My Favorite State Manager Is...URLs?
HTML-код
- Опубликовано: 7 июн 2024
- useState is overrated. Seriously tho, query parameters and the URL bar are the best place to store a lot of your state. "search params" are dope and underrated. Hope this helps convince y'all of why.
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏 
Наука
Using URL query params to store the state is a game changer and revolutionary idea. Makes me wonder why previous generations of web devs did not come up with this idea 20 years ago.
I feel so old
The sarcasm here 😂
Topkek
😂
XD
I love that as a rule of thumb; if you want it to persist across a refresh it should be in the query parameters. SPAs ruined the url bar, lol.
Unless you don't want that info shared, like cart data or some data that needs to be stored in the browser storage.
SPA's didn't ruin it the developers did. We did this decades ago when we were doing HTML replacements in browser and all the hacks that came with it. Web developers, since SPA's became more mainstream, have always fought the browser navigation instead of working with it.
SPAs didn't ruin the URL bar. The surge of bootcamped "frontend engineers" who find this video a revelation (and don't know a lick of CSS) -- THEY have ruined the URL bar, among so many other things. Like, this is so 101.
@@zakariabougroug2687 Cart data should be session based, so there's a pretty big difference in my opinion.
URL determines the resource to fetch. Cookies personalise the resource fetched.
These two offer 95% of the state management you ever need, rest being mostly local UI interactivity and real-time form validation.
This is how i write multi part forms, filters, No need any fucking global state, props and etc. Just cookies, query params, and router.push or redirect in server action. Now i see SPA global state management as evil
I love how pretty much every new thing lately is basically us realizing: "OK - those PHP and AJAX guys, they were onto something. Let's do THAT!".
It's funny in the "I was there 3.000 years ago" way and I can't help but feel old, but also it's super cool to see a lot of the same methods find their way back into the modern day stack!
True, brother
Soon we'll ditch JS frameworks! Soon...
Yes! Finally! As somebody who has been making web applications for 15+ years with "uncool PHP" it's nice too see techfluencers promoting common sense over Resume Driven Development. I've dealt with so many bugs in SPAs that only happen "if you start on page A and go to page C without clicking through page B first", or issues that only happen after you've refreshed the page. Most of these wouldn't happen if the URL/router were given more authority over what page to display and how, rather than over-using the state management library.
@jonki7538 don't you think as me that most of frontend devs are self thought or weak courses thought programmers? It's not bad but how they could learn how to make things better?
@@dzienisz if only the seniors shared more tips/were more straight forward instead of gatekeeping we self taught devs would be happy to listen ;)
For sure, trying to debug a PWA is also one of the hardest things for no reason. Yesterday we had links that just wouldn't trigger and there's just no way to debug as to why. The URL was valid, the button was as simple as you can imagine, and there was no weird invisible div that has a higher z-index. It literally made no sense. Laravel / Rails had it right from the beginning.
Just because many people don't know how to SPA doesn't make you less uncool as a PHP "dev".
Yes! I use this kind of thing to great effect at work! As a user, sites that update the query params to reflect the state I care about feel satisfying to use (because I know for a fact that I'm not going to refresh and find nothing there) and effortless to share by nature. It's been a blast implementing them as often as I can, and I can't recommend this pattern to other web devs enough!
True, but what's not showed in this vid is what you do when you want to have that state in both url and as a part of your state management solution - for various reasons sometime this is needed and I think it's an art to achieve this while maintaining a clear flow of what's happening. ❤
My man just discovered how absolutely every online store page has been working since 2005! Great job
More like 1996
theo: react is the best abstraction for web dev
also theo: don't use any of reacts built in features
...fairly accurate tbh
Reminds me of: the best typescript is no typescript at all
Dat foolish consistency is the hobgoblin of little minds n we don't take kindly to hobgoblins in these here parts
can’t help that both things are true
the best product is no product at all
I'm a huge fan of using URL for state. Been doing this for awhile on my frontends, also for internal tools at my company. It's one of the few things that is very powerful and while being straightforward to implement.
Best part of using URL/search params for state is that it works both server-side and client-side. Both can read and write to it and it doesn't require any tooling to do so-although type safety would definitely help.
There is (at least) one more kind of state that is nice to have: persistent across loads but not shareable. Stuff you might use local storage for. Themes, sidebar collapse state, etc.
Awesome that you can access things like that through custom hooks. Using all the different kinds of state from the same context is so powerful.
These small things such as theme or sidebar collapse state are even better as cookies so that you can read them server side and immediately send appropriate UI to the client. Having a theme stored in localStorage might produce a flash in UI styling if for example light theme is default, but dark is the one stored by user so the user will see the UI transition from light to dark instead of immediately seeing dark mode UI. You can also avoid hydration mismatch errors this way if server side HTML is immediately the right HTML you need.
Love this, also think it's kind of funny because coming from "old-web" using url as a state management is kind of a normal 😅
Love that hook! I did not know that was a thing til now. ❤
Haven’t even watched this yet but THANK YOU FOR MAKING THIS
Using the URL query params to store state also helps a great deal when error tracking and monitoring. When users run into an issue, the specific state that caused it is right in the URL.
I feel like remix helped to bring up these conversations in the web ecosystem again and realize that the browser is actually good in most things
I think that is really great suggestion to put yourself in user mode. Last time on one website I spend 5 minutes writing in a chat box. Of course this cannot go to url state and it should absolutely reset on refresh. But closing the chat accidentally and opening it again should persist state. And this is no the first time I had such experience with chats. So yes if they would ask themselves this question I think it would be so clear that can be a problem.
thank god people are making more videos about this lately
Stock photos platforms like Unsplash and Pexels make use of this a lot. Basically, anything data that users will likely share and needs to retain state after being shared should be be stored in the URL.
Also love screenshots with this. Sometimes people don’t give urls but I can work out key debugging starting points. Ember had this right and its spirit animal rails.
Actually I've done this a few years ago in the company I was working in. I started from scratch our search, used the query params as our state manager and improved a lot the usability of the site. I would share here but I don't want to be accused of trying to make publicity when I don't work there anymore. Interesting topic.
Even when my react apps are served through an (don't ask), I still use the url for some state. Being able to send someone to a page with pre-loaded state because it was in the URL is really powerful.
This is a great idea! :D
I love that innovation is very often us just going back to how we used to do it 😆
In relation to NextJS, and the demo the guy showed. How would you make sure that adjusting the URL with minor query values, wouldn't fill the history stack - to the point where returning would be a chore.
Echo of all the rest of the love for url params. Want to add that local storage can also do some magical things. Would love a deep dive on that
I’ve been doing this for years. I build my last companies warehouse management system, and it was absolutely necessary to have a way to share a state with another individual that might not be in the same location.
Great video as usual!
I've been talking about this at work a lot as well, totally agree, also why does your shirt make it look like you're about to go get motion captured for a video game XD. Much love.
would use url as state more if it was better supported natively with solid patterns around url state management (type safety like you mentioned) or anything tanner listed
Yet within NextJS, there’s a poor support of such. I used next-query-params, and multiple states have been racing with each other for who is gonna push to the browser history first. I’ve tried many solutions out there and ended up not using any libraries and handling all page state within a single custom hook that since them manually and spent two weeks on testing to resolve the race
So is it recommended now for personal projects with React or keep using only State. There things make beginners confused.
Who knew what I needed for so long, was just url utilization
If you're not used to app router yet, then storing state in url also makes your life a lot easier. You can go ahead and learn app router while using it, without compromising code quality (at least by design).
Using state in url forces your route to be dynamically rendered. If values of any search param you could ever set are know in advance, shouldn’t there be a generateStaticSearchParams() like we have generateStaticParams()?
Maybe the decision of when to use search params could be down to when the developer started. As someone who started with PHP in the 00's almost everything was in the URL.
So when I recently built an inventory React app with search, sort, and filters I didn't even think twice about using URL search params for those.
Maybe a newer developer who started with React and learned about state before search params approaches the problem with a very different mindset.
Most certainly use query params, not so much for sharing with others, but the ability to right click a button link and open in new tab is really good UX,.. eg. You have a list of records it's then very easy to open multiple record in multiple tabs doing this.
Another semi-persistent store I don't believe is used that much is History storage, keep UI state consistent when going back & fwd is really nice UX too. Might seem daft but making sure the scrollbar position is in the same place when you press back is a must, also History store can persist a refresh.
Lastly of course is the Locale/Session Storage, mainly use the LocaleStorage here, for things like Dark Mode settings, widget positions etc.
In a nutshell using the correct state storage makes a lot of difference, and to be honest is not that hard to do. Doing all this can make it so your users could refresh a page at any time, be half way into editing a record and the will not loose a thing.
url state management is great way to persist the state.
like for persisting table sorting status, pagination etc.
I work for a large e-commerce site, and we actively try to keep the URL as clean as possible so that we don't re-crawl the same page multiple times and ruin our crawl budget.
I recommend only letting customers share these URLs and not internally linking to them from another page on the site.
Of course, this is only an issue once you have a considerable number of pages.
Maintaining consistency between url and state feels great as a user. As a side question I wonder how search engines react when you start including query params as well in your sitemap, SEO standpoint
you should use link rel=“canonical” to address this
I've heard varied responses to this. Some say it's totally fine, others say it's awful. I work in ecommerce and I haven't noticed any significant difference between the stores that have query parameters and the ones that have unique URLs to stuff like color choices. So I am leaning more toward it's fine. Something I have noticed makes a difference is language though. Search engines seem to not be as fond of languages other than English, but it could've also been something else causing it, but that is the one case where I've personally noticed a difference. That was one and a half year ago though, so things could be different now.
any library recommendations for next js?
Would it be better to use replace instead of push in this case to make backwards navigation less annoying for the user
What about api tokens for the front end. That would be better to store in state regardless right?
Thank you for the reminder good Sir :) I often use URLs to create sharable URLs, for product listings with filters/sorting and so on.... but you have a good point... why stop there?
It is like going back to 1999. I like it.
What are your thoughts on using local storage as an alternative to query params when a user reloading the page is a possibility. of course when you want to seamlessly share a particular state you would definitely use query params.
Local storage is good for persistence. Search params are more ephemeral, meaning that they will change often (as you navigate).
The difference is also in how you want to expose the state; local storage is more "private" (difficult to share, usually specific to the current session/user) whereas URL is "public" (easily shareable, not user-specific). Use what makes sense for the best UX.
@@dealloc Lovely response man. Thanks
We've recently come to the same conclusion. Having a shareable URL with your team is nice. We are looking to move some of the state to the router soon!
How did Lee Robinson make that video with the huge cursor and subtle animations?
Lee mentioned it in comments on his latest video. It's called "Screen Studio".
Query params are hard to make type-safe and sanitize (e.g. against prototype pollution). That's usually why I don't use them for state, and I instead use URL push with path params when I need to.
I hope Tanner comes up with a good type-safe validation solution for query params with his Router, that would be dope!
Probably would be pretty straightforward to define a hook that consumes a zod schema to reference the query params.
Wow truly revolutionary
Before app router I only really used url state once or twice, and I'm not even sure if you could call it a state, more like extra info on navigation. But now with SSR so easy to achieve, it's practically a must if you don't want flicker or a hydration error. Just wish someone made a wrapper for it already, it's not the nicest experience in terms of types. URL Thing when?
There is a max character length for the url though right?
Sorry, could you share original link video of Lee Robinson talk relate the URLS
I recently needed to provide a company with a preferred MacBook choice. Was baffled to see that the 5 variants, including color, RAM, keyboard choice, power adapter etc, was not reflected in URL params. I had to send them a list of choices rather than a single link. In the official apple online store. So bad!
I thought this was a default way to think of it... But it's true that some sites do not make sharing of URLs, or even opening up tabs for different states (like if you want to open up 5 separate products for comparison) very easy... Strangeness.
I noticed something really annoying about the azure git the other day. The branch state isn't part of the damn url. So you can't copy a link to a branched version of a file to share with someone else
I wish there was a better way of handling search params in next, currently it is really lacking type safety.
I remember ever visit google documentation which use url when tab changes.
excellent point
Url state management seems like "It's great until it's terrible" thing. Pretty much like all other tech
3:09 Everyone! Please use router.replace instead of router.push so that the user clicking the back button in the future won’t have to go through a bunch of identical looking pages with just changes to the search params. It breaks UX & user expectations (back should go to different page, not state changes of a page).
This. Please. Heck, I'd be happy if the back button went through multiple pages at once sometimes, especially on things like page turning through a book. If I wanted to go back a page in my book (or manga, those websites are exceptionally bad for this), I'd turn the page, not press the back button.
Using search params make the page dynamic in Next.js, which is less performant than static pages which are fully in cache, right? So, you should always choose static pages when possible, correct?
A GET request with query parameters can be cached. Caching layer sits between the client and server. Look at ETag settings for requests you want cached.
@@NuncNuncNuncNunc I see, thanks for the reply!
Blowing my mind
you need to be veeery careful for xss tho
What stack is used by RUclips?
I always do this, I want the url to keep the state of the stuff I select in the page, it just makes sense for all the reasons mentioned on this video
I feel like we are re-invening things we already had years ago . I always used this method when i was working with php . Infact all of the websites used to work only like this before the rise of react js and other js frameworks .
The only issue I have with this from experience is that in the current app router this jumps you back to the top of the page and haven’t found a way to stop that from happening… would love to know if anyone has a solution to this.
this is a hard requirement for every feature we do in my company, super useful to have everything in the URL.
also when you shut down the PC and reboot, the state holds, also goes for browser crashes
Because nextjs couldn’t figure a shared state like Sveltekit did, so they through url params at us as a great state solution. And Theo as long as he’s being paid he must agree.
I recently developed a feature in our app that uses three layer of data store: the form, the state management lib and the url query. I gotta say that synchronizng these three is absolutely unpleasant to do, especially when everything is async.
But in order to store complex data that spread accross modules, some sort of a state mng is always needed, as simple as useContext or as complex as the redux
Why not IndexedDB? Using URL can open to vulnerabilities
Is there a case where this solution (using URL) is not good to use ? Is it secure ?
Also the other place state is stored that people forget about is the actual DOM. it's literally the state of the page.
I used the URL for state back in 1995. Boy, was I ahead of my time! cgi-bin 4 lyfe!
Unfortunately, using search params opts the page and all of it's child components into dynamic rendering. I was using search params to select product variations - but the data for all variations is requested in the initial getProduct query. This query was re-run whenever the variation was changed.. which was completely unnecessary as I'm using it purely for state - not a data request. Not sure if there's a setup to avoid this happening. I can see why it's the default behaviour though, as in Lee's example, the search params were altering what was fetched by the server.
I don't think this is true. A GET request with the same query params is intended to return the same response everytime. Make sure your headers allow caching and you are setting an ETag.
This feels like a bell curve meme moment ... but yeah this is nice
i like too use url to state, but many site on web replace the page on historic, and this cause to "back button" on broser go to home, if in a list of 100 page and i'm in on page 6, stop use replace if use state on url, thanks
no website whose SEO was valuable would overlook this. Still the state is managed in react as well , only synchronized. You have a state dependency url react internal state, nowadays next does it for you. Surely this is mandatory in ecommerce. Otherwise it's a mess.
Nice to bring this to client rendered apps. This is REST API and server sided rendering 101.
This is the way
can i do this without strugling with next js page router?
Like I have said before I miss php... JS made everything complicated for no reason, glad people are doing things the way the web was designed once again.
Yup. URLs and😮 Cookies is all you need🎉
This is also great from a DX perspective as well... Users can send you the URL with the exact state that's causing a bug.
Guys how to use together: trpc + solidjs + tan stack query for solidjs??
The problem is where you have, a lot more complicated app with dozens of filters, and the URL starts to get 1km long
I love watching everyone “discover” the patterns Ember has been advocating for a decade while simultaneously smirking at Ember.
I’m like 🤯🤯
Turns out that globally accessible, easily exported / restored state is valuable.
The best state management a browser can provide is the HTML, remember the old 'data-' props?
Offtopic: Theo is slowly becoming Heimerdinger
Yes
I used php in my class where we passed states in the url. Now, with this video, I might just do it in my next react project rather than using useState all the time.
In your Next React project, or in your next React project? ;)
@@yamyam263 latter
100%. This is plaguing me at work since we have a few apps that we’re forced to use that unfortunately *do not* embed their state, so, so many people are stuck having to constantly copy/paste and reexplain what to do, what to click, etc. It’s _extremely_ painful.
Please, folks… please make the URL a first-class citizen in your app! It’s not a new concept at all, I hate that we lost our way here.
It's sad that some developers need to be told this. It's such an important part of the user experience that I considered it critical even when I was first learning web dev.
There is apparently one downside to use URL params for state.
Google will in some cases penalize the page because there is many "pages" (each param combination is treated as a unique page) with the same content so each "page" gets a lower score and a competitor that does not use the same solution will end up higher in the search result.
That problem should be handled by 1) having unique content per unique address and 2) if #1 is not possible setting a canonical URL so indexers look at just one URL
@@NuncNuncNuncNunc 1: yes, but that depends on what state your storing. If the state does not actually change the real content but serves some other purpose it will be a problem and 2: Yes except apparently it does not always work, Canonical Url's is a hint that it is the same content but its not always respected. Not sure of what could case changes but it might be if there is some dynamic content in the page that causes google to distrust the canonical hint.
Jotai's atomWithLocation and atomWithHash 😉
Lol! Why not use normal href links instead of complex js overhead for manipulating querys? Why need js in the fidst place when you can statically create theese sites?
What about password/emails?
Been using the URL since PHP3 for this
What is state?
interesting what counts as state these days. But yeah, control whats shown to all users via url and whats shown to only that user via cookie