music_library/backlog/completed/ml-29 - Collection-Wishlist-index-LiveView-duplication.md

id, title, status, assignee, created_date, labels, dependencies, references, priority

id	title	status	assignee	created_date	labels	dependencies	references	priority
ML-29	Collection/Wishlist index LiveView duplication	Done		2026-04-20 08:51			https://github.com/cloud8421/music_library/issues/150	high

Description

GitHub: created 2026-04-05 · updated 2026-04-13 · closed 2026-04-13

Summary

CollectionLive.Index (359 lines) and WishlistLive.Index (338 lines) share ~40% identical code including apply_action/3, load_and_assign_records/2, order_path/2, back_path/2, search event handling, and filter/pagination markup.

Why This Matters

• Any change to index behaviour (pagination, search, display modes, ordering) must be applied twice
• Bug fixes in one may be missed in the other
• #125 addressed the duplicated parse helpers, but the broader structural duplication remains

Affected Files

• lib/music_library_web/live/collection_live/index.ex
• lib/music_library_web/live/wishlist_live/index.ex

Suggested Fix

Extract shared index behaviour into a LiveHelpers module or use a shared base pattern that both LiveViews delegate to, parameterizing only the differences (base query filter, routes, section name).

Acceptance Criteria

• Shared logic lives in one place
• Both index pages retain their current functionality
• Adding a new shared feature (e.g., new sort option) requires changes in one location

• #1 Shared logic lives in one place
• #2 Both index pages retain their current functionality
• #3 Adding a new shared feature (e.g., new sort option) requires changes in one location