Sort by date on the history page#6214
Conversation
github-actions
Bot
added
the
PR: waiting for review
Head branch was pushed to by a user without write access
|
o: it's been two weeks, hopefully this get reviewed soon so I can make any fixes necessary and/or start work on follow ups |
| dataLimit: 100, | ||
| searchDataLimit: 100, | ||
| doCaseSensitiveSearch: false, | ||
| ascending: false, |
There was a problem hiding this comment.
| ascending: false, | |
| useAscendingOrder: false, |
Recommend adjusting the variable name to be more specific.
| :default-value="doCaseSensitiveSearch" | ||
| @change="doCaseSensitiveSearch = !doCaseSensitiveSearch" | ||
| /> | ||
| <ft-toggle-switch |
There was a problem hiding this comment.
suggestion (non-blocking): We do tend to use ft-selects for sort selections, and we may have more options for this in the future, so you may want to consider changing it. Not incredibly important at this point, though, aside from making the current labeling more likely to be temporary.
There was a problem hiding this comment.
Better have consistent UI unless there is a good reason
There was a problem hiding this comment.
ft-select will probably require me to make change to the store, not a problem, but I'm debating then, if I'm using ft-select I should stop using a boolean for this then, I didn't want to use an enum yet, since I don't even know if we will have sorting of anything besides date. (and if we are never sorting by anything else an enum feels unnecessary)
what are your thoughts on using an enum instead?
I can also add boolean as a type to ft-select, but I'm not sure what is the desired approach here
| Empty Search Message: There are no videos in your history that match your search | ||
| Search bar placeholder: "Search in History" | ||
| Case Sensitive Search: Case Sensitive Search | ||
| Sort By Date ASC: Sort By Date ASC |
There was a problem hiding this comment.
issue: Related to the above, not a fan of this label, but hard to know of a better alternative without switching to ft-select. If you do do that, looking at the other sorting labels we have, more consistent ones would be DateWatchedOldest: Earliest Watched First and DateWatchedNewest: Latest Watched First
There was a problem hiding this comment.
I was also not a big fan of the label, but I also wasn't sure what to write, I'll look into ft-select and update the label accordingly (I like the Latest/Earliest watched first label more)
There was a problem hiding this comment.
I changed the sort by texts please take a look
Head branch was pushed to by a user without write access
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
github-actions
Bot
added
PR: merge conflicts / rebase needed
and removed
PR: waiting for review
|
I made some changes based on feedback, I switched to ft-select, I prepared the store to prepare for more sort options, when more sort options are added, historyCacheSorted would be the place to change things (instead of just an inline if a case and calls to different sorting would be necessary). in the case of this sort, it's just reversing the list not actually sorting, if other sorts would be added, we would need to stop doing that and actually sort, so a decision would have to be made if it's worth adding more sorting possibilities that would obviously make sorting slower, particularly with people with huge histories. |
Head branch was pushed to by a user without write access
|
Conflicts have been resolved. A maintainer will review the pull request shortly. |
|
I might have messed up the way I solved the conflicts (let me know if you prefer a clean PR again :(, or if something else) |
|
Please solve the conflicts properly, you seem to have pulled in all the commits from the development branch so now it is really difficult to tell what changes are yours and merging this PR will then reland all of the existing changes on the development branch a second time. The two usual approaches are:
As for how to fix what you have done here, I'm not sure. |
Head branch was pushed to by a user without write access
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
|
I reset to my latest commit, I used rebase, but I think I messed it up somehow, unsure how it ended that way you can see only my changes now, I'll try to fix the merge conflicts in a bit... HOPEFULLY not messing everything up again lol had to reset HEAD --hard <my_last_commit> then I did the rebase properly after that EDIT. that should have fixed it, sorry about the random trouble... please review when you have the chance |
Head branch was pushed to by a user without write access
|
Conflicts have been resolved. A maintainer will review the pull request shortly. |
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
|
This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days. |
|
Hi, I apologize I haven't had time to make the chances, just changed jobs, I'll try to get the changes done next weekend |
…o more sort types
…eview suggestions and fixes
Head branch was pushed to by a user without write access
|
Conflicts have been resolved. A maintainer will review the pull request shortly. |
|
I updated the PR with the changes from the code review, sorry for the delays, holidays then changed jobs, so I had a pretty hectic couple of months |
|
Icon change requested in #6214 (comment) hasnt been implemented yet |
I see I missed that one, I'll update it in a bit |
|
This PR is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 14 days. |
|
This PR was closed because it has been stalled for 14 days with no activity. |
5 participants
Sortbydate
Pull Request Type
Related issue
Initial addition to #5595 (not sure it would be considered closed and we just make a new issue for future changes)
Description
Adds a sort by date ascending/descending toggle to the history page, this is a stopgap to adding a more fully fledged filter by setting, but I wanted to keep the changes small and incremental since design wise, some decisions have to be made and I'm not sure I'm the one that should make those decisions. (like other kinds of sorting/filtering in history page)
I also removed the second sorting it does when it does the search, since the array it uses is already sorted (in whichever order we choose), and the filter method I believe does a linear scan, it seemed unnecessary to sort twice, if we think it's necessary I can add it back and just add a condition to sort whichever way we need it to (But I don't think it's needed)
Screenshots
Testing
I tested by adding random videos to history, sorting it back and forth, then doing search and sorting back and forth as well
possibly with a huge history we'd like to view how the sorting performs... I don't have a huge history at the moment, so it's hard to tell. it's expected to a certain degree
Desktop
Additional context
I stuck to the simple toggle since I was only going to do the asc/desc sorting on this PR