Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decouple entry-list and editor #1372

Open
myieye opened this issue Jan 13, 2025 · 1 comment
Open

Decouple entry-list and editor #1372

myieye opened this issue Jan 13, 2025 · 1 comment
Labels
💻 FW Lite issues related to the fw lite application, not miniLcm or crdt related
Milestone

Comments

@myieye
Copy link
Contributor

myieye commented Jan 13, 2025

Describe the feature
Currently the editor is only allowed to show entries that are in the current filtered list of entries. That means that whenever we want to show a certain entry (after creating an entry, loading the entryId in the URL, clicking on a quick-search result, clicking on a component or complex form etc.) we have to make sure the entry list contains that entry. We've done that by applying a text filter and sometimes even an exemplar filter I think (we can't just remove all filters, because the entry might not be in the first page of entries). It's yucky.

To solve this we want to decouple the entry-list and the editor, which means:

  • The editor can show an entry that's not in the list (In the future we could consider making that fact visible with something along the line of Currently-selected entry should appear in nav list no matter what the filter is #1366)
  • Whenever we want to load a certain entry we query it by ID and stick it in the editor, whether it was: selected from the list, just created etc. That will be the new semantics of navigateToEntry
  • We stop implicitly picking a selected-entry (there might be an exception or two e.g. selecting the first entry on page load, but even that's not necessarily needed/valuable and we do have a meaningful empty state that includes a create entry button, so I'd lean towards never implicitly selecting an entry, but I don't have a strong opinion)
  • The new semantics of NewEntryDialogOptions.dontNavigate will no longer be "don't load it in the entry list and then select it and load it in the editor", but rather just "don't load it in the editor", because we won't change the entry list at all.
  • Later it would be nice if we could optionally load a selected-entry in the entry-list as well, but that's complicated to do well (the db would have to figure out what page it's on and we'd have to decide what to do with active filters: just always throw them away or keep them if they include the selected-entry 🥴)

In the 2 cases "on new entry created by us" and "on new entry from a different user" we have the problem of knowing if the entry should be in the current filtered list of entries on our machine. I can think of 2 fixes:

  1. Ultra-complex pro fix: we ask the server if entry X matches filter Y and what index it has in the matching result list, so we can insert it ourselves. Yikes.
  2. Quick fix: we always just refresh the list of entries and it'll show up if it should. 👈 I'd be inclined to implement this as part of this issue.

Who is this feature for?
Editors

Pages affected
Project

@myieye myieye added the 💻 FW Lite issues related to the fw lite application, not miniLcm or crdt related label Jan 13, 2025
@myieye myieye added this to the FW Lite beta milestone Jan 13, 2025
@rmunn
Copy link
Contributor

rmunn commented Jan 13, 2025

#1367 (review) mentioned wanting to flip the dontNavigate condition. It's possible that that won't be necessary once this idea is implemented, but I'm mentioning it here so we don't lose track of the idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💻 FW Lite issues related to the fw lite application, not miniLcm or crdt related
Projects
None yet
Development

No branches or pull requests

2 participants