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'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.
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.
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.
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!
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.
TLDR: I don't want "Back" button to be "Undo" button. For example, user goes from search to product, then switches between different sizes and colors a bunch of times and then decides to actually go back to search. Particularly for mobile UX. In my experience if you didn't do additional handling, user will have to press BACK BACK BACK BACK BACK BACK through the history of state changes before he can actually go back. I don't do react and don't know if community already invented the solution. But i guess you'll need some kind of stack that tracks if your previous url is indeed another page or change of state on current page.
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?
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.
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).
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.
OMG yes I hate this. I do understand it for more complex interaction where something needs to happen and then a navigation occurs, but for something that is just a link to another page please just use an anchor tag.
@@Sammysapphira If something needs to be clickable and perform some action when you click it, it's a button. As someone mentioned, using a button HTML element means you get bunch of functionality for free. div does not replace a button element.
This is a 20+ year old concept, something you would do literally ALL the time in something like PHP. It's completely dumbfounding to me that this could be anyone's news 😂
Ok, I'm disappointed that some people need to be explained about this while they are already using web frameworks. People should not start coding web before understanding fundamentals like.... f*cking URLs.
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.
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?
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.
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
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. ❤
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!
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.
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.
people confuse *ui* state with their data layer WAY too often. No wonder they find react hard, when they're using a library for ui view state to behave similar to their data layer.
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.
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 .
What about storing a list? What about in this example the product data itself? A lot of data can’t simply be stored in url There’s nothing new being offered here Search uis have always been reflected in urls since the 2000s
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.
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.
NOPE. This is a terrible idea and another example of the tail wagging the dog. How is exposing application state to the user a sensible thing to do? What happens when the user, by accident or design, tampers with the URL? State is fundamental to an apps correct operation, exposing it like this leave you open to all sorts of bugs and potential security issues. If state management is such an issue (can't say I've ever had a problem with it) surely fixing it properly is the correct thing do rather than co-opting some other mechanism that's not designed to handle this.
All the examples he gives are solid He is not saying use URLs for *all* your state management. He's saying don't forget it's a tool in the toolbox. In recent years it seems more and more forgotten as a valid mechanism for some forms of state :)
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.
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!
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
If react devs where not using search params for simple states like colors, size, some search, is a skill issue driven by youtube videos promoting various state libs. It is not hard to find the same people some years ago using some state management for the same example. Which is common theme in react/next influencers trying to find content to produce, But certainly these simple states are NOT an example of what state managers are usefull for and cannot handle complex (which is more often than not what is happening) scenarios. So "what do you think of managing state in url" is not actually a proper question cause there are specific cases where this state management should happen.
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.
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.
Yeah, now they're gonna start prefixing the query params to prevent collisions from arguments from different components, and we are back to misery... People love to overcomplicate things. Just remember, simple is not necessarily easier, and you want simple, not easy...
Did you know you can just append a timestamp to a UA-cam URL? I just found that out yesterday. The variable name is "t". I will 1000% be abusing this in all future video sharing moments.
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?
I've been saying this for some time now, tried to do it in the company i was working previously and my PM said 'yeah but the urls must look nice for the user', one of the dumbest things i've heard in a while LOL
Nothing worse than a shitty SPA that you can't deep link or use browser navigation buttons within. This isn't new we've been doing this for decades but it seems people have found it again.
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. ❤
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.
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
why do people treat this like it’s a shiny new thing? this has been a thing for years! I’m glad it gets attention because it’s a great pattern but it’s nothing new lol
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.
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
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.
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.
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
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?
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()?
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'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.
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 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 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.
Url state management seems like "It's great until it's terrible" thing. Pretty much like all other tech
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.
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!
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.
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.
TLDR: I don't want "Back" button to be "Undo" button.
For example, user goes from search to product, then switches between different sizes and colors a bunch of times and then decides to actually go back to search. Particularly for mobile UX. In my experience if you didn't do additional handling, user will have to press BACK BACK BACK BACK BACK BACK through the history of state changes before he can actually go back.
I don't do react and don't know if community already invented the solution. But i guess you'll need some kind of stack that tracks if your previous url is indeed another page or change of state on current page.
thank god people are making more videos about this lately
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
url state management is great way to persist the state.
like for persisting table sorting status, pagination etc.
I remember ever visit google documentation which use url when tab changes.
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?
Offtopic: Theo is slowly becoming Heimerdinger
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.
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).
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".
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 am surprised people are only thinking about this now. Been doing this since college. I blame brogrammers for reinventing the wheel. 😂
excellent point
With this, please please please use tags instead of buttons - it makes me when I click to open in a new tab and nothing happens
I don't understand why anyone uses the button tag when you can onclick a div with a specific function and have way more control over the style flow
@@Sammysapphira wcag
@@Sammysapphira accessibility is free with a button tag - you need to build your own tab/key/focus behaviors if you are using a div - it’s a pain
OMG yes I hate this. I do understand it for more complex interaction where something needs to happen and then a navigation occurs, but for something that is just a link to another page please just use an anchor tag.
@@Sammysapphira If something needs to be clickable and perform some action when you click it, it's a button. As someone mentioned, using a button HTML element means you get bunch of functionality for free. div does not replace a button element.
Please remember to separate UI state and Application state. Yes, they are not the same :-)
“2K ought to be enough for anybody.”-Bill Gates
Even for calculators too 🕶
Yes
typescript is pain though
Not sure how you could make this video without mentioning Remix or Ryan Florence. It's basically built on this exact philosophy.
Thanks for mentioning them yourself! Can you elaborate a bit? I am curious
This is a 20+ year old concept, something you would do literally ALL the time in something like PHP. It's completely dumbfounding to me that this could be anyone's news 😂
@@SebastianSativaLivemore yeah this trend of people rediscovering basics of how web works and presenting them as revolutionary is hilarious.
The other big benefit is SEO
Can we really call this a state management?
but but but, you have to know how to use url!
Ok, I'm disappointed that some people need to be explained about this while they are already using web frameworks.
People should not start coding web before understanding fundamentals like.... f*cking URLs.
SECOND
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.
@@Ziko2687s8 Cart data should be session based, so there's a pretty big difference in my opinion.
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".
My man just discovered how absolutely every online store page has been working since 2005! Great job
More like 1996
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
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. ❤
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...
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.
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.
people confuse *ui* state with their data layer WAY too often. No wonder they find react hard, when they're using a library for ui view state to behave similar to their data layer.
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.
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 .
I used the URL for state back in 1995. Boy, was I ahead of my time! cgi-bin 4 lyfe!
What about storing a list? What about in this example the product data itself? A lot of data can’t simply be stored in url
There’s nothing new being offered here
Search uis have always been reflected in urls since the 2000s
Isn't this how the web was always built till JS devs went bonkers with frontend frameworks.
React is slowly catching up to the usability that PHP web sites had over two decades ago as react devs learn basic web development
😂 exactly. They're so "smart"
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.
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.
NOPE. This is a terrible idea and another example of the tail wagging the dog. How is exposing application state to the user a sensible thing to do? What happens when the user, by accident or design, tampers with the URL? State is fundamental to an apps correct operation, exposing it like this leave you open to all sorts of bugs and potential security issues. If state management is such an issue (can't say I've ever had a problem with it) surely fixing it properly is the correct thing do rather than co-opting some other mechanism that's not designed to handle this.
All the examples he gives are solid
He is not saying use URLs for *all* your state management. He's saying don't forget it's a tool in the toolbox. In recent years it seems more and more forgotten as a valid mechanism for some forms of state :)
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.
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!
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
It is like going back to 1999. I like it.
Stop with these thumbnails man.
If react devs where not using search params for simple states like colors, size, some search, is a skill issue driven by youtube videos promoting various state libs.
It is not hard to find the same people some years ago using some state management for the same example.
Which is common theme in react/next influencers trying to find content to produce,
But certainly these simple states are NOT an example of what state managers are usefull for and cannot handle complex (which is more often than not what is happening) scenarios.
So "what do you think of managing state in url" is not actually a proper question cause there are specific cases where this state management should happen.
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.
This state management can be done now is because we can have non-reload navigation. And I really love this.
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.
Yeah, now they're gonna start prefixing the query params to prevent collisions from arguments from different components, and we are back to misery... People love to overcomplicate things. Just remember, simple is not necessarily easier, and you want simple, not easy...
Missed the ultimate way to save state in URLs: serializing entire app state as base 64 encoded json, looks like this: ?state=ABCF15C35F....
Did you know you can just append a timestamp to a UA-cam URL? I just found that out yesterday. The variable name is "t". I will 1000% be abusing this in all future video sharing moments.
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?
I've been saying this for some time now, tried to do it in the company i was working previously and my PM said 'yeah but the urls must look nice for the user', one of the dumbest things i've heard in a while LOL
Nothing worse than a shitty SPA that you can't deep link or use browser navigation buttons within. This isn't new we've been doing this for decades but it seems people have found it again.
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. ❤
Why not IndexedDB? Using URL can open to vulnerabilities
Hateoas gonna hateoas
What bothers me is presenting this like something new, like these guys using it in React are somewhat revolutionary... come on...
why do we even need to remind people of it, it was always a thing even before times of jQuery
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.
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
The best state management a browser can provide is the HTML, remember the old 'data-' props?
Guys how to use together: trpc + solidjs + tan stack query for solidjs??
This is just very basic UX. Worrying that you have to spell it out.
Sorry, could you share original link video of Lee Robinson talk relate the URLS
Will cause problems when building for PWA / installable apps.
why do people treat this like it’s a shiny new thing? this has been a thing for years! I’m glad it gets attention because it’s a great pattern but it’s nothing new lol
I don't understand why this is underrated if everybody at e-commerce mostly use it?
We are doing that on PHP way back the time of the dinosaurs
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
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.
URL has always been and will always be the single source of truth
can i do this without strugling with next js page router?
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.
Yup. URLs and😮 Cookies is all you need🎉
any library recommendations for next js?
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
There is a max character length for the url though right?
Been using the URL since PHP3 for this
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
What about password/emails?
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?
Jotai's atomWithLocation and atomWithHash 😉
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()?
Mix localstorage and a global object.