querystrings in state

The docs say

Intentionally we have chosen to solely support paths since they are best for SEO and keep the API minimal. You are free to use query strings to request data in your thunks.

This is a bit hand-wavy; I think it could be more helpful to explain what the intention is for thunks.

• Should they be reading the querystring from the window.location object? If so, how is SSR indtended to work with querystrings?
• Is the querystring stored in an undocumented part of the reducer state? If so, it should be documented.
• Are thunks supposed to access the querystring in some other way?

[kyeotic]

I think that is really going to complicate Components that do rely on querystrings. The querystring is part of the URL and an important piece of the state of pages that rely on them, like search pages. If the goal of this library is to say “Don’t use URLs, don’t think about the browser location, just use your application state” then not storing the querystring means you either can’t use querystring’s at all or you are violating the primary tenant of the library. Neither of those seem like great options.

To take it further, say I do get the querystring from some other place (like window.location), I am probably going to break the ability to replay/rewind redux actions. Will redux-first-router correctly restore querystrings to the URL if I use the back action? What about the url hash?

I don’t see how you can control the URL and but ignore querystrings; they are part of the URL.

[kyeotic]

Search results are the big one. If I perform two searches the back button should take me back to the first search. If the search is simple I guess you could still express that as a path component, but if the search is complex (multiple attributes) that would get difficult fast.