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

61–70 of 416 posts

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

#61

Post by refulgentis »

G3rn0ti wrote: post #44
bckygldstn wrote: post #14

Earlier quoted context omitted.

It seems to vary greatly by browser. Based on this SO answer [1] MS edge only supported 2000 characters in 2017, while Chrome currently handles 40 million characters (of compressed, encoded json). [1] https://stackoverflow.com/a/44532746

Weirdly, with IEs it was exactly 2083 characters (1) not some base 2 number and MS never increased this number over all these years. This upper limit even included fragments. We tried to do something similar as described in the article and were surprised to learn about IEs limitation. In the end, we stored states on a JS object instead using their hash sum as keys and put that inside the fragment. Then fragment based…

I don't quite understand and it's on me, trust me :)

My reading is you were worried about length of encoding one state, so you moved to encapsulating states in a dictionary with keys of hash of State and objects of State

And this led to a decrease in size of the URL?

My guess at my misunderstanding: you kept the state dictionary server-side or at least some other storage method than the URL, and just used the URL to identify which state to use from the dictionary. I e. The bit you add to the URL is just the hash of the state, or dictionary key

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

#63

Post by easrng »

mperham wrote: post #41

I recall this technique being used in 1999. It doesn't work well with caching proxies which key off the URL, using a Cookie header is cleaner and simpler.

Caching proxies which key off the URL are pretty much useless now because they don't work with HTTPS.

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

#64

Post by jonny_eh »

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…

> You can make the state unique in the DB by a user cookie ID

https://gdpr-info.eu/

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

#65

Post by AndrewStephens »

typingerror wrote: post #55
AndrewStephens wrote: post #16

This is pretty common and has a bunch of advantages, like the fact you can link to and bookmark a particular state. Also, if you are careful you get undo and redo for free with the browser's back button doing all the work for you. The disadvantages are that your representation of internal state becomes part of the interface - if you ever change your app you need to deal with versioning the state so your new version c…

> 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.

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

#67

Post by EGreg »

ddyevf635372 wrote: post #9
EGreg wrote: post #5

It’s actually difficult to do this in the UX. Suppose that you have a hierarchy that was opened. Do you want to store all the hierarchy breadcrumbs in case you hit refresh, and reload all of them? Furthermore, what about URLs to initiate an action from a particular context? If you refresh what should it show? It should show a dialog / lightbox above the page, showing the form / interface for filling out before taking…

Routes are the fundamental building blocks of a webpage, so the hierarchy will be represented by the routes in the url. Proper frontend framework, like Ember.js, built on top of routes and building a UX focused web app is much easier with them. https://guides.emberjs.com/release/routing/

Your link and the explanation there is not enough. It only shows the current resource you are looking at. As I said above - you should also consider representing the breadcrumbs of how you got there in the hierarchy (you could have taken multiple paths) and also on top of that use URLs to represent actions that can be taken in dialogs !

Here is a question for you: what happens when you have a url for a New Issue in github? By itself. It renders a form for a new issue full-page. But now what if I want it as an overlay over a hierarchical state that U navigated to? I should have a longer URL and it wouldnt be full screen anymore.

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

#68

Post by enos_feedler »

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…

So you think of a new feature "X". That feature has a bunch of state it needs to manage. Each piece of state has _requirements_ over where it fits within this hierarchy based on how this state relates to the feature being developed. I don't understand where the cost lowering is? I know instantly where the state should live when I design the feature.

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

#69

Post by notRobot »

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.

This looks very cool, and I'll definitely use it in a side project sometime soon!

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

#70

Post by michaelteter »

As long as your users are reasonably tech-saavy this is ok. But long URLs can be problematic when sent in email for many possible reasons, such as the email client wrapping the URL and then creating a link out of just part of the original URL. The user sometimes doesn't realize this and gets unpredictable results when trying to use the URL they "saved" in the email.

Perhaps instead, assuming the user is online, hash the json state data, then send the json+hash to the server and update the URL to URL?hash. Then the user has a much shorter URL, and the server can lookup the json state from the provided hash to resume the app at that state. As a bonus you then have versions of the data over time (either posted automatically in the background or on-demand when the user clicks Save).

Post reply on HN