More lobbying for state in URL…

[tordans]

I notice again and again that managing state in the URL is still underrepresented in React and not talked about (enough).
Maybe this quick post will motivate someone to write about it more or maybe join one of the many Podcasts to give this important UX feature some visibility.

Here are two things that make me come to this conclusion:

Managing state in URL is different for each React environments (framework). When I want to share global internal state, I can use Zustand or one of many libraries that work across Astro, React, NextJS, … and so on. The way I write React to manage state in all those environments is the same. — This is very different for shareable URL state management. For NextJS there is this great library. For Astro there is something else. For a plain react app I can try using the Router based search param solutions … and so on. — Why is this? My take is, the URL state mangement ecosystem is just not was big as the internal state mangement. Which is why I think talking more about why it is better to have state in the URL in most cases ist so important, IMO. Another reason might be that it is far more complex to manage state in the URL than in an internal store … so no common pattern developed, yet.

Which is what brings me to my second part:

The educational crowd does not speak about state in URL enough. Look at this nice flow chart "Picking a React State Approach". It does include managing state in URL to make it shareable, which is great. Quite a few resources don't mention this approach at all. But it falls short right after. There is no detail on how to do this. No library list, nothing. It suggest it is super easy to do so… but it is not.

---

What would be good places to lobby for URL state?
A few things that come to mind are…

• https://topenddevs.com/podcasts/react-round-up they have guests that talk about their topics
• https://www.youtube.com/channel/UC6vRUjYqDuoUsYsku86Lrsw Jack creates great quick deep dives into topics
• … other?

[franky47]

Thank you for this! I've pinned this discussion for visibility.

I have started giving talks at conferences and meetups about this subject (will post video links when they're up), and I'd love to talk more about it in podcasts too. Thanks for the links, I'll have a look and reach out.

The crux of it is that in-memory state (useState, Zustand/Jotai/Redux/younameit) is locked in both space and time. Freeing it by putting it in the URL allows it to:

• Survive page reloads, but also being recalled from bookmarks (time travel)
• Being transferred to another device (teleportation)

The URL is a superpower.

[jazsouf]

One other thing to take into consideration, is where does your state live.
If your state is close to the root of your page, using searchParams will make your page render dynamically, and that might not be what you want.
So if you really want to use the url in this case, better create a whole new param segment. Otherwise, just use state solutions inside react.

[tordans]

Personally, I consider this a bug and not something that should be part of the main decision tree. #574 (comment) has some more on it. Other libraries don't have the same issue (#574 (comment)). — I do agree, though, that in some cases, performance might be more important and in those cases, URL base state is not really possible in NextJS ATM.

[jazsouf]

Okey, I didn't think it was possible for other libraries. I raised an issue one day about this. It is conceptually possible to have a function called generateStaticSearchParams, kind of mimicking the generateStaticParams already available for ISR. But I think the Nextjs team have other priorities for now.