feat: remember sorting per folder - #356
Conversation
|
I tested this against my branch — it merges with a single trivial conflict in The sort is shared between accounts on the same browser. The map grows without bound. One entry per folder ever sorted, never expired or trimmed. It won't hit the quota in normal use, but nothing stops it either — a cap on the most recently used entries would. Dynamically created sort options are lost on reload. Worth mentioning since it's adjacent: #360 asks for a configurable default view, and its author believes per-folder view preferences already exist — probably having assumed the sorting behaviour this PR introduces. If per-folder state is going to be a pattern here, it's better if sorting and view use the same storage and the same scoping rules rather than diverging. |
Sorting is remembered per folder, so a folder opened again comes back the way it was left. Contributed by @jimaek, for nxzai#355. Taken as it stands, with its shortcomings noted on the pull request: the map is stored in localStorage and so is shared between accounts on one browser, it grows without bound, and a sort by a column outside the eight built-ins does not survive a reload. The first of those is the same flaw the default-view work has to solve anyway, and both are better fixed once, together, than separately here. # Conflicts: # frontend/src/stores/fileStore.js
|
Please check now |
@jimaek reworked this after review, and it now answers all three points: sorts are stored per user through `user_settings` rather than in localStorage shared by every account on a browser, the map is capped at 100 entries by recency, and a sort on a column outside the built-in list is rebuilt on load instead of silently falling back. Two things changed while resolving the merge: The new `upsertUserSetting` went through `db.prepare` on every write. It now goes through `prepared`, which caches the statement — the rest of this file already avoids recompiling the same SQL, and these run on every preference change. The store's factory for default system settings predated `uploads` and `folderSize`, so switching user would have reset the store to a shape the rest of the app no longer expects. It builds the full shape now, and the duplicate declaration that the merge left behind is gone. His local generateId is dropped in favour of the one this file already imports.
2 participants
Fixes #355