mirror of
https://github.com/yattee/yattee.git
synced 2026-10-23 21:22:53 +00:00
3d87aeeaf1
The screen read local playlists and nothing else, so selecting an account moved the subscriptions and the feed but left this list showing the device's own playlists with no way to tell. It now follows the effective context: local as before, or the account's list read live out of RemotePlaylistsCache — never copied into state, because every change to a server-side playlist goes through that cache and reading it is what makes a rename or a delete show up. Rows carry both the account's instance and the account's id, which have to agree or UnifiedPlaylistDetailView drops ownership and the playlist loses its edit and delete. Editing refetches first, exactly as the detail view does: the form saves every field at once, and one started from a row fetched minutes ago would put that row back over anything changed since. Deleting from a server asks first; deleting a local playlist stays unconfirmed as it always was. Row identity, item mapping and the search filter move into PlaylistListItem, where they can be tested — the transition id stays separate from the row identity because it has to match what PlaylistSource produces for the destination. Local behaviour is unchanged throughout: the same rows, the same swipe actions, the same unconfirmed delete, and the same synchronous read on appear so the empty state never flashes.