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

151–160 of 218 posts

Re: URLs are state containers

#151

Post by eru »

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 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 it doesn't make sense.

The two use cases are in slight conflict: most of the time, when I share a URL, I don't want to share a specific scroll position (which probably doesn't even make sense, if the other guy has a different screen size.)

Re: URLs are state containers

#152

Post by paulddraper »

eru wrote: post #151
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 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 it doesn't make sense. The two use cases are in slight conflict: most of the time, when I share a URL, I don't want to share a specific scroll position (w…

Scroll, as parent said, is usually not included.

Obviously the URL is not all state, it doesn’t save your cursor or IME input. So there is some distinction between “important” and “unimportant” state.

Re: URLs are state containers

#154

Post by eru »

paulddraper wrote: post #152
eru wrote: post #151

Earlier quoted context omitted.

> 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 it doesn't make sense. The two use cases are in slight conflict: most of the time, when I share a URL, I don't want to share a specific scroll position (w…

Scroll, as parent said, is usually not included. Obviously the URL is not all state, it doesn’t save your cursor or IME input. So there is some distinction between “important” and “unimportant” state.

Perhaps a better example: should video URLs (like on youtube) include a timestamp or not?

Youtube gives you both options, and either can be what you want. Youtube also seems to be smart enough to roughly remember where you were in the video, when you are reloading the page.

Re: URLs are state containers

#155

Post by gortok »

The wild thing about this is that for the longest time, URLs were the mechanism for maintaining state on a page. It is only with the complete takeover of JavaScript-based web pages that we even got away from this being "just the way it is". Browsers and server-rendered pages have a number of features that folks try their best to recreate with javascript, and often recreate it rather poorly.

Re: URLs are state containers

#156

Post by franciscop »

This is one of the things that bothered me the most from existing React libraries, if you wanted to update a single query parameter now you needed to do a lot of extra work. It bothered me so much I ended up making a library around this [1], where you can do just:

    // /some/path?name=Francisco
    const [name, setName] = useQuery("name");
    console.log(name);  // Francisco
    setName('whatever');
Here's a bit more complex example with a CodeSadnbox[2]:

    export default function SearchForm() {
      const [place, setPlace] = useQuery("place");
      const [max, setMax] = useQuery("max");

      return (
        
          
            Search Trips
            
Start planning your holidays on a budget

          
          
          
        
      );
    }
[1] https://crossroad.page/

[2] https://codesandbox.io/p/sandbox/festive-murdock-1ctv6

Re: URLs are state containers

#157

Post by nozzlegear »

domga wrote: post #148
capecodes wrote: post #142

Earlier quoted context omitted.

The “cut off” thing is generally legacy thinking, the web has moved on and you can reliably put a lot of data in the URI… https://stackoverflow.com/questions/417142/what-is-the-maxim...

Links with lots of data in them are really annoying to share. I see the value in storing some state there, but I don’t think there is room for much of it.

What makes them annoying to share? I bet it's more an issue with the UX of whatever app or website you're sharing the link in. Take that stackoverflow link in the comment you're replying to, for example: you can see the domain and most of the path, but HN elides link text after a certain length because it's superfluous.

Re: URLs are state containers

#158

Post by franciscop »

mrexroad wrote: post #68
fittom wrote: post #51

Earlier quoted context omitted.

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.

As a UX designer that always gives guidance on URL design/strategy, I’ll say it’s not always well received. I’ve run into more than a few engineering or PM teams who feel that’s not w/in scope of design.

As a dev who cares about UX, this is crazy to hear but resonates, I've got a few weird looks from people whenever I mentioned some URL improvements. I've also worked with people who understood it. I've seen a correlation though, when people cared enough I could share freely about this, when I did the designer's and dev work I would just add that in (I'm def not a designer, so if I'm doing design work that means the owner doesn't care about design, let alone URLs).

I can imagine in your situation as a pure designer how you got it though though, sorry to hear that and I wish other devs cared more. I've def mentoring people to care about it so hope others do so too.

Re: URLs are state containers

#160

Post by porridgeraisin »

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.

Yeah, lichess does this.

On lichess.org/analysis, each move you make adds a history item, lichess.org/analysis#1, #2, and so on.

Pretty annoying.

Post reply on HN