Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

The selected category is not persisted across page loads

Aperta
#2,033 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

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

feature request needs discussion

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:

  1. 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
  2. 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 loadRecentOnStartup and notesLastViewNote. 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/notes with 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:

  1. Should I use the query parameter as I suggest or the path segment for the category in the URL?
  2. 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.
  3. Should restoring the category on startup be a new setting or should it be folded into the existing loadRecentOnStartup setting?
  4. 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

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nextcloud/notes

Tutte le issue di nextcloud/notes

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.