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

391–400 of 416 posts

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

#391

Post by anshumankmr »

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?

I Just like to keep query params simple and readable. I understand the possible use case for this obfuscated url which would make it difficult to scrape the site

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

#392

Post by mattpallissard »

bsima wrote: post #372
TeMPOraL wrote: post #263

Earlier quoted context omitted.

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/

Or it could just be that s expressions are easy to parse.

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

#393

Post by ddyevf635372 »

EGreg wrote: post #67
ddyevf635372 wrote: post #9

Earlier quoted context omitted.

Routes are the fundamental building blocks of a webpage, so the hierarchy will be represented by the routes in the url. Proper frontend framework, like Ember.js, built on top of routes and building a UX focused web app is much easier with them. https://guides.emberjs.com/release/routing/

Your link and the explanation there is not enough. It only shows the current resource you are looking at. As I said above - you should also consider representing the breadcrumbs of how you got there in the hierarchy (you could have taken multiple paths) and also on top of that use URLs to represent actions that can be taken in dialogs ! Here is a question for you: what happens when you have a url for a New Issue in g…

Overlay is useful sometimes, however not always the best UX.

The main route of the url (example.com/page/subpage) represents the background page of the overlay.

You have two options. 1. Using further subroutes to represent the stage of the overlay if your framework supports it (Ember does) (example.com/page/subpage/form/step1). 2. Using query parans to store the state of the overlay (without the actual data of course): … subpage?overlay=form&step=1

Also breadcrumbs should always mirror the routes. Frameworks, libraries can automatically do it for you.

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

#394

Post by lsaferite »

stnmtn wrote: post #177
voidmain0001 wrote: post #176

Earlier quoted context omitted.

Pass that super duper long Yahoo URL to Tinyurl and shrink it down to https://tinyurl.com/bdfepwar It seems like storing state in the URL could benefit from URL shortening techniques so long as the secret sauce logic is both client and server side.

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

The primary benefit of storing all the state in the URL is that the server can be stateless. Using a shortener just moves the state to a different server. A user being able to inspect the state is just a side benefit.

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

#395

Post by galaxyLogic »

thunky wrote: post #285
galaxyLogic wrote: post #276

Earlier quoted context omitted.

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.

If it points to local storage then it's not shareable. If it points to a cloud database then you need a cloud database to do what a url could do.

Good point

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

#396

Post by calebegg »

Ndymium wrote: post #163

Last November I had covid and during that time I wrote a little pastebin that runs in the browser, compresses the paste data with Brotli, and puts it in the URL. It has line numbers, file naming, and syntax highlighting so it's feature complete for my own use. Here's a demo, but beware, the URLs are loooong: https://nicd.gitlab.io/t/#NhfW?Qm3F?6-&22c&CQZXuP+Aej5OXzXk7... I find it interesting to sometimes play around…

> The maximum URL size is 2048

FYI, this is almost entirely untrue. Maybe for some old versions of IE, but modern browsers can handle extremely long URIs

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

#397

Post by winrid »

forgotusername6 wrote: post #332
winrid wrote: post #299

Earlier quoted context omitted.

I mean, they got pwned because they didn't validate the state against the current user's session. Not because storing state in the URL is insecure.

How can you secure state stored in the URL?

You don't. You secure the resources the state accesses.

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

#398

Post by WorldMaker »

User23 wrote: post #386
moring wrote: post #324

Earlier quoted context omitted.

That, and the usual style of stacking all closing parentheses together at the end of the last line of a sub-expression / statement / whatever. People sometimes do this in Java and it's just as unreadable.

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

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

#399

Post by WorldMaker »

owl57 wrote: post #284
TheBrokenRail wrote: post #224

Earlier quoted context omitted.

> by default the reader can't tell what's it about without clicking. Most chat apps like Discord will automatically include an embed generated from a URL's metadata when present in a message.

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?

There is a standard for this. It's called oEmbed: https://oembed.com/

The chat host still likely needs access to the "non-public website" to discover and call its oEmbed API, so that's something you'd have to figure out, but any website anywhere can offer oEmbed metadata if it wishes.

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

#400

Post by hot_gril »

naasking wrote: post #376
hot_gril wrote: post #213

Earlier quoted context omitted.

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.

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 across a reload/back.

For example, you may track the scroll position for the purpose of loading more content when the user reaches the bottom of a feed, but you don't want to persist that across reloads. And the user may click on some content and anchor the view to it, which you do persist in the URL for the purpose of history or sharing.

Post reply on HN