Sort videos within playlist

[kommunarr]

Sort videos within playlist

Pull Request Type

• Feature Implementation

Related issue

closes #4870

Description

• Implements sorting types:
• A-Z / Z-A (Video title)
• A-Z / Z-A (Channel name)
• Custom (Custom sorting will be set when user moves a video up/down in the list)
• Sort by Recently added / Earliest added

Implementation details:

• Only for user playlists, not remote playlists.
• I didn't implement Sort By Views or Video Length because those seem quite unimportant. I can implement these if someone actually wants these features.
• The default sort preference is "Latest added first". If the user sets their sort preference in a user playlist, it applies to all of their user playlists by default.
• The order adjustment buttons (i.e., move up/down) are not present for sort orders of Custom. Rationale: we want "Custom" orderings to persist even when the sorting preference is changed to something else.

Unrelated mini-fix:

• Adds locale property that was being referenced (but was actually missing) in src/renderer/components/ft-playlist-add-video-prompt/ft-playlist-add-video-prompt.js

Screenshots

Testing

• Test all orders work properly on a remote playlist (tested with this one)
• Test all orders work properly on a local playlist
• Test "move/up down" buttons show only for Custom sort orders, and that they continue to work properly

Desktop

• OS: OpenSUSE
• OS Version: TW

More info

I have a PR coming out after this is merged for handling sorting in watch-video-playlist. I split this up to ease the testing criteria and the relative unimportance of the other sorting types compared to the big "Added" and "Custom" ones.

[absidue]

Technically, only each individual "batch" of data is sorted for remote playlists, due to obvious technical limitations. I think this is fine.

I would prefer to not have sorting for remote playlists at all, if we can't do it properly. We don't allow searching in remote playlists for the same reason.

[absidue]

Also personally I think that there are too many sorting options, it feels a lot like a "because we can" and not because anyone would ever actually use it (all the people that complained just want a way to reverse playlists).

I think we just need 2:

• Default: respects the order in the playlist, move buttons are shown
• Reversed: just reverses the playlist, otherwise respects the order in the playlist, move buttons shown but move in the correct direction in the UI, so opposite in code

[kommunarr]

I would prefer to not have sorting for remote playlists at all, if we can't do it properly. We don't allow searching in remote playlists for the same reason.

On it!

I think we just need 2: [...]

Let's talk about that some more in the Dev channel. That conception seems pretty different from what was being recommended by @efb4f5ff-1298-471a-8973-3d47447115dc and @PikachuEXE in the #4870 discussion.

[ChunkyProgrammer]

I think these are good options but the select box definitely seems to have a lot of options for a sort by. I wonder if there should be a separate control (ex: checkbox) for ascending/descending? That way the amount of items in the select box will be halved and reversing the playlist would take one click.

[kommunarr]

I'm not opposed to that. Thoughts? @absidue @efb4f5ff-1298-471a-8973-3d47447115dc @PikachuEXE

[PikachuEXE]

Disagree
Not every sort order must have a "reverse" one (weak argument I know
Having 2 UI components just to get a sort order seems unnecessary, non-standard UI/UX
You can reorder the options if you want

[PikachuEXE]

Can sort by component be placed on the right like most other places?

[PikachuEXE]

Custom already sound a bit weird to me
Custom (descending) makes it even more weird

I guess this means "user specified" order
User-defined? (Suggest a better if you can

[kommunarr]

I'm seeing some different perspectives on this from everyone. I think the option I'm leaning to the most is removing "Custom (Descending)", implementing @PikachuEXE's position (& most likely label) changes, and making "added descending" the default. With "Custom (Descending)" gone we're at 7 playlist sort preferences, compared to YT's 5, which isn't what I would call excessive. I think it's more that the current ordering & wording of the labels could stand to be adjusted to reduce cognitive complexity. Let me know what y'all think.

[kommunarr]

Here's how it looks like now:

[PikachuEXE]

Why isn't custom the default sort order?

[kommunarr]

Rationale being that "Latest added first" is the previous behavior before the Playlist PR, and seems to be the most requested ordering from people. Custom ordering seems to be relatively less leveraged on average and thus less suited to be the default behavior.

[PikachuEXE]

I am fine having default option changed with the last used sort order is saved

But we should disable order changing UI unless the sort order is "custom"

(YT just persists the sort order when a sort order option picked, it sucks)

[kommunarr]

But we should disable order changing UI unless the sort order is "custom"

One step ahead of you:

FreeTube/src/renderer/views/Playlist/Playlist.vue

Lines 76 to 77 in 9db7e48

	:can-move-video-up="index > 0 && !playlistInVideoSearchMode && isSortOrderCustom"
	:can-move-video-down="index < playlistItems.length - 1 && !playlistInVideoSearchMode && isSortOrderCustom"

Update: Updated the PR description with changes discussed.

[absidue]

If you want to implement this, you'll have to keep in mind that shorts don't have a published date on the shorts channel tab or in shorts only playlists (not returned in youtube's response, thats's why we always use RSS on the shorts tab on the subscriptions page), so if someone were to add a video to a playlist from there, it would make it impossible to sort by published. Also the Invidious API never returns published dates inside playlists, so if someone were to copy a playlist while using the Invidious API, the published dates would be missing for all videos.

For the watch history we just don't store the published date if it isn't available, but we also don't have any sorting functionality that would depend on it.

Also unlike the watch history where marking as watched from a list is probably quite uncommon (most people probably let the watch page do it automatically), adding to a playlist from a list is probably a lot more common (especially the quick bookmark).

TL;DR: I don't think we should even attempt to support it, due to all of the situations where it wouldn't be possible.

[kommunarr]

Thanks for this context absidue. Just removed the code for these.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[kommunarr]

Didn't mean to push that to this branch, intended to put that in a second PR. My bad! Reset now

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.