User favorite status synced across app (fixes #659) #731
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So, user liking of a song was pretty inconsistent before this PR. I made two large changes to make this better, inspired by #659, which this PR fixes part of.
First of all, if a user had liked a song before playing it, that status never showed up in the player at the bottom. It always showed a non-red heart until the user liked it (again). I get around this by using the util function for updating
user_favorite
when playing a new song.Second, if you had a song playing and you liked it from the queue, stream, playlist, etc, it wouldn't update the heart in the player. And if you liked it from the player, it wouldn't change state on the stream, playlist, etc. There was no sharing of state or knowledge between views. I added a
$broadcast
notification on any like or dislike of a song to fix this. The song directive handles changing the status ofuser_favorite
when it gets it, and root scope handles removing/adding to the likes cache inutilService
.This was extensively tested, from every state I could think of, and it seems to work consistently! State is shared for likes. This would all be much easier if there was one type of song data model that had state, and we saved that song model somewhere, only ever using that one object to read or write changes to. Something to think about for the future.
One more state-related bug this fix exposed is that liking a song from the player/queue doesn't update the count of the likes on the stream/playlist/etc page itself, as those pages use a
$scope.count
variable to keep track of counts (seefavoriteSongDirective
to see where this is being changed). IMO, we should be using the data's count property itself on those pages and then the notification handler in the song directive can also modify count values, rather than changing$scope.count
where we call the API infavoriteSongDirective
. But that requires a bit of refactoring, so it will be done in a future commit.