You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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.
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
The text was updated successfully, but these errors were encountered:
#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.
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:
navigateToEntry
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.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:
Who is this feature for?
Editors
Pages affected
Project
The text was updated successfully, but these errors were encountered: