The latest version of Microsoft Teams is absolutely terrible at this... just one URL for everything. No way to bookmark even a particular team.
URLs are state containers
41–50 of 218 posts
Re: URLs are state containers
#42When 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…
The URL is a public facing interface. If anything goes into the URL, it should already be detailed in the design that the PR’d code is implementing.
Re: URLs are state containers
#43When 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 can understand "shareable" state (scroll position), but _as much as possible_ seems like overkill.
Why not just use localStorage?
Re: URLs are state containers
#44> 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)
Re: URLs are state containers
#45I use URLs for pixel art: https://www.mathsuniverse.com/pixel-art?p=GgpUODLkg-N0JchwOF...
Re: URLs are state containers
#46When 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.
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
Re: URLs are state containers
#47One barrier to adoption is that big URLs are just ugly. Things are smooshed together without spaces, URL encoding, human-readable words mixed with random characters, etc. I think even devs who understand what they're looking at find it a little unsatisfying.
Maybe a solution is some kind of browser widget that displays query params in a user-friendly way that hides the ugliness, sort of like an object explorer interface.
Re: URLs are state containers
#48I agree, and this reminds me: I really wish there was better URL (and DNS) literacy amongst the mainstream 'digitally literate'. It would help reduce risk of phishing attacks, allow people to observe and control state meaningful to their experience (e.g. knowing what the '?t=_' does in youtube), trimming of personal info like tracking params (e.g. utm_) before sharing, understanding https/padlock doesn't mean trusted…
> Generally, even the most internet-savvy age group, are vastly ill-equipped. It’s a losing battle when even the tools (web browsers hiding URLs by default, heck even Firefox on iOS does it now!) and companies (making posters with nothing more than QR codes or search terms) are what they’re up against….
And with commercial software like Outlook being so ubiquitous and absolutely HORRENDOUS with url obfuscation, formatting, “in network” contacts, and seemingly random spam filtering.
Our company does phishing tests like most, and their checklist of suspicious behavior is 1 to 1 useless. Every item on the list is either 1: something that our company actually does with its real emails or 2: useless because outlook sucks a huge wang. So I basically never open emails and report almost everything I get. I’m sure the IT department enjoys the 80% false report rate.
Re: URLs are state containers
#49The amount of state that early video games stored in like 256 bytes of ram was actually quite impressive. I bet with some creativity one could do similarly for a web app. Just don’t use gzipped b64-encoded json as your in-url state store!
With a custom compression dictionary made against your JSON schema, I would bet you could still pack a surprising amount of data into 256 bytes that way.
I tried this once and discovered that for us it worked even better when populating the dictionary with a bunch of commonly seen URLs. Like that includes the same field names as the json schema, but none of the other JSON Schema cruft, and it also includes commonly used values etc. It seemed like the smarter I tried to be, the worse the results got.
I just used Pako.js which accepts a `{ dictionary: string }` option. Concat a bunch of common URL together, done.
The only downside (with both our approaches) is if you add substantially many new fields / common values later on, you need to update the dictionary, and then old URLs don't work, so you'd need some sort of versioning scheme and use the right dictionary for the right version.
Re: URLs are state containers
#50When 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 make sure that as much state as possible is saved in a URL Do you have advice on how to achieve this (for purely client-side stuff)? - How do you represent the state? (a list of key=value pair after the hash?) - How do you make sure it stays in sync? -- do you parse the hash part in JS to restore some stuff on page load and when the URL changes? - How do you manage previous / next? - How do you manage server-side…
The URL spec already takes care of a lot of this, for example /shopping/shirts?color=blue&size=M&page=3 or /articles/my-article-title#preface