The selected category is not persisted across page loads
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- javascript
- Ambito
- frontend
Direzione di ricerca
Inizia dalla vista delle note, intorno a getFilteredNotes(), al punto di ingresso /app/notes e al comportamento esistente di loadRecentOnStartup e notesLastViewNote. Traccia come vengono gestite la categoria selezionata e l’URL corrente, quindi risolvi con i maintainer le questioni aperte relative alla codifica dello stato della query, al ripristino all’avvio e alla sincronizzazione dell’URL. Il lavoro è completato quando gli aggiornamenti, i link condivisi, la navigazione avanti/indietro del browser e i nuovi avvii dell’app preservano la categoria prevista senza confondere All Notes e Uncategorized.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Is your feature request related to a problem? Please describe.
When a user selects a category, it is only maintained in-memory. It isn't stored in the URL and isn't persisted anywhere else. The symptom is that the category resets to "All notes" on every page load and when the app is loaded fresh.
However, the filtering works. getFilteredNotes() does filter by the category the user selects and changes the sorting from "most recent" to the selected category. But any refresh changes the view back to "most recent" in the notes list and doesn't retain the selected category. For users who work in a particular category, it means continually clicking back to that category.
Also, browers back/forward navigation doesn't navigate between categories.
Describe the solution you'd like
There are two parts to the feature and each could land independently:
- Store the selected category in the URL so the category remains selected when the page reloads or the user uses the back/forward navigation in their browser or shares a link
- Use a user setting to restore the category the user selected last when the app loads. This would be similar to how the last-viewed note is loaded using
loadRecentOnStartupandnotesLastViewNote. Part 1 by itself doesn't cover what is likely the common use case of opening Notes from the app menu. It lands on/app/noteswith no query string so the user has to navigate back to the category they had navigated to last time they were in the app.
Describe alternatives you've considered
For the first item, I considered a path segment (/category/:category/) but the categories are stored as folder paths containing the forward slash. This would make the wildcard route ambiguous vis-a-vis the existing /note/:noteId. It would also break existing note URLs. Using a query param avoids these problems while encoding the slashes properly and matching the current ?new convention.
For the second item, I considered browser storage as a simpler option but the app doesn't currently use that. So we went with the approach that notesLastViewedNote already uses. Also, this approach allows for syncing across devices.
Additional context
Issue #1079 talks about persisting the visibility of the navigation itself. While this is a different setting, it does address the same underlying gap as this request. #879 which is about the category tree (something else I'm very keen on addressing) would also need persistence so creating the foundation here would be beneficial to other features that would need the same persistence mechanism.
Here are some open questions:
- Should I use the query parameter as I suggest or the path segment for the category in the URL?
- How should the URL represent "Uncategorized" (which is an empty string and a real category) from "All Notes" which is a null category. Right now, these are distinct states and naive encoding wouldn't distinguish between them.
- Should restoring the category on startup be a new setting or should it be folded into the existing
loadRecentOnStartupsetting? - If item 2 restores the category on startup, should this be reflected in the URL as well so the URL has the actual category state? I think this is a good design choice but want to confirm first.
Investigated with the help of Claude Code.
- Lingua principale
- JavaScript
- Stelle
- 738
- Fork
- 162
- Merge medio
- 2h 32m
- PR unite (30g)
- 41
Preparare l'ambiente
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di nextcloud/notes
-
bug need to reproduce
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
I maintainer di solito rispondono entro 1 giorno
-
bug need to reproduce
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
feature request needs discussion
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 62/100
nextcloud/notes#1344 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Tag or categorize notesApertafeature request needs discussion
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di nextcloud/notes
Issue simili
-
Design only Leadership Survey SLFS
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
bcgov/digital-journeys#2293 ·
-
Toolkit
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
API Bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
ProjectSidewalk/SidewalkWebpage#5556 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
jessepollak/home#1454 ·
I maintainer di solito rispondono entro 1 giorno
-
Mend: dependency security vulnerability untriaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
opensearch-project/OpenSearch-Dashboards#12822 ·
I maintainer di solito rispondono entro 1 giorno