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

351–360 of 416 posts

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

#351

Post by dncornholio »

tempestn wrote: post #320
b112 wrote: post #272

Earlier quoted context omitted.

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.

Agreed. However they could still simplify the urls a ton by including only non-default parameters, and still achieve the same thing.

And what problem does this solve? Hint, it doesn't. Long URL is ugly but who cares. Life is too short. Nice or ugly is relative. It stops nobody from using the tool or sharing links. It's a non-problem really.

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

#352

Post by dspillett »

dhosek wrote: post #291
anotheraccount9 wrote: post #130

Earlier quoted context omitted.

A horse walks into a bar. Several of the patrons quickly get up and leave, realizing the potential danger in the situation.

A priest, a rabbi and a minister walk into a bar. The bartender say, “What is this, a joke or something?”

A priest, a rabbit, and a minister, walk into a blood donation clinic. The rabbit says "I think I might be a type-o".

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

#353

Post by [deleted] »

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…

[deleted]

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

#354

Post by xmprt »

TeMPOraL wrote: post #348
NavinF wrote: post #337

Earlier quoted context omitted.

Well yeah that's a major reason why most programmers hate LISP syntax. It uses a parentheses for everything even though every keyboard has round, square, angle and curly braces.

I somehow doubt it. I tutored quite a few people of all ages who started to learn programming, mostly C, C++ and Java - they all initially have been mostly confused by the different kinds of brackets. They quickly understood where the brackets go (scopes/blocks, function calls, array declarations and access, etc.), but took some time to internalize which bracket type is used in which context. I suspect the main reaso…

I suppose beginner programmers might find all the different kinds of brackets in C++ confusing but after some experience, it helps a lot with readability. If I see `a[1]` then I know that `a` is probably an array. If I see `a(1)` then I know that `a` is probably a function. You could make the argument that those are terrible names for variables and methods and you'd be correct, but every small bit of context helps.

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

#356

Post by matthewmacleod »

ajuc wrote: post #342
bboygravity wrote: post #293

Earlier quoted context omitted.

That's genious IMO. Making sure the amount of opening and closing parantheses is equal is annoying and unnecesary. It screams "trust me all good with the closing parantheses".

if ((v1.x()-v2.x())*(v1.x()-v2.x())+(v1.y()-v2.y())*(v1.y())-v2.y())+(v1.z()-v2.z())*(v1.z()-v2.z()) > distance*distance) { // collision } Would you like this to fail to compile? Or would you prefer it to silently return the wrong value?

I'd prefer the compiler file an HR complaint against the author.

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

#358

Post by pifm_guy »

michaelmior wrote: post #166
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…

In your example, absolutely the first URL is better. But if as in the case of the OP, you're trying to encode an entire flowchart, I would argue it's a bit of a pointless exercise. Maybe you could come up with something reasonably readable, but I don't think anyone would care. It really depends on what kind of state you need to store.

A flowchart can be encoded as simply the name of the state you're currently in.

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

#359

Post by michaelmior »

pifm_guy wrote: post #358
michaelmior wrote: post #166

Earlier quoted context omitted.

In your example, absolutely the first URL is better. But if as in the case of the OP, you're trying to encode an entire flowchart, I would argue it's a bit of a pointless exercise. Maybe you could come up with something reasonably readable, but I don't think anyone would care. It really depends on what kind of state you need to store.

A flowchart can be encoded as simply the name of the state you're currently in.

How do you know what all the other states in the chart are and how they are connected?

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

#360

Post by michaelmior »

moffkalast wrote: post #262
michaelmior wrote: post #166

Earlier quoted context omitted.

In your example, absolutely the first URL is better. But if as in the case of the OP, you're trying to encode an entire flowchart, I would argue it's a bit of a pointless exercise. Maybe you could come up with something reasonably readable, but I don't think anyone would care. It really depends on what kind of state you need to store.

Whoever needs to copy that long intestine of a url definitely cares.

If you can shorten the URL, sure. But if data stored in the URL means it needs to be incredibly long, I don't think most users care whether it's readable or not. Of course, at a certain length, it's worth reconsidering whether storing all the data in the URL is a good idea.
Post reply on HN