rankings shouldn't (exclusively) use search params

[lumenkeyes]

From reading the code a little bit, (frontend/src/lib/search.ts) it seems like stract uses the search parameters, and only the search parameters, to determine a user's ranking/block preferences. As far as I can tell, a ranking store is already implemented and used by the like/dislike/block modal. I would propose that the results page fully utilize this store for a more consistent experience (and shorter, more readable URLs).

Currently some use cases are infeasible for the end user if they also want to keep their ranking preferences, such as using stract as a custom search engine from the search bar in e.g. Firefox. Since the &sr param seems to change every time the user updates their ranking preferences, it is impossible to use a consistent link, which is required for custom search engines.

Currently, if one uses stract as a custom search engine with a simple url like https://stract.com/search?q=%s, blocked sites appear in the results, but when one opens the modal for the offending result, the block option is already highlighted.

As a matter of personal opinion, it seems like a bad idea to store preferences in URL params at all, but at the very least this workflow/usage pattern should not be required, especially when the modal is already using the svelte store.

[mikkeldenker]

I agree, this was a bad design decision and I've been meaning to change it.

The idea was that it would improve the browser history as blocking a site wouldn't retroactively change previous search results. This would also make it more consistent with the other parameters such as the chosen region which is also sent as a GET parameter.

In practice it has added a lot of unnecessary complexity and bugs as the one you describe here. Another potential problem is that the maximum size of urls is not specified and depends on the browser, so very big sr fields could potentially cause some unknown problems down the line. This does not seem worth it in retrospect compared to the minor upsides.

I think we should remove the sr parameter entirely as you propose and rely on the svelte store for this instead.

[oeb25]

Would there be a way to use site rankings on the initial sever-side rendered search results? Without storing them in a cookie or server-side (and thus referenced by a cookie or similar) I don't see a way of affecting the results when using, for example, the browser search field.

Having the search ranking as part of the URL at least makes it clear (too some extend) that fresh search made from outside stract.com is different from one made from the search bar on stract.com.

I'm not saying that keeping it as part of the URL is the only option, but I think there's a deeper issue of when search rankings are applied and when they are not, which could lead to confusion.

One idea could be to have a small indicator that says whether or not a search was done using site rankings, and when not, allow users to click this to redo the search with the rankings applied. I think even the issue applies to optics, right?

[mikkeldenker]

I don't think this is a problem given how the search flow currently is on main. The search now always happens client-side unless a specific ssr field is set on the request, in which case the search is only performed on the server. Search during SSR is now mostly used for environments where js is disabled and allows us to show something to the user before the results are ready when js is enabled. This flow should also allow us to apply site rankings and optics when the search is issued through the address bar.

The only downside I see is that there is no way to apply site rankings in noscript environments without keeping the sr field, but given that the modal already isn't shown in this case and the the current sr format is quite obscure, I don't think this will be a huge problem.