Tracks page doesn't properly reflect changes

[Insprill]

Describe the bug
When adding or removing saved tracks, the tracks page does not reflect those changes properly until the app is restarted.

To Reproduce

• Load the tracks page.
• Save a song that isn't already saved.
• The last saved song will now be duplicated at the bottom of the list, and the new song will not be there.

This also applies when unsaving songs.

• Go to the tracks page.
• Unsave a song.
• The last song in the list will be removed, and the song you just unsaved will still be there.

Expected behavior
The list will be updated properly.

Environment

• OS: Windows 10
• Version: 21H2 19044.2130

Additional context
Add any other context about the problem here.

[oleggtro]

Same thing for me, this is kind of annoying.
I'm probably going to look into this in the next few days.

[jacksongoode]

Can confirm this on latest/macOS as well.

[oleggtro]

Yeah, pretty sure thats a problem with us not invalidating the cached api response/altering the local copy on updates

Wasn't able to look at it till now, though. Maybe in the next couple days 💀

[Insprill]

I'm not sure exactly what the issue is, but it's not that.

psst/psst-gui/src/data/mod.rs

Lines 293 to 305 in 64362ea

	pub fn add_track(&mut self, track: Arc<Track>) {
	if let Some(saved) = self.saved_tracks.resolved_mut() {
	saved.set.insert(track.id);
	saved.tracks.push_front(track);
	}
	}
	pub fn remove_track(&mut self, track_id: &TrackId) {
	if let Some(saved) = self.saved_tracks.resolved_mut() {
	saved.set.remove(track_id);
	saved.tracks.retain(|t| &t.id != track_id);
	}
	}

Here is where the local state is updated. If you print out the contents of the Vector after it's modified, the contents represent the correct state. In add_track, if Vector::push_front is replaced with Vector::push_back, the correct track gets added to the end of the list and is visible in the UI. Because of this, I would suspect it's related to Druid's handling of Vectors, however, albums use basically the same code and don't have this issue.

[jacksongoode]

It seems the way the Track and Album object are handled is different. I'm looking into this now. My first thought is that SavedAlbum is stored as a hashset of str while SavedTracks are a hashset of the custom TrackId.

[jacksongoode]

Maybe because TrackId's implement copy instead of clone which Albums do? Eh maybe this is a frontend refresh thing.

[royathan]

This appears to not to affect playlists when removing a song because we are specifically resubmitting the playlist data load command:

psst/psst-gui/src/ui/playlist.rs

Lines 172 to 173 in 38422b1

	// Re-submit the `LOAD_DETAIL` command to reload the playlist data.
	e.submit_command(LOAD_DETAIL.with((p.link, data.clone())))

As well, adding a song to a playlist doesn't have issues because playlist navigation always reloads the PlaylistDetails. It looks like it shouldn't, but the LOAD_DETAIL command always gets sent here because data.playlist_detail.playlist is ALWAYS Empty.

psst/psst-gui/src/controller/nav.rs

Lines 47 to 53 in 38422b1

	Nav::PlaylistDetail(link) => {
	if !data.playlist_detail.playlist.contains(link) {
	ctx.submit_command(
	playlist::LOAD_DETAIL.with((link.to_owned(), data.to_owned())),
	);
	}
	}

[jacksongoode]

@literallyjustroy If you're interested in submitted a PR to revise this, I'd be more than happy to look over it!

[royathan]

Still digging around on the internal logic here. A quick and dirty fix would just be force a full reload on all track lists when selected (like playlists do now). But then accessing your library would be slower than it is today, so it's really not ideal.

The saved_tracks is actually updated correctly during a remove track/add track, it's just that the tracks list widget doesn't use the new data. This is especially noticeable if you remove the top track from your saved songs, then try to play it. It'll start playing the one below it (since internally that is the first song in the list, even though the ui doesn't show it).

Not familiar with druid/not sure how to tell the page to reload the widget. Ideally we do a combination. We should show the correct data we have saved locally right on navigation, then we can reload the tracks in the background and if there's an update we'll see it then.

[royathan]

Okay so the problem with the lack of ui updating is (I'd guess this is pretty obvious if you're familiar at all with druid) is centered around Lenses. In particular I think the problem is that the saved_tracks_widget lens is looking at the Library::savedTrack field, which is actually a promise. So the only time the ui will update is when the entire object is changed. For example, the ui will actually update if you call clear() on the saved_tracks promise.

Interestingly, Saved Albums correctly updates instantly when getting removed...

[jacksongoode]

Ah so it doesn't need to be a promise? We need to immediately update that object?