Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

URLs are state containers

alfy.blog

Post reply on HN
Print view View original

51–60 of 218 posts

Re: URLs are state containers

#51

Post by fittom »

jorl17 wrote: post #24

When I get my way reviewing a codebase, I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. I genuinely don't understand why people don't get more upset over hitting refresh on a webpage and ending up in a significantly different place. It's mind-boggling and actually insulting as a user. Or grabbing a URL and sending to another person, only to find out…

I completely agree. In fact, I believe URL design should be part of UX design, and although I've worked with 30+ UX designers, I've never once received guidance on URLs.

Re: URLs are state containers

#52

Post by DrewADesign »

thijsvandien wrote: post #36
jorl17 wrote: post #24

When I get my way reviewing a codebase, I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. I genuinely don't understand why people don't get more upset over hitting refresh on a webpage and ending up in a significantly different place. It's mind-boggling and actually insulting as a user. Or grabbing a URL and sending to another person, only to find out…

While I like this approach as well, these URLs ending up in the browser history isn’t ideal. Autocomplete when just trying to go to the site causes some undesired state every now and then. Maybe query params offer an advantage over paths here.

I think it’s a “use the right tool for the job” thing. Putting ephemeral information like session info in URLs sucks and should only be done if you need to pass it in a get request from a non-browser program or something, and even then I think you should redirect or rewrite the url or something after the initial request. But I think actual navigational data or some sort of state if it’s in the middle of an important action is acceptable.

But if you really just want your users to be able to hit refresh and not have their state change for non-navigational stuff like field contents or whatever, unless you have a really clear use case where you need to maintain state while switching devices and don’t want to do in server-side, local storage seems like the idiomatic choice.

Re: URLs are state containers

#53

Post by cyptus »

bgilroy26 wrote: post #37
jorl17 wrote: post #24

When I get my way reviewing a codebase, I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. I genuinely don't understand why people don't get more upset over hitting refresh on a webpage and ending up in a significantly different place. It's mind-boggling and actually insulting as a user. Or grabbing a URL and sending to another person, only to find out…

To save the url length, why not hash all possible states and have the value of the variable in the query string refer to that?

and where is the hash mapped back again?

Re: URLs are state containers

#54

Post by lenkite »

jorl17 wrote: post #24

When I get my way reviewing a codebase, I make sure that as much state as possible is saved in a URL, sometimes (though rarely) down to the scroll position. I genuinely don't understand why people don't get more upset over hitting refresh on a webpage and ending up in a significantly different place. It's mind-boggling and actually insulting as a user. Or grabbing a URL and sending to another person, only to find out…

To make this work better, URL's should standardize several common semantic query parameters and fragment identifiers (like lines, etc). There is utterly no need for every website to re-invent the wheel here. It would also enable browsers to display long URL's better. It could also reduce the amount of client JS once browsers pick up the job of executing some of the client side interactions on very common fragment changes.

Re: URLs are state containers

#55

Post by croes »

djoldman wrote: post #44
azangru wrote: post #29

> Browsers and servers impose practical limits on URL length (usually between 2,000 and 8,000 characters) but the reality is more nuanced. As this detailed Stack Overflow answer explains, limits come from a mix of browser behavior, server configurations, CDNs, and even search engine constraints. If you’re bumping against them, it’s a sign you need to rethink your approach. So what is the reality? The linked StackOver…

Each of those characters (aside from domain) could be any of 66 unique ones: Uppercase letters: A through Z (26 characters) Lowercase letters: a through z (26 characters) Digits: 0 through 9 (10 characters) Special: - . _ ~ (4 characters) So you'd get a lot of bang for your buck if you really wanted to encode a lot of information.

Unless you have some kind of mapping to encode different states with different character blocks your possibilities are much more limited. Like storing product ids or EAN plus the number of items. Just hope the user isn’t on a shopping spree

Re: URLs are state containers

#56

Post by yreg »

linked_list wrote: post #38
bgilroy26 wrote: post #37

Earlier quoted context omitted.

To save the url length, why not hash all possible states and have the value of the variable in the query string refer to that?

Because a hash is by definition a one-way mapping, so then you'd have to keep a map of the reverse mapping hash -> state, which obviously gets impractical with state such as page index or search terms. Better just make two-way "compression" mapping

They probably have meant something like base64 encode

Re: URLs are state containers

#58

Post by linked_list »

yreg wrote: post #56
linked_list wrote: post #38

Earlier quoted context omitted.

Because a hash is by definition a one-way mapping, so then you'd have to keep a map of the reverse mapping hash -> state, which obviously gets impractical with state such as page index or search terms. Better just make two-way "compression" mapping

They probably have meant something like base64 encode

If you base64 encode an ascii string it gets 33% longer

Re: URLs are state containers

#59

Post by orphea »

linked_list wrote: post #46
thijsvandien wrote: post #36

Earlier quoted context omitted.

While I like this approach as well, these URLs ending up in the browser history isn’t ideal. Autocomplete when just trying to go to the site causes some undesired state every now and then. Maybe query params offer an advantage over paths here.

JS does have features for editing the history, but it's a trade-off of not polluting the history too much while still letting the user navigate back and forth

I'm glad to see that prismjs site mentioned by the blog is doing the right thing - when it updates the URL, it replaces the current history item.

Re: URLs are state containers

#60

Post by croes »

yubblegum wrote: post #28

Sure and file names are state & attribute containers too. A URL is a uniform resource locator. You can hack it, of course, but this is no less kludgy than overloading filename. It is never ceases to amaze me seeing the recylcing of good and bad idea in this field.

Urls have extra parts like the parameters to store that data. It’s not a hack
Post reply on HN