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

181–190 of 416 posts

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

#181

Post by mhink »

skrebbel wrote: post #91
mhink wrote: post #71

Earlier quoted context omitted.

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…

Unfortunately sessionStorage is not copied over when you ctrl+click a link, and that’s arguably the most common way to “duplicate” a tab. Something about security iirc but i dont grok it. Still an underappreciated browser feature though, esp for class server-side rendered apps.

I'm actually kinda surprised that's the case for links to the same origin. I suppose you could probably still get this working by using `window.opener` along with `postMessage` to request data from the opener, although you'd have to be very conscientious about checking the origin and verifying that the requested data is actually ok to share.

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

#182

Post by _fat_santa »

spullara wrote: post #108
divbzero wrote: post #86

App state in URL can be a good idea, but if possible I prefer readable path/query parameters instead of unreadable base64 encoding. As one comparison, this is Google Finance encoding stock chart parameters: https://www.google.com/finance/quote/F:NYSE?window=5Y Versus Yahoo! Finance doing the same: https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6IndlZWsiLCJwZXJpb2RpY2l0eSI6MSwidGltZVVuaXQiOm51bGwsImNhbmRsZ…

Here is it decoded: {"interval":"week","periodicity":1,"timeUnit":null,"candleWidth":4.3486590038314175,"flipped":false,"volumeUnderlay":true,"adj":true,"crosshair":true,"chartType":"line","extended":false,"marketSessions":{},"aggregationType":"ohlc","chartScale":"linear","studies":{" vol undr ":{"type":"vol undr","inputs":{"id":" vol undr ","display":" vol undr "},"outputs":{"Up Volume":"#00b061","Down Volume":"#ff3…

I suspect it's probably a global library that handles this. So refactoring it in one place would be difficult. If I had to guess their implementation looks something like this.

SomeUrlService.pushState(JSON.stringify({ foo: 'bar' }));

SomeUrlService.navigate('/some/url/here')

Likely, that "SomeUrlService" is also tacking on plenty of other shit to the URL that is passed along. I don't work for Yahoo and never have, so this is all pure speculation.

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

#183

Post by secondcoming »

jwoglom wrote: post #164

Like some other commenters mentioned, this is a cool idea, however by storing JSON data inside base64, the length of the URL blows up very quickly as you start storing more state. While technically URLs have no formal length limit, various sources suggest that URLs with more than around 2,048 characters start causing issues in browsers, and around 8,196 start causing issues in CDNs ( https://stackoverflow.com/a/41718…

Excellent, I was waiting for the protobuf suggestion.

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

#184

Post by slivanes »

nanidin wrote: post #156
slivanes wrote: post #126

Earlier quoted context omitted.

base64 does not have the problem here, iMessage has. Frustrating.

Curious if English is your mother tongue, and if so, which locale? As a native speaker of en-US, I would write this as "base64 does not have the problem here, iMessage does."

Originally en-AU. I was trying to match the "have" with a "has". My sentence has a truncated " the problem" in my head.

Your version reads more correct, thanks for pointing it out.

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

#186

Post by secondcoming »

misnome wrote: post #59
IYasha wrote: post #54

I'm not into web "programming", but do people really have to abndon binary data storage these days? I think compressing more informaiton produces still more information. While JSON is by no means as heavy as, for example, XML, it's far heavier than just array of int graph[x][y];

A colleague has been tasked with writing a remote image viewer. It’s slower than before (running on the same machine) “because it’s client-server”. Naturally, the 16 Megapixel images are sent as an array of json floats…

Unless it's still at a proof-of-concept stage, that person is out of their depth.

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

#187

Post by thewisenerd »

divbzero wrote: post #86

App state in URL can be a good idea, but if possible I prefer readable path/query parameters instead of unreadable base64 encoding. As one comparison, this is Google Finance encoding stock chart parameters: https://www.google.com/finance/quote/F:NYSE?window=5Y Versus Yahoo! Finance doing the same: https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6IndlZWsiLCJwZXJpb2RpY2l0eSI6MSwidGltZVVuaXQiOm51bGwsImNhbmRsZ…

ah, azure does the same for generating the "share" URL for their cost dashboards.

it additionally gzip's the data to compress it futher, with.. some savings..

in the above example you've shared, gzip would've,

  orig=1177
  base64=1572
  gzip(orig)|base64=768

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

#188

Post by aplummer »

cwt137 wrote: post #131

A few years ago, I worked on an app where some of the state was kept in the session and some was on the url as GET params. We ran into an issue where some browsers would only accept urls that were less than 1024 chars long. Is that still an issue today?

The limit disappeared after ie9, however can and should are different things here

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

#189

Post by imhoguy »

redleader55 wrote: post #7

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

Mega.co.nz uses that to hide the decryption key for almost decade. You share links but Mega never knows your key because fragment hash is never sent to server or in referrer. Encrypted files are stored on Mega servers but the decryption occurs in JS on the client side, files are decrypted into temporary JS Blob objects in browser then you save them aka "download" locally... a lot of clever tech there. https://help.mega.io/security/data-protection/end-to-end-enc...

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

#190

Post by valvar »

anotheraccount9 wrote: post #133
2ICofafireteam wrote: post #125

Earlier quoted context omitted.

I did once and was told off for adding noise to the discussion by someone who didn't see the irony of their complaint also adding to the noise.

Two chemists walk into a bar. The first says “I’ll take a glass of H2O.” The second says “I’ll take a glass of H2O too.”

Oh no...
Post reply on HN