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

221–230 of 416 posts

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

#221

Post by TheRealPomax »

kelnos wrote: post #195
TheRealPomax wrote: post #141

Earlier quoted context omitted.

If you have so many parameters that you need a URL that's over 2048 characters, you should probably be reminded that localStorage exists.

Using local storage means that you can't share a flowchart with someone else (or embed one in another page) at all, let alone easily.

If you need to show a flowchart that doesn't fit in a URL, the idea that you should be able to do this with a URL is kinda bonkers. The solution there would be www.example.com/?data=url_for_the_flowchart_definition, because what you're talking about isn't page state, it's a secondary resource.

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

#224

Post by TheBrokenRail »

owl57 wrote: post #192
hunter2_ wrote: post #155

Earlier quoted context omitted.

I don't think people care so much about a messy address bar as a messy chat/email message after pasting a URL. Shorteners and vanity URLs exist, but that's more friction than just copying from the address bar as-is. This can be overcome with html, markdown, and other rich text formats that let you specify the visible link text (missing from many chat apps*), but that's also friction to compose compared to automatical…

It's not even only about messiness. " https://news.ycombinator.com/item?id=34315441 " isn't some horrible long base64, but it's not a good UX either: when you paste it in a messenger, or in your notes, by default the reader can't tell what's it about without clicking. > *Slack's implementation is awesome: type the link text, highlight it, and paste a URL. Yes! Matches my vision of hypertext perfectly: I usually type…

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

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

#225

Post by hinkley »

MereInterest wrote: post #206
PUSH_AX wrote: post #171

Earlier quoted context omitted.

> Just because a thing is prevalent doesn't mean it's good. I agree with this sentiment. I'm not sure I've ever seen a url referred to as "good", I was just a bit confused as to why someone would baulk at a URL. In my opinion everything after the host portion of the url is to serve the apps needs, so it knows where to go or what to do, it's not really an interface for the user as obviously there are better ways to pr…

I’d say everything after the host is part of the UX, and should serve the user needs. For example: * Should be book-markable. * If searching with a query, should have a clear query parameter for ease of browser integration. * If the URL contains slash dividers that can be read as categories (e.g. storefront.com/department/category/product), then deleting everything after a given slash should go to that category’s pag…

* I should be able to guess if you're sending me a link about composting or a Rick Astley video

Opaque slugs are problematic in a low-trust world. Phishing attempts are easier when the parameters are indecipherable. I'm not clicking on that shit in a text message or an email. I've seen what happens to people when they do.

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

#227

Post by whatusername »

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

Earlier quoted context omitted.

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…

> Just because a thing is prevalent doesn't mean it's good. I agree with this sentiment. I'm not sure I've ever seen a url referred to as "good", I was just a bit confused as to why someone would baulk at a URL. In my opinion everything after the host portion of the url is to serve the apps needs, so it knows where to go or what to do, it's not really an interface for the user as obviously there are better ways to pr…

No - but they have been referred to as "cool" before. Gotta love the early 90's.

https://www.w3.org/Provider/Style/URI

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

#228

Post by voidmain0001 »

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

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.

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

#230

Post by jefftk »

dheera wrote: post #30
redleader55 wrote: post #7

A better idea is to use the URI fragment (the string after the # sign). It has the advantage of not having a size limit, and not needing to be sent all to the backend during the request. `window.location.hash` is your friend.

> It has the advantage of not having a size limit Still though I suppose you could probably gzip it before base64 encoding it for some additional optimization. Extremely long URLs have other UX issues, e.g. sending them on chat apps and having them eat up multiple scroll pages in one URL, like: "Check out this event: http:// ..... ... ... (500 scroll-screen-lengths of just URL) ... ... Here's another event on the sam…

I don't most chat apps truncate long URLs?
Post reply on HN