Best Practices for URL as State Paradigm (eg. Form Input in URL)

[leovigna]

TLDR

• What are some common "URL as State" patterns?
  • Is this even a recommended way to use Tanstack Router (examples seem to suggest so)?
  • Do you have any suggested patterns? List them below!
• What are some best practices when using Tanstack Router & URL as State?
• What state should be in the URL? What criterion should we use?
• Shoud user input be included in URL as State? If so, how to handle frequent changes (eg. user holds down a key)?

Discussion

URL as State

Using TanStack Router has led me to favor a URL as State paradigm. The ability to simply copy a URL and get the exact(ish) UI is quite powerful. It also removes the headache of passing down props or defining contexts to pass down simple parameters (now typed thanks to TanStack Router).

I think it could be interesting to discuss more the URL as State paradigm and what are some best practices.

Common Patterns

Broadly I think the "URL as State" paradigm can be split into 4 patterns (not exhaustive but I think it's a good mental model). The first two are common web patterns, while the other ones are made possible by Tanstack (not impossible before but horrible DX).

1. Path Parameters as resource ids

• Classic REST API structure to access a resource.
• Access /invoices/$invoiceId

2. Search Parameters as filter/pagination

• Classic REST API structure to query resources.
• List /invoices?limit=10&userId=1

3. Search Parameters as UI State

• Store UI state in URL such as the open/close of a modal, tab selection,
• Not impossible before but much easier to use with Tanstack as this can grow quite complex

4. Search Parameters as Input State

• Store user input (eg. forms) in URL and render accordingly
• See the dashboard/invoices/$invoiceId in kitchen-sink-file-based for an example of user input in a text area stored in URL
• Can be useful for saving state as a URL (for non-sensitive information)
• Poses certain challenges see below section

Best Practices

What are some best practices when using Tanstack Router & URL as State?
I've added some thoughts but feel free to add to this discussion!

What state should be in the URL?

When we say URL as State, we don't really mean that all state should be in the URL (don't wanna leak that jwt token 😆 ), but rather that more state should be in the URL. Things like the selected tab in a page, the open/close state of a modal, all the way possibly up to a user's draft form input.

With various types of state in our web apps, what criterion should we use? I think one mental model is shareable state meaning, any state shared between 2 users that with a link. If user A shares a link with user B, their account info will be different of course, query parameters or tab selection should be shared as they provide consistent UI, the theme state (light/dark mode), could technically be shared as well, but probably shouldn't be, as it would provide inconsistent UX (eg. user B is in dark mode, opens link which switches to light theme).

Shoud user input be included in URL as State?

The ultimate URL as State use case is saving draft user input data. This is fantastic for non-sensitive info as the user can just save a link and pick up where they left off.

However, this can pose some challenges where the UI gets re-rendered too many times (after all this seems to be one cost of using the navigate too frequently). Updating the URL is not a problem when a user clicks a button, or enters one key slowly but if they hold down a key, watch the page slow down to a crawl as React struggles to render the page properly. This can be seen in the dashboard/invoices/$invoiceId example. Try adding a note and holding down a key.

• Should user input even be included in URL as State? Do you agree/disagree?
• If so, how to handle frequent changes (eg. user holds down a key)?

URL Pollution, How much is too much?

One final question, if we decide to push more and more state to the URL, how much is too much?
I think this can depend on your use case but I also think their could be a solutions to minify URLs.

• Does encoding advanced schemas into very long URLs impact UX negatively?
• How does this depend on the target audience (eg. consumer, enterprise) or type of web app (eg. social media vs analytics dashboard)?
• Are there solutions to very long URLs? What could be a pattern to shorten links and still keep them deterministic?
• Highly experimental thought on searchParam complression
  • Hash the searchParams (ideally sort/sanitize equivalent inputs so they provide the same hash), store hash => params in cache so we can get the preimage back
  • Navigate to that hash
  • In loader get the original params back (could be stored locally or even remotely to enable sharing).

My Usage of TanStack Router

Currently, I use path parameters to query various resources (eg. invoices in the examples), and search parameters to configure different states that can range for common web use cases (filters params, pagination). These patterns are pretty standard and I wouldn't really call them "URL as State" as they predate Javascript itself (though they have much better DX today 😉)

I've started controlling some UI state (eg. Modal open/close, Tab selection) using searchParams. I have not yet used Tanstack Router for input state but you'll be hearing from me soon on that topic!

[dissentScript]

I'm really interested in this topic. Thank you, @leovigna , for starting this discussion and describing it so well! I would like to know the pros and cons of using this as a global (UI) state management solution compared to context or redux. Of course, this wouldn't fit for really large-scale apps because of the URL maximum length (around 2000 characters), but for smaller ones, could it be an option?

I think it can also be really useful in the context of micro-frontends, where different micro-frontend apps could communicate through the URL.

[generalzhou]

I'm a fan of this conceptually and my company makes use of this a lot. However, I found that this can lead to performance issues - basically the url is a global state that many many components share. There is no way to only get the 2 query parameters that a single component cares about (I mean you could have a cheap wrapper component get the params, then pass in the 2 params as props to an expensive component that is memoized, but then you're doing a lot of work for every component that needs this and aritificially organizing your code for performance rather than business logic).

Any thoughts on this? I don't see many people talking about this downside.

[schiller-manuel]

There is no way to only get the 2 query parameters that a single component cares about

isn't this solved by fine-grained selectors?

https://tanstack.com/router/v1/docs/framework/react/guide/render-optimizations#fine-grained-selectors

[flodaniel]

We are also big fans of managing state in the URL and TSR makes it really easy to work with.
However we also face performance issues when updating the URL with navigate too frequently (as described by OP for example for draft user input - a user typing into an input field). The navigate causes too many rerenders and beforeLoad functions that need to run again.