internetarchive / internetarchive/openlibrary
Make search sort option sticky by type
- Dominant language
- Python
- Stars
- 6.7k
- Forks
- 2k
- Avg merge
- 2d 14h
- Merged PRs (30d)
- 126
Description
### Proposal
Right now, there are sort droppers on...
(a) search page,
(b) author pages,
and (c) list pages
Every time one refreshes the page, these droppers return to their default selected value.
We'd like to use [locaStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) to keep track of the last selected sort option **per** type (i.e. we should store a different `selectedSorts` value for `searchPage`, `authorPage`, `listPage`, e.g.
```
selectedSorts = { searchPage: null, authorPage: null, listPage: null }
```
We use localStorage similarly elsewhere in our JS: https://github.com/internetarchive/openlibrary/blob/6ff7058a9558d40704ec98c4f4f5e23b7d3e30c3/openlibrary/plugins/openlibrary/js/SearchUtils.js#L42
### Justification
Several librarians, including @seabelis and @mheiman, have told us that now that all sort links are in a dropper, it's becoming more challenging to re-select the sort option they want every time they redo a search.
### Breakdown
#### Requirements Checklist
* [ ] Selecting a sort option should update the selected result for that type in localstorage
* [ ] If a value exists in localstorage and a patron performs a search for a given type, the corresponding localstorage value should be fetched and used / put into the search form as `sort=` `
Contributor guide
Research direction
Start with the sort controls in openlibrary/templates/work_search.html, openlibrary/templates/type/author/view.html, and openlibrary/templates/type/list/view_body.html, then review the existing localStorage pattern in openlibrary/plugins/openlibrary/js/SearchUtils.js. Verify how each page submits its sort value. Done means each type remembers its selected option in localStorage and uses it when a patron searches again.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100