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

401–410 of 416 posts

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

#401

Post by WorldMaker »

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

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

To my understanding, that static table in HTTP2 is directly in context of recommending and discussing Brotli compression, which does use a table like that as a standard static dictionary in HTTP2+ scenarios including other static dictionary inclusions derived from a corpus of HTML documents.

https://en.wikipedia.org/wiki/Brotli

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

#402

Post by User23 »

WorldMaker wrote: post #398
User23 wrote: post #386

Earlier quoted context omitted.

You read it by indentation not by counting parentheses.

It's still very easy to make mistakes reading it that way. If you are reading it by indentation anyway you may as well use a parser that closes parentheses for you at indentation changes. (Like the ML family and Haskell and Python all decided to do.)

I don't find reading properly indented Lisp any harder than reading properly indented Python. I agree however with respect to having the tooling help with balancing delimiters, although I let the editor do that job instead of the parser. And that's one of the major advantages of Lisp. Structural editing is considerably easier to implement. Parinfer[1] for example is really cool. I have to say I'm really excited about tree-sitter allowing similar structural editing for harder to parse languages.

[1] https://shaunlebron.github.io/parinfer/

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

#403

Post by naasking »

hot_gril wrote: post #400
naasking wrote: post #376

Earlier quoted context omitted.

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.

Modern web apps often use the URL in ways that only matter to the client and can be edited client-side without issuing another request to the server, unless you reload manually, in which case everything is reset except the URL state. This doesn't violate REST principles. Some of that makes sense to put in the URL so users can return to past state, some is very temporary and wouldn't make sense at all to persist acros…

Sure, and all of that belongs in the fragment of the URL which is not sent to the server but is specifically reserved for client-side resources.

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

#404

Post by misnome »

IYasha wrote: post #336
misnome wrote: post #217

Earlier quoted context omitted.

Yes, yes they are. Unfortunately this is dysfunctional academia, so as long as the people paying the bills (who know nothing about building software) like them, they remain at this depth. Extra fun fact: Two years into the project, they hadn't heard of REST. Then rejected it, because, I quote, "The S means stateless and [they] need the server to store state"

This is on another level! (0_0) Thank you for this example. Makes one rethink things )

I find the experience good for soothing the imposter syndrome!

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

#405

Post by efreak »

hunter2_ wrote: post #306
owl57 wrote: post #284

Earlier quoted context omitted.

At least in Telegram, this works for at most one link per message, and quickly fills the screen if you send multiple such messages. And I believe that there is no standard API to get previews of non-public websites in a work chat, you need to develop site-specific bots or something like that?

> previews of non-public websites It would be interesting if browsers / OSes / apps offered a way to use the browser's cookie jar / basic auth headers / whatever sessioning scheme in whatever apps the user decides should display authenticated previews. Ask the user to allow the release of browser data scoped to the domains that the app suggests. Similar to how some Android apps can put up a prompt to release a Chrome…

Examples of why this is bad:

* http://example.com/settings/transferownership?to=efreak * http://example.com/settings/deleteaccount?confirm=true * http://example.com/sendmoney?to=efreak&amount=10000

Might need a redirect. Do previews follow redirects? Does your poorly-written chat app filter urls by protocol, or does it just look for a token with '://'? A good app will allow me to link to things like steam://connect/IP so I can invite you to a game.

* tel:9005555555 (call a phone number. Fortunately, this requires confirmation these days, but what if you're on desktop or the app that does texting can directly make calls without invoking the dialer?) * steam://exitsteam (steam will exit if it's running)

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

#406

Post by Altho00 »

ninjanomnom wrote: post #340
Altho00 wrote: post #335

Earlier quoted context omitted.

What is the point of the encoding ? Is it obfuscation for the common user ? What's wrong with http:// url.com/api/?interval=week&periodicity=1... since the encoded version is not shorter.

Encoding isn't usually to obscure but to allow using characters not allowed in a URL or wherever text is being stored. This makes it a bit easier to directly take that encoded text later and decode it into something like json.

That makes sense, thank you

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

#407

Post by gnramires »

WorldMaker wrote: post #401
gnramires wrote: post #256

Earlier quoted context omitted.

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

> 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. To my understanding, that static table in HTTP2 is directly in context of recommending and discussing Brotli compression, which does use a table like that as a standard static dictionary in HTTP2+ scenarios including other static…

Thanks, I didn't know Brotli! Indeed it seems to include a dictionary in its compression which seems to help significantly with small pages. I hope compression continues to improve in this way.

> To my understanding, that static table in HTTP2 is directly in context of recommending and discussing Brotli compression

It seems separate, that would be a header compression for HTTP2 header itself, while Brotli encodes content (usually html, css or js).

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

#408

Post by robryk »

gnramires wrote: post #407
WorldMaker wrote: post #401

Earlier quoted context omitted.

> 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. To my understanding, that static table in HTTP2 is directly in context of recommending and discussing Brotli compression, which does use a table like that as a standard static dictionary in HTTP2+ scenarios including other static…

Thanks, I didn't know Brotli! Indeed it seems to include a dictionary in its compression which seems to help significantly with small pages. I hope compression continues to improve in this way. > To my understanding, that static table in HTTP2 is directly in context of recommending and discussing Brotli compression It seems separate, that would be a header compression for HTTP2 header itself, while Brotli encodes con…

The header compression in http2 has atypical requirements placed upon it: contents of different headers in a single request must not impact each other's compressed size[^], lest an attacker able to manipulate one of them can use that to guess the other. Thus, LZ77-style compression is out of the window, as well as using Huffman codes selected based on _all_ the header values. In essence, each header value (in a single request) has to be compressed independently. IIUC the dictionary you reference is used for header keys (as opposed to values).

[^] this statement is a bit of a lie for reasons of simplification

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

#409

Post by wstuartcl »

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?

if collisioncheck(v1,v2, distance) { // collision }

where you have defined an actually readable equivalent inside of collisioncheck would be my prerogative... I also agree paren matching failures should error, but your example is NOT why.

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

#410

Post by everforward »

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?

> Are urls expected to be a good UX these days? What's the big deal?

I think they are. If I want to go back to some page I was looking at earlier, it's really nice to be able to find that page in my history. That Yahoo URL is going to be hard to differentiate if you looked at a few stocks.

It's also handy if the URL's are predictable enough that I can hit one directly rather than having to go through search. Good for me because I don't wait on page load, good for them because they don't have to serve my search request.

It's pretty low on my list of UX annoyances, but it is there.

Post reply on HN