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

371–380 of 416 posts

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

#371

Post by moonchrome »

NavinF wrote: post #337
TeMPOraL wrote: post #266

Earlier quoted context omitted.

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

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.

Clojure uses [] and {}, eg. :

  (defn fib [x, n]
    (if (

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

#372

Post by bsima »

TeMPOraL wrote: post #263
hk__2 wrote: post #234

Earlier quoted context omitted.

Speaking about LISP and state in the URL, this is how OVH stores the state when you buy a domain from them: https://www.ovh.com/fr/order/webcloud/?#/webCloud/domain/options?selection=~(domains~(list~(~(name~'somethinghn.com))~options~(~'dnssec)))

That's Clojure's EDN encoded for ClojureScript isn't it? I recognize this syntax from briefly working on a CLJ/CLJS app.

Nope, edn uses square brackets and doesn't have a `list` keyword. This is some custom representation.

Probably written in Common Lisp? Based on some quick searching I found this reference https://docs.ovh.com/us/en/web-paas/languages-lisp/

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

#373

Post by pacifika »

PUSH_AX wrote: post #137
anshumankmr wrote: post #105

Earlier quoted context omitted.

> https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6... Dear god... this link was real. I thought it was like a joke or something

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?

Pipe that into bash (ie: the user doesn’t know if they’re loading malicious state)

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

#374

Post by gnramires »

gnramires wrote: post #256
waynesonfire wrote: post #123

Earlier quoted context omitted.

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)…

> would benefit greatly from some kind of standard compression libraries

Correction: standard compression dictionaries

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

#375

Post by naasking »

rsync wrote: post #145
A4ET8a8uTh0 wrote: post #118

Earlier quoted context omitted.

Harder. Not impossible. Harder. I don't want to make it sound like I am being disagreeable just for the sake of being disagreeable. If there is one thing the past decade has shown, it is that hacking is just a matter of time and whether a determined person is willing to direct resources at it.

I see you, and raise you: What if they encrypted the parameters with a one-time pad ?

One-time pads have to be stored server-side. If you're going to do that, you might as well just store the data itself under a GUID server-side so you avoid network transfers and then put the GUID in the URL.

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

#376

Post by naasking »

hot_gril wrote: post #213
AndrewStephens wrote: post #170

Earlier quoted context omitted.

> URLs aren't meant to be used this way I disagree, URLs are supposed to point to a resource - in this case the resource is the client state of the app (aka "deep linking"). It is a useful approach. Of course, it can easily be misused.

The suggestion was to put your entire client state into it, which is probably more than just the resource location (aka deep link).

There is no such thing as "client state" separate from the notion of resource under REST. The URL is meaningful only to a server. If a server can encode data in the URL so it doesn't need to persist it, that's perfectly fine, so long as the URL conforms to all expectations of resources, ie. caching directives, lifetime, etc.

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

#377

Post by [deleted] »

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…

[deleted]

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

#378

Post by wildrhythms »

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 would you predefine a state to include the flowchart nodes that the user creates?

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

#379

Post by wildrhythms »

firstbabylonian wrote: post #317
numair wrote: post #271

Earlier quoted context omitted.

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…

How do we go about passing this kind of historic knowledge between generations of engineers? In my observation, most newcomers to the industry are trained either academically or through self-guided practical learning, i.e. by hacking and reading tutorials. Neither method exposes them to such 'contemporary history' of innovation within the field.

I got a Compsci degree and we did in fact learn some history, figures like Grace Hopper and Alan Turing, how punched card computers worked (we even got to make our own punched cards!) Obviously people who are passionate about computers will find such history very interesting; the newcomers with dollar signs in their eyes won't care, they just want to 'make an app'.

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

#380

Post by wildrhythms »

barbazoo wrote: post #87

> Another great benefit is that these urls can be embedded. That means the user can put their graph on any ewb page that supports embedding. I see people typically do this with wikis like Notion, which means you can share with a team This is so valuable that it can't be overstated. Being able to store the raw data in a link WITH the visual representation, you'll never struggle trying to find out who has the latest ve…

Bingo. I use this all the time to let users pass preconfigurations of internal tools back and forth. These are tools that live on the client and don't have a backend. The downside is my users complain about 'long/ugly links' which is another problem...
Post reply on HN