navigate through searches via browser history

[Jan-Ka]

This resolves #7 and possibly #22 .

Things I tested:

• From an external Site open primerpedia without search
• From primerpedia without search
  • do random search
  • go back to primerpedia without search
  • go forward to random search
• From primerpedia with search
  • go to external Site
  • go back to primerpedia with search

I think that should be all use cases? It "felt" natural and did what I expected.

[waldyrious]

Actually, there's a small ambiguity that we should resolve: the URL parameter doesn't show the search term, but the article title instead. In fact, a search term that provides no results does not update the URL at all.

I agree this behavior makes sense, but that probably means the URL parameter should be changed from search= to page=. Any objections?

[Jan-Ka]

No, not at all.

[waldyrious]

I've actually just now noticed a behavior related to this that we might want to address: when I enter a search term, the search box keeps the entered text, but the URL shows the title of the page; if I then click the random link twice, the URL changes each time to reflect this, and the search box is emptied. All this is fine and expected.

But if I now click the back button on the browser, the search field gets filled with the value of the URL, which is redundant for pages loaded via the random function, and is incorrect for pages loaded via the search function (since the search terms typically do not match the title of the article exactly, even if only in capitalization).

I'm wondering if we shouldn't set the url parameter to search= and page=, respectively, in order to be able to make the interface behave as expected in both cases, i.e. only fill the search box automatically for pages loaded via search, and show the search terms rather than the actual article title.

Does that make sense? (If so, we should probably open a separate issue to track this. Also, it would likely impact the implementation of #42.)

[Jan-Ka]

It took a while but it makes sense.

The only problem that comes to mind occurs when both parameters are present. I don't see a way to respect both at the same time without either just blindly writing the search back into the search input without triggering a search or executing a search and hoping that it results in the same page (which most of the time it probably will) but if you request something like ?search=united_states&page=canada there's nothing we can do beside just favoring one of them.

Maybe a better implementation for the original issue would be to replace the history entry with the found page (thus changing the URL from ?search=something to ?page=some_thing. In which case I would favor search= before page= because the first one is dependable.

Anyhow, I would create a new Issue for this matter. It's a refinement of a now existing feature :) Hooray for progress!

[waldyrious]

if you request something like ?search=united_states&page=canada there's nothing we can do beside just favoring one of them.

Yes, indeed.

writing the search back into the search input without triggering a search

This sounds like the most natural behavior to me.

Maybe a better implementation for the original issue would be to replace the history entry with the found page (thus changing the URL from ?search=something to ?page=some_thing. In which case I would favor search= before page= because the first one is dependable.

IIUC that's aligned with the behavior outlined in the two quotes above; please confirm.

Anyhow, I would create a new Issue for this matter. It's a refinement of a now existing feature :) Hooray for progress!

Yes, I was just making sure we were on the same page (heh) before doing so. I'll create it now.

[Jan-Ka]

There is a slight difference I did not manage to make obvious.

If the url is ?search=united_states&page=canada, I would drop the page parameter and instead trigger a search for the contents of search, which would of course be put into the search input.

When the search succeeded, I would replace the current URL (and history entry) with ?page=united_states_of_america. The search input is still around because we do not clear it.

Coming back to or entering a url with a page parameter will not put anything in the search bar since In my understanding we do not search for the page but just open the result again.

Keeping the search information around does nothing for us (that I can think of at the moment). I can repeat them of course by calling the url with an appended search parameter.