mirror of
https://github.com/koel/koel.git
synced 2026-04-27 09:46:03 +03:00
[GH-ISSUE #299] Default sorting of song list #219
Labels
No labels
Authentication
Dependencies
Documentation
Feature Request
Flac
Help Wanted
Installation/Setup
Integration
Mobile
PR Welcome
Pending Release
Performance
Playlist
S3
Search
Sync
[Pri] Low
[Pri] Normal
[Status] Keep Open
[Status] Needs Author Reply
[Status] Needs Review
[Status] Stale
[Status] Will Implement
[Type] Blessed
[Type] Bug
[Type] Duplicate
[Type] Enhancement
[Type] Help Request
[Type] Question
[Type] Task
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/koel-koel#219
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @alex-phillips on GitHub (Apr 13, 2016).
Original GitHub issue: https://github.com/koel/koel/issues/299
I can't seem to figure out the right place to put this, otherwise I'd submit a PR, but I think the default sorting of the song list should be artist - album - track. I'm not sure what the default sort currently is (if any) but every time I open up the app I have to click the artist column twice to get to what is defaulted on most media players.
@phanan commented on GitHub (Apr 14, 2016):
You're right, there's no default sort as of current. I don't think there should be one, either. At least, I personally don't care about it, and it takes only one or two clicks anyway.
@alex-phillips commented on GitHub (Apr 14, 2016):
What if we made it a 'sticky' setting and saved the last sort in a cookie which was restored the next time the page is loaded? I feel that would be a good compromise and the setting could even be disabled if desired?
@phanan commented on GitHub (Apr 14, 2016):
Saving the last state is not a bad idea, however we'll need one state for every song-list screen (all songs, favorites, and every playlist). That could look ugly very quickly IMO.
@alex-phillips commented on GitHub (Apr 14, 2016):
What if we only applied it to 'song list' view (the main ones). This would cover when your viewing songs, whether it be on the artist page, album page, or 'all songs' and only apply it to those views? Those are the only views that would by default actually matter what order the songs are referred to in. I don't think you'd want the software to auto-sort your favorites or playlists since you'd create those yourself.
I'd be happy to take this on and submit a PR, but I'd rather not do the work without discussing with you on how it should be done and actually get merged in. Otherwise it'd be wasted time :-P.
@phanan commented on GitHub (Apr 14, 2016):
Let's go for All Songs, Artist, Album, and Favorites then. I agree that we
don't need to cater for custom playlists.
And of course, a PR would be much appreciated!
On Thu, Apr 14, 2016 at 11:04 PM, Alex Phillips notifications@github.com
wrote:
@alex-phillips commented on GitHub (Apr 14, 2016):
I'll get to it. Thanks for the insight!
@alex-phillips commented on GitHub (Apr 14, 2016):
@phanan What's the best way to determine the current
viewinside of thesong-list.vuefile? I can't tell anywhere we're currently checking a state like that except the extras components.@phanan commented on GitHub (Apr 15, 2016):
It's the
typeprop.@alex-phillips commented on GitHub (Apr 15, 2016):
So it's up to you how to approach this, and both ways are extremely easy.
allSongs,artists,andalbumview (and a couple others?)lskey withthis.typeand apply it as long as that key exists. This would make each individual view have its own sticky sorting.Code examples below:
Obviously these code snippets are only the portions where we apply the saved value, but the setting would be quite similar.
@phanan commented on GitHub (Apr 15, 2016):
I would go with 2, but with a different approach:
preferenceStore.state.sorts.This looks more structural and cleaner IMHO.
@alex-phillips commented on GitHub (Apr 15, 2016):
Would it be smarter to have the
typebe the key for an object containing the information rather than an array of objects? That way you wouldn't have to iterate through the array but just check if the property exists:@phanan commented on GitHub (Apr 15, 2016):
Yes of course I meant an object :P
@alex-phillips commented on GitHub (Apr 15, 2016):
Great, just clarifying. I'll have a PR for you sometime today.
@alex-phillips commented on GitHub (Apr 15, 2016):
I'm running into an issue calling
.seton the preferences object with a nested key (i.e.,sorts.allSongs). Is there a good way to save a nested value in preferences? Or should I call.get('sorts'), edit what I need to, and then just savesortsback to preferences?Or should I add support for calling
setwith dot-notation strings?@phanan commented on GitHub (Apr 15, 2016):
.setfor nested keys isn't supported (because there wasn't a need for it), so you can do either :P@alex-phillips commented on GitHub (Apr 15, 2016):
It looks like I'm able to set the sorts into the preferences just fine (when I open the resources tab I can inspect the local storage object and see the value there), but if I call
preferences.get('sorts')it returns an empty object.Do I have to initialize preferences at all before using it? Maybe I'm attempting to use the preferences object too early?
@alex-phillips commented on GitHub (Apr 18, 2016):
@phanan any thoughts on this? If I use the example snippets above (with prefs instead of ls), when the page loads, it never retrieves the data I see stored in local storage.
@phanan commented on GitHub (Apr 18, 2016):
Oops sorry, this slipped my mind. Can you post the whole code?
@alex-phillips commented on GitHub (Apr 18, 2016):
preferences.js
song-list.vue
Note: if you don't include my new
getandsetmethods and use the other method described above, the outcome is the same. The value is set, but never retrieved when the page loads.@phanan commented on GitHub (Apr 18, 2016):
Yes, you're calling the preferences too early. Preferences are bound to the user, and only initialized after the user has logged in. In your case, the
song-list'sdata()is called prior to that, hence the empty value.@alex-phillips commented on GitHub (Apr 18, 2016):
So should I just use local storage here?
@phanan commented on GitHub (Apr 18, 2016):
No, of course not! You can trying watching the property instead, or listen to
koel:readyevent.