Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stable search query URLs #105

Open
almontg opened this issue Apr 18, 2024 · 4 comments
Open

Stable search query URLs #105

almontg opened this issue Apr 18, 2024 · 4 comments
Assignees

Comments

@almontg
Copy link
Collaborator

almontg commented Apr 18, 2024

This is likely related to the bigger issues around rolling out a more powerful advanced search, but at the moment search query URLs don't appear to be stable -- I was experimenting with linking to a search of "clinton maps" within our new bio of Henry Clinton to direct users to Clinton Collection maps. While the query works as expected, the URL is https://www.argomaps.org/search/?q=clinton, which, when refreshed, reverts to the more simple query on just "Clinton" which is not helpful in this case.

Not sure how complex the solution is but wanted to bring it to everyone's attention.

@alexandergknoll
Copy link
Collaborator

alexandergknoll commented Apr 18, 2024

@almontg

I think I see the issue here. Let me know if this set of steps to reproduce checks out with your experience:

  1. Perform a search query from the home page. This works as expected, taking you to the search results page with the q=clinton query parameter populated correctly.
  2. Perform a new search query from the search landing page. The debounced search field provides new results on key up as a new query is typed. The correct results are shown, but the q=clinton query parameter in the URL stays the same.
  3. When the page is refreshed, the initial search query and results are restored.

This isn't too much of an issue to fix, but whether we fix it depends on how big of an issue it seems. We could push a new query parameter to the browser history each time the search query runs and new results are displayed, but since this happens on key up and might happen many times even as you type in a single new search query, you might end up with a large number of browser history entries to page back through.

Alternatively, we could debounce the browser history push with a larger timeout than the input debounce to reduce the number of browser history entries that get pushed.

Let me know if this makes sense and if you would like me to proceed with some kind of fix @garrettdashnelson !

@almontg
Copy link
Collaborator Author

almontg commented Apr 19, 2024

@alexandergknoll yes that does reproduce the problem -- I hadn't even noticed the search from homepage/initial search distinction, but when I search "clinton maps" direct from the home page it does produce the correct URL! Differ to @garrettdashnelson on fixing this, but in general I'd love to see us put some energy into the search function (esp building out an advanced search function) now that 1.0 is done and live.

@garrettdashnelson
Copy link
Member

Yes, I was going to note what @alexandergknoll has already said: the homepage search box does create a stable URL, which you can see in the q parameter of the URL, e.g.:

https://www.argomaps.org/search/?q=Henry+Clinton

And it's worth mentioning that you can rewrite that q URL parameter to point to any free text query.

Subsequent search edits on the search page don't update the URL parameter, primarily to avoid junking up the browser history, again as @alexandergknoll has described above.

I think there are two possible solutions for this:

  1. @alexandergknoll I could be wrong about this, but I think you can use history.replaceState() to update the query string without adding an entry into the browser history. We could do this after every debounced update to the text.

  2. Alternatively, we could introduce a button that says something like "Copy to this search" which contains a URL with the correct q parameter.

@alexandergknoll
Copy link
Collaborator

Hey @garrettdashnelson - I totally forgot about that history.replaceState() - you are absolutely right. I would advocate for just updating the existing implementation with that. We can add it right inside the debounced callback for the search, which should be pretty easy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants