ML-169.5: cancel task as it breaks functionality

2026-05-19 15:16:55 +01:00
parent be371cbf4e
commit 78670268d5
1 changed files with 35 additions and 1 deletions
@@ -0,0 +1,92 @@
+---
+id: ML-169.5
+title: "Fix: Display toggle (grid/list) triggers full DB reload"
+status: Done
+assignee: []
+created_date: "2026-05-19 11:45"
+updated_date: "2026-05-19 15:13"
+labels:
+  - perf
+  - fix
+dependencies: []
+references:
+  - >-
+    backlog/documents/doc-27 -
+    Phase-4-Performance-Audit-Low-Hanging-Fruit-Findings.md
+modified_files:
+  - lib/music_library_web/live_helpers/index_actions.ex
+  - lib/music_library_web/live/collection_live/index.ex
+  - lib/music_library_web/live/wishlist_live/index.ex
+parent_task_id: ML-169
+priority: high
+ordinal: 26000
+---
+
+## Description
+
+<!-- SECTION:DESCRIPTION:BEGIN -->
+
+Fix performance issue where toggling between grid and list display views triggers a full FTS database reload.
+
+## Problem
+
+`handle_set_display` in `index_actions.ex` calls `load_and_assign_records/2` which re-executes the full FTS search query (`search_records_count` + `search_records`). The toggle only changes a CSS layout class (`@display == :grid` vs `@display == :list`) — no data changes.
+
+## Impact
+
+Every grid/list toggle wastes 2 FTS queries. This is a common user interaction (clicking the view switcher button).
+
+## Files
+
+- `lib/music_library_web/live_helpers/index_actions.ex:136-143` — `handle_set_display/2` calls `load_and_assign_records`
+- `lib/music_library_web/live/collection_live/index.ex:336` — `handle_event("set_display")`
+- `lib/music_library_web/live/wishlist_live/index.ex:259` — `handle_event("set_display")`
+
+## Fix
+
+Remove the `load_and_assign_records` call from `handle_set_display`. Only `assign(:display, mode)` is needed. The existing `:if={@display == :grid}` / `:if={@display == :list}` conditionals already handle showing/hiding the appropriate view.
+
+<!-- SECTION:DESCRIPTION:END -->
+
+## Acceptance Criteria
+
+<!-- AC:BEGIN -->
+
+- [ ] #1 Grid/list toggle no longer triggers DB queries (verified via QueryReporter)
+- [ ] #2 Grid view renders correctly after toggle
+- [ ] #3 List view renders correctly after toggle
+- [ ] #4 No regression in search/filter functionality after toggle
+<!-- AC:END -->
+
+## Archive Reason
+
+<!-- SECTION:ARCHIVE_REASON:BEGIN -->
+
+Archived after validation showed the proposed optimization is not correct with the current
+LiveView stream rendering structure.
+
+Collection and wishlist render either `<.record_grid>` or `<.record_list>` behind
+mutually exclusive `:if` branches, and both components consume the same `@streams.records`
+stream. LiveView stream entries are consumed after render and the existing DOM holds the
+streamed children. When the display mode changes, the previously mounted stream container
+is removed and a different stream container is mounted. Without re-running
+`stream(:records, records, reset: true)`, the newly mounted container has no queued stream
+entries to insert, so only its static empty-state node remains and `only:block` displays
+“No records yet”.
+
+The DB reload avoided by this task is therefore also the step that rehydrates the stream
+for the newly mounted container. A future optimization would need a different rendering
+shape, such as keeping both containers mounted or avoiding conditional stream container
+replacement, before removing the reload.
+
+<!-- SECTION:ARCHIVE_REASON:END -->
+
+## Final Summary
+
+<!-- SECTION:FINAL_SUMMARY:BEGIN -->
+
+Reverted the proposed `handle_set_display/2` change and archived this task as not
+actionable in the current UI structure. The reload is required because grid/list toggling
+replaces the mounted stream container.
+
+<!-- SECTION:FINAL_SUMMARY:END -->