Earlier quoted context omitted.
[flagged]
A horse walks into a bar. Several of the patrons quickly get up and leave, realizing the potential danger in the situation.
Thank you for posting a joke to HN. Thank you for making me laugh today.
How to store your app's entire state in the url
251–260 of 416 posts
Re: How to store your app's entire state in the url
#252Earlier quoted context omitted.
> 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…
not my fight, but you literally wrote: > Seems like it could be better Maybe you didn't mean it that way, but it does come across that way. Just a data point for you; I got no beef...
oh I guess I did. thanks. should have said "I wonder if its better".
Re: How to store your app's entire state in the url
#253A better idea is to use the URI fragment (the string after the # sign). It has the advantage of not having a size limit, and not needing to be sent all to the backend during the request. `window.location.hash` is your friend.
I wrote a library based on that very idea. It supports fragment query, just like normal queries. https://github.com/Cyphrme/URLFormJS I use it in a lot of places, like: https://convert.zamicol.com/#?inAlph=Text&in=Hello%20world!&... https://cyphr.me/ed25519_applet/ed.html#?msg=Hello%20World!&... https://cyphr.me/coze#?verify&input={%22pay%22:{%22root%22:%...
How to use this in React?
Re: How to store your app's entire state in the url
#254Earlier 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…
> were surprised to learn about IEs limitation
IE was all about limitations Nothing surprised me about IE limitations.
Re: How to store your app's entire state in the url
#255The early 2000's called, they want their ASP pages and IIS license back
Re: How to store your app's entire state in the url
#256Earlier quoted context omitted.
you could come up with a better compression scheme given that the dict keys and many of the values are probably common across everyone even if they don't repeat multiple times for a given user. a lot of flexibility would be lost though, and you would need to always update the scheme in a backwards-compatible way.
would it be feasible to include the compression dictionary along w/ the data? And, maybe just send it once on the initial request and store it on the client?
> would it be feasible to include the compression dictionary along w/ the data
In theoretical terms (in particular Kolmogorov-complexity perspective), I believe the inclusion of a dictionary wouldn't help, it would strictly increase size. It can help (specially from a Shannon information perspective) if the compression is too computationally demanding to build the data model (which is kind of what all compressors do); but it almost certainly doesn't help in the case of something as small as an URL. But then it's possible to just pack a common compressor with the website (and just refer to it with a version code).
I think the web in general would benefit greatly from some kind of standard compression libraries. Compression tends to have a significant cold start cost to work well, if that were mitigated certainly something like an url could be far shorter.
I believe HTTP2 has header compression (RFC 7541)[1] with 'static tables', which seems to be a form of dictionary, but surprisingly to me no html compression with such shared dictionaries. There is caching libraries (unfortunately cross-domain caching seems to be deprecated[2] due to security concerns) I believe which helps in other ways, but I think a true dictionary-style compressor would bring huge bandwidth savings.
Major web entities should get together to develop those standard dictionaries (and which algorithms to use them with), so they are reasonably fair for everyone (maybe even language specific dictionaries should be used).
Security seems indeed a concern, but I think the key would be carefully preventing that a content were decoded with the incorrect dictionary (meaning the server could serve a different web page than the standard decompression) -- but overall it doesn't seem like a big issue (similar to cache, less problematic than cross-domain caching).
In the future maybe even one of those fancy neural network (or otherwise machine learning inspired) methods could be an option, specially useful for highly bandwidth constrained like rural or satellite internet (although of course performance is always a priority with mobile devices being major users).
[1] https://httpwg.org/specs/rfc7541.html#static.table.definitio...
[2] https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca... Is this still accurate?
Re: How to store your app's entire state in the url
#257relevant to mention the new tan-stack router that does this: https://tanstack.com/router/v1
Re: How to store your app's entire state in the url
#258Earlier quoted context omitted.
Would have to do the signing server-side, predicated on the server checking the entire state to ensure validity. Such effort being put into preventing parameter-hacking would suggest there are serious vulnerabilities in that website. The URL is meant to be modified by the client.
> The URL is meant to be modified by the client. Clarification, the human user probably won't want to modify the URL, but the client will.
With something nice like the Google url, I would happily modify it myself.
Re: How to store your app's entire state in the url
#259I love stuff like this. Around 2008 or so I was working on a Java game for the T-Mobile Sidekick (aka hiptop). The platform let you register url scheme handlers so I registered "drod" (the game was a from-scratch port of Deadly Rooms of Death, a classic shareware game). Since the game was a 16x16 grid-based game with 3 layers, it was super efficient at expressing levels, including monsters and locks and keys, with just a limited number of bits. On my website I had "DLC" in the form of drod://[base64 encoded level here]. It always filled me with joy that users already downloaded the levels when they navigated to the website. Clicking the link just opened the game with the data they already had on their device.
Re: How to store your app's entire state in the url
#260Earlier quoted context omitted.
I’d say everything after the host is part of the UX, and should serve the user needs. For example: * Should be book-markable. * If searching with a query, should have a clear query parameter for ease of browser integration. * If the URL contains slash dividers that can be read as categories (e.g. storefront.com/department/category/product), then deleting everything after a given slash should go to that category’s pag…
* I should be able to guess if you're sending me a link about composting or a Rick Astley video Opaque slugs are problematic in a low-trust world. Phishing attempts are easier when the parameters are indecipherable. I'm not clicking on that shit in a text message or an email. I've seen what happens to people when they do.
Eh, I mean URL shorteners are a thing and all kind of things redirect on the web. The length of the URL doesn't really tell you much.