Lbry-desktop: Sort order should be retained when returning to page

[42degrees]

My publishes library has a lot of duplicates in it. These are real duplicates. So, I sorted my list by name and started going through it to remove the duplicates. But every time I hit Back to return to the main list, it changes the sort order back! Very annoying, especially if I'm scrolled down the page as the sort control scrolls off.

Also, if a change has happened (like I deleted an item) then when I return to by publishes page it's going to update, but it can take 20 seconds. If I change the sort order before it updates, then when it updates it changes my sort order. This can be very annoying especially if it refreshes just as I'm going to click on something since I end up clicking on the wrong item.

Sort of on a related note, when it refreshes like this, it also resets the page, so in those 20 seconds I may have changed the sort order and scrolled down the page. When the reset happens it not only resets the sort order, it doesn't remember my scroll point.

Steps to reproduce:

1. Go to My LBRY | publishes.
2. Choose any sort except for "Newest First"
3. Click on any of your published items.
4. Hit the back button
5. Note that the sort always reverts to "Newest First"

Expected Behaviour

It should remember that I changed the sort order.

Actual Behaviour

It forgets the sort order.

Suggested Solutions

I would vote to remember the sort order of both Downloads and Publishes, even if I'm clicking between them or away to Explore or Subscriptions (not just for back). The user changed the sort order for a reason, the page should honor that. Also, when resetting the page it should remember the sort order as well as the current scroll position on the page.

System Configuration

• LBRY App version: 0.25.0
• LBRY Installation ID: 8jTfoiRnN7Gux5LUhcAb5Twq3cU4XVhnoF4Y6nr6mVVjP6piiRwXBxt2stQc6xAKfE
• Operating system: Windows 10

[tzarebczan]

Thanks for filing this @42degrees ! Similarly, we should persist these filters in other areas of the app, i.e. https://github.com/lbryio/lbry-desktop/issues/1154

[jessopb]

I have spent some time researching this and https://github.com/lbryio/lbry-desktop/issues/1154
It seems like there is a choice to create a new state object in local app redux state, or to just use the existing navigation object that records, for example, scrollY.

edit*: The problem is that scrollY is only retrieved using the history navigate back/forward buttons, and not by independent sidebar navigation. The below will not work in the latter case.

So it looks like this requires building a new state object for all persisted presentation options, or changing the way navigation state recording works.

My previous idea was:
Supposing the best choice is to persist during the session in the navigation local redux object. This will involve:
1) an action in src/renderer/redux/actions/navigation.js

• named doRecordFiltered type ACTIONS.LIST_FILTERED in ,
• future requirements may ask for a doRecordSorted as well
  2) a reducer in src/renderer/redux/reducers/navigation.js
• that assigns filterString to filterState: string in the local app navigation state object
  3) In any target list component (fileList, transactionList, etc)
• import appropriate selectors and reducers as app/index.js does to handle doRecordScroll.
• component's handle*Changed method dispatches doRecordFiltered with the filter value.
• Props type and object are updated to include a ?filterState property
  4) lbry-redux needs ACTIONS.LIST_FILTERED action type constant. lbry-redux need not be involved

Will update soon.

[kauffj]

@seanyesmunt or @skhameneh can you provide clarity or guidance for @jessopb on this? Let's not leave a good contributor hanging!

This seems roughly correctly, though I may disagree with this part:

So it looks like this requires building a new state object for all persisted presentation options, or changing the way navigation state recording works.

My thought would have to store them in state in either:

• The same place settings are stored (settings.file_download_sort_order or whatever)
• The same place the most closely data type is stored (wallet.transaction_list_sort_order)

[kauffj]

Also, when this is done, I'd suggest that these become independent components as well <SelectTransactionListOrder>, <SelectDownloadedFileListOrder>, etc.

If they were all in settings, you may even be able to do something like this:

<SettingSelect setting="transaction_list_order" values=values>

[seanyesmunt]

@jessopb Sorry about that!

I don't think it makes sense to include this in the navigation state. I agree with @kauffj that it would be fine in either settings or wallet. My suggestion would be wallet since this is something that android app might want to do also.

[seanyesmunt]

Actually after going over this issue again I think the wallet reducer makes sense for transactions sorting, but not for "your {publishes, downloads}"

Maybe that toggle should live in the file_info reducer?

[jessopb]

My plan is to move forward in lbry-redux:wallet and lbry-redux:file_info the way @seanyesmunt seemed to be leaning (nobody objected to file_info), and a <FormPresentationSelector> (common/form-component) that takes as props 'options: []' and 'presentationSelection: string' as @kauffj suggested. I think I'll turn the list of <options> in the transaction filter into a map: Object.values(TRANSACTIONS).map(tt => (<option value={tt} >...</option>)) which, tested, works.

I'm interested in any votes or comments on better names.
Should the standard be doSet/GetThing vs doVerbNoun vs just doNoun?
`
ActionTypes:
wallet: SET_TRANSACTION_LIST_FILTER | TRANSACTION_LIST_FILTERED
file_info: SET_FILE_LIST_SORT | FILE_LIST_SORTED

Reducers:
wallet state: transactionListFilterSelection: string
file_info state: fileListSortSelection: string

Selectors:
wallet: selectTransactionListFilterSelection
file_info: selectFileListSortSelection

Actions:
wallet: doTransactionListFilterSelection | TransactionListFiltered ?
file_info: doFileListSortSelection | doFileListSorted ?
`

[seanyesmunt]

Sounds great.

I think as far as naming goes, we have been sticking with the doSet/GetThing, and SET_XXX. Everything else looks good.