Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

The selected category is not persisted across page loads

Abierto
  • ¿Algo no está bien?
#2,033 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript
Área
frontend

Línea de trabajo

Comienza en la vista de notas, alrededor de getFilteredNotes(), el punto de entrada /app/notes y el comportamiento existente de loadRecentOnStartup y notesLastViewNote. Traza cómo se gestionan la categoría seleccionada y la URL actual, y resuelve con los maintainers las preguntas abiertas sobre la codificación del estado de la consulta, la restauración al iniciar y la sincronización de la URL. Se considera terminado cuando las actualizaciones, los enlaces compartidos, la navegación hacia atrás y hacia delante del navegador y los nuevos inicios de la aplicación conservan la categoría prevista sin confundir All Notes y Uncategorized.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
JavaScript
Estrellas
738
Forks
162
Merge medio
2 h 40 min
PR fusionados (30 d)
39

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de nextcloud/notes

Todos los issues de nextcloud/notes

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.