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

271–280 of 416 posts

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

#271

Post by numair »

threeseed wrote: post #180

This technique goes back to the late 90s where Apple WebObjects (owned by NeXT at the time) pioneered this approach in their web framework. https://en.wikipedia.org/wiki/WebObjects Was quite revolutionary at the time and it also included the first (or one of the very earliest at least) SQL ORMs.

You’re the first and only person to point out this fact, which shows how depressingly little history is studied by people who work in this field. It’s a shame it’s become about getting to The Money as quickly as possible…

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

#272

Post by b112 »

munk-a wrote: post #157
PUSH_AX wrote: post #137

Earlier quoted context omitted.

Genuinely curious to hear why you are so shocked. Long, ugly, user unfriendly urls are really prevalent. Arguments can be made even query params are pretty ugly.. Are urls expected to be a good UX these days? What's the big deal?

Just because a thing is prevalent doesn't mean it's good. I have a hard time believing all those parameters are completely necessary for the amount of data being displayed. Often times it feels like people just base64encode(page.state) and call it a day. I think it's advantageous to keep the complexity and specificity of information in URLs to a minimum outside of what's needed to retrieve the data set as it can make…

I can say that many, many times, I have zoomed in, picked date ranges, added options, then pasted the yahoo finance url to others... and they have all those same configs passed.

It's awesome and incredibly handy.

Yahoo is on the ball here.

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

#275

Post by wtetzner »

mikepurvis wrote: post #140
dyno12345 wrote: post #119

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

Once you've already given up on human-readability, it probably doesn't much matter how long/gross the result is. Rather than spending effort and adding complexity, just provide a built in URL shortener.

Well, there are limits to the lengths of URLs in much of the internet’s infrastructure, so better compression could still be useful.

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

#276

Post by galaxyLogic »

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…

Right no need to put it all in the URL, it could be just a random key pointing to local storage for instance, if not some cloud database.

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

#277

Post by voidmain0001 »

voidmain0001 wrote: post #228
stnmtn wrote: post #177

Earlier quoted context omitted.

This loses all the benefits of storing all state in the url, which is that it's inspectable by the client. Using a URL shortener still makes all the data stored somewhere in the server

Okay that's not exactly what I had in mind. My suggestion was to implement the same hash both server and client side so that the query string is small and manageable. Don't worry about the state not being fully legible because you will implement the hash decode on the client too. The code will be there for you to peruse.

I've lost my mind. I literally just implemented a dictionary web API the other week and have completely forgotten how I did it. Just forget what I wrote.

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

#279

Post by reaperducer »

a_c wrote: post #134
spullara wrote: post #108

Earlier quoted context omitted.

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…

OT, we used to joke about LISP source code contains mostly brackets. Nowadays we literally store, transform and pass around willy nillily

we used to joke about LISP source code contains mostly brackets.

There was a programming language in the 1970's called SAM76 that didn't care how many closing parentheses you had, as long as it was more than the number of opening parentheses.

So, something like this was perfectly valid:

  a(1+r(em(2)))))))))))))))))))

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

#280

Post by spullara »

TeMPOraL wrote: post #266
a_c wrote: post #134

Earlier quoted context omitted.

OT, we used to joke about LISP source code contains mostly brackets. Nowadays we literally store, transform and pass around willy nillily

I found that joke funny until I realized that, if you sum the count of round, square, angle and curly braces together, your typical piece of C++ or Java code has more brackets than equivalent piece of Lisp code...

Right, but having them all be the same is what people are joking about :) Although I might check the lisp/clojure vs java code on techempower or another rosetta stone like example.
Post reply on HN