Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to store your app's entire state in the url

scottantipa.com

Post reply on HN
Print view View original

71–80 of 416 posts

Re: How to store your app's entire state in the url

#71

Post by mhink »

swyx wrote: post #25

This is quickly becoming a standard in apps and it really shouldnt be handrolled since its such a common requirement and easy to get wrong (between serializing/deserializing/unsetting states). In Svelte it is now as easy as using a store: https://github.com/paoloricciuti/sveltekit-search-params in general i've been forming a thesis [0] that there is a webapp hierarchy of state that goes something like: 1. component s…

Note on 2: I haven't seen this get a lot of use (or maybe I just haven't noticed it), but the Storage API also provides a `sessionStorage` object [1] with some interesting properties. Not only are values persisted across same-tab refreshes, but if you duplicate the tab, the session values are copied over as well (but they don't remain linked like `localStorage`). An interesting use case for this, IMO, is for tracking dynamic layout values (like if you have resizable panels, scroll areas, etc). If you keep this kind of thing in sessionStorage, you can refresh or duplicate the working tab and that ephemeral state will carry over, but since it's copied (not shared) the tabs won't step on each other.

1: https://developer.mozilla.org/en-US/docs/Web/API/Window/sess...

Re: How to store your app's entire state in the url

#75

Post by lelandfe »

Zamicol wrote: post #34

We wrote a library for storing application state in the URL. Its novel feature is using fragment query, which prevents the information from being sent to the server. https://github.com/Cyphrme/URLFormJS I would love to see it get more use. Here's a small demo: https://cyphrme.github.io/URLFormJS/#?first_name=Bob&last_na... See my other comment on this page for some other examples of its use.

Does this necessarily prevent the ability to provide in-page anchors?

Re: How to store your app's entire state in the url

#76

Post by devmunchies »

ErrantX wrote: post #37
devmunchies wrote: post #26

Seems like it could be better to store the state in a database and create a unique, short ID that goes in the URL, especially if your doing server rendering (like SSR react or HTMX, or rails/Django) > I also didn't want to store anything on the backend (at least for the free tier). You can make the state unique in the DB by a user cookie ID and then upsert the state which will overwrite older state with the latest st…

I am genuinely intrigued as to why that's better? Especially as in the second part of your comment you restrict shareability/usability significantly from what the author wants to achieve (IE I can't as a free user bash out a diagram and share it, then later do another and share with a different person). In fact the solution is so elegant when you think on it; free account volume is incredibly scalable, zero storage c…

> Especially as in the second part of your comment you restrict shareability/usability significantly

no it doesn't. If my URL is `/thing#a1234` and I share it with you it will load my state for you. If you make a change, it's easy to push a new hash to the url that belongs to you.

> I am genuinely intrigued as to why that's better?

I didn't say it was better. We engineers are supposed to discuss solutions. I ended my last comment with "Just off the cuff thinking".

Re: How to store your app's entire state in the url

#77

Post by WaffleIronMaker »

swyx wrote: post #25

This is quickly becoming a standard in apps and it really shouldnt be handrolled since its such a common requirement and easy to get wrong (between serializing/deserializing/unsetting states). In Svelte it is now as easy as using a store: https://github.com/paoloricciuti/sveltekit-search-params in general i've been forming a thesis [0] that there is a webapp hierarchy of state that goes something like: 1. component s…

Does anyone know of solutions for this in React?

Re: How to store your app's entire state in the url

#78

Post by awb »

AndrewStephens wrote: post #65
typingerror wrote: post #55

Earlier quoted context omitted.

> If your app has a server component that acts on this state, be super careful about acting on it and treat it as you would any other input under user control. I would recommend signing it if it's generated by the server component, and checking the signature when the server component is provided this signed state. For example to do this in Node is quite straightforward. Key generation: const crypto = require('crypto'…

Good advice. For some apps you might also need to protect against replay attacks to prevent the user from reverting to a previous state in a way that you app should not allow (undo'ing a change of bank balance, etc). But if your state is so important it is probably better to not uses these techniques at all and just store the state on the server.

This technique is client-side data only, so updating a client-side state would only appear to revert your bank balance on the UI, but wouldn’t trigger any server-side functions to do so.

If you sent the client state to the server for some type of CRUD action or persistence, you’d need to sanitize and validate it first. And at that point like you said, why not just keep the state secure server-side and not trust the client.

Re: How to store your app's entire state in the url

#79

Post by tlavoie »

somehnguy wrote: post #31
tlavoie wrote: post #12

As usual when I see this sort of thing, I have questions around the security needs of the application. Storing all of this information on the client means that the client has to be trusted to not mess with all of this state. If it's important, it needs to be stored and checked server-side.

Validating data from the client should always be done on the server in that context, regardless of if state is being saved client side or not. I think this is just an extension of what you said though. I can think of many apps that don't need server side data storage or security that would benefit from this type of state saving however. For example, this app that I was using today - https://wheelofnames.com/ . Right…

Sure, there are reasonable use cases. It's worth pointing out where those use cases are not reasonable though, because those devs that don't know better will be inclined to treat obfuscated inputs as if they're trustworthy.
Post reply on HN