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.
@SashaInTheCloud10 ай бұрын
I feel so old
@gintoki_sakata__10 ай бұрын
The sarcasm here 😂
@SimonCoulton10 ай бұрын
Topkek
@vaisakhkm78310 ай бұрын
😂
@goldforest0610 ай бұрын
XD
@blahblahblah314910 ай бұрын
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.
@Ziko2687s810 ай бұрын
Unless you don't want that info shared, like cart data or some data that needs to be stored in the browser storage.
@fifty-plus10 ай бұрын
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.
@OnePieceWonPeace10 ай бұрын
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.
@CottidaeSEA10 ай бұрын
@@Ziko2687s8 Cart data should be session based, so there's a pretty big difference in my opinion.
@oreqizer10 ай бұрын
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.
@c7rsed11810 ай бұрын
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
@rumisbadforyou967010 ай бұрын
My man just discovered how absolutely every online store page has been working since 2005! Great job
@NuncNuncNuncNunc10 ай бұрын
More like 1996
@chriss340410 ай бұрын
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!
@TheSilasbulan10 ай бұрын
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. ❤
@JonnyJKF10 ай бұрын
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.
@dzienisz10 ай бұрын
@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?
@user-dn7yl7ms1u10 ай бұрын
@@dzienisz if only the seniors shared more tips/were more straight forward instead of gatekeeping we self taught devs would be happy to listen ;)
@orosales123e10 ай бұрын
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.
@31redorange0810 ай бұрын
Just because many people don't know how to SPA doesn't make you less uncool as a PHP "dev".
@SebastianSativaLivemore10 ай бұрын
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!
@ShredEngineerPhD7 ай бұрын
True, brother
@angelcaru4 ай бұрын
Soon we'll ditch JS frameworks! Soon...
@boreddad42010 ай бұрын
theo: react is the best abstraction for web dev also theo: don't use any of reacts built in features
@t3dotgg10 ай бұрын
...fairly accurate tbh
@frattaro855610 ай бұрын
Reminds me of: the best typescript is no typescript at all
@SashaInTheCloud10 ай бұрын
Dat foolish consistency is the hobgoblin of little minds n we don't take kindly to hobgoblins in these here parts
@dairyisfine10 ай бұрын
can’t help that both things are true
@aritrachatterjee418910 ай бұрын
the best product is no product at all
@imbaedin10 ай бұрын
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.
@rand0mtv66010 ай бұрын
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.
@LukeCreates10 ай бұрын
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.
@dealloc10 ай бұрын
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.
@magne604910 ай бұрын
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).
@mage369010 ай бұрын
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.
@lukasalvarezdev10 ай бұрын
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
@miggu10 ай бұрын
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.
@bevakad10 ай бұрын
It is like going back to 1999. I like it.
@henrmota10 ай бұрын
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.
@peterdenham10 ай бұрын
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.
@davidmartensson27310 ай бұрын
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.
@NuncNuncNuncNunc10 ай бұрын
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
@davidmartensson27310 ай бұрын
@@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.
@evgeniiegorov26110 ай бұрын
Url state management seems like "It's great until it's terrible" thing. Pretty much like all other tech
@anbiniyar6 ай бұрын
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!
@jozekuhar289510 ай бұрын
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.
@blueprint700010 ай бұрын
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 .
@pandasoniccollective10 ай бұрын
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. ❤
@thegrumpydeveloper10 ай бұрын
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.
@helleye31110 ай бұрын
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?
@charltonphan10 ай бұрын
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
@GdeVseSvobodnyeNiki10 ай бұрын
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.
@TheBuddilla10 ай бұрын
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.
@lpon975710 ай бұрын
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
@caczus10 ай бұрын
you should use link rel=“canonical” to address this
@CottidaeSEA10 ай бұрын
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.
@DarenC10 ай бұрын
I used the URL for state back in 1995. Boy, was I ahead of my time! cgi-bin 4 lyfe!
@Johnny_JTH10 ай бұрын
How did Lee Robinson make that video with the huge cursor and subtle animations?
@rand0mtv66010 ай бұрын
Lee mentioned it in comments on his latest video. It's called "Screen Studio".
@dairyisfine10 ай бұрын
thank god people are making more videos about this lately
@joshuaborseth10 ай бұрын
Haven’t even watched this yet but THANK YOU FOR MAKING THIS
@_romeopeter9 ай бұрын
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.
@guxit10 ай бұрын
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!
@jonathanbriggs416810 ай бұрын
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.
@matt1988ish4 ай бұрын
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.
@deeves365010 ай бұрын
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
@israel545010 ай бұрын
Who knew what I needed for so long, was just url utilization
@thelinuxlich10 ай бұрын
Offtopic: Theo is slowly becoming Heimerdinger
@DexterMorgan10 ай бұрын
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.
@includenull10 ай бұрын
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.
@alexenax11099 ай бұрын
Great video as usual!
@suuunly10 ай бұрын
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.
@BoodskiBro10 ай бұрын
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.
@keithjohnson651010 ай бұрын
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.
@claytonkruse7 ай бұрын
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.
@TonyGustafsson10 ай бұрын
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?
@patricknelson10 ай бұрын
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.
@genesisxyz7 ай бұрын
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
@tyronemguni389510 ай бұрын
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.
@dealloc10 ай бұрын
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.
@tyronemguni389510 ай бұрын
@@dealloc Lovely response man. Thanks
@eindbaas10 ай бұрын
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).
@MRtorki5510 ай бұрын
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.
@FabuBrik10 ай бұрын
Wow truly revolutionary
@JordanRiser10 ай бұрын
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.
@ricoaw50010 ай бұрын
I remember ever visit google documentation which use url when tab changes.
@ashish_prajapati_tr10 ай бұрын
url state management is great way to persist the state. like for persisting table sorting status, pagination etc.
@bassemmagdi667110 ай бұрын
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
@echobucket10 ай бұрын
Also the other place state is stored that people forget about is the actual DOM. it's literally the state of the page.
@RhysSullivan10 ай бұрын
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
@Sammysapphira10 ай бұрын
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
@restartit178810 ай бұрын
@@Sammysapphira wcag
@Theguy831blah10 ай бұрын
@@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
@rand0mtv66010 ай бұрын
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.
@rand0mtv66010 ай бұрын
@@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.
@trongquocnguyen278610 ай бұрын
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.
@trongquocnguyen278610 ай бұрын
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
@yohendryy10 ай бұрын
The best state management a browser can provide is the HTML, remember the old 'data-' props?
@mattburgess569710 ай бұрын
I love watching everyone “discover” the patterns Ember has been advocating for a decade while simultaneously smirking at Ember.
@dalechyn10 ай бұрын
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
@Atmos4110 ай бұрын
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!
@joelv449510 ай бұрын
Probably would be pretty straightforward to define a hook that consumes a zod schema to reference the query params.
@firebrickfilmstv10 ай бұрын
Me: I want deep linking! Mum: We have deep linking at home deep linking at home:
@TeaBroski8 ай бұрын
Blowing my mind
@TeaBroski8 ай бұрын
you need to be veeery careful for xss tho
@jhonyhndoea10 ай бұрын
Yup. URLs and😮 Cookies is all you need🎉
@kiyov0910 ай бұрын
this is a hard requirement for every feature we do in my company, super useful to have everything in the URL.
@BosonCollider10 ай бұрын
React is slowly catching up to the usability that PHP web sites had over two decades ago as react devs learn basic web development
@natescode10 ай бұрын
😂 exactly. They're so "smart"
@solvm165210 ай бұрын
excellent point
@pyplacca10 ай бұрын
Would it be better to use replace instead of push in this case to make backwards navigation less annoying for the user
@jamonh10 ай бұрын
Turns out that globally accessible, easily exported / restored state is valuable.
@stefangarofalo313110 ай бұрын
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()?
@franciscokloganb10 ай бұрын
I am surprised people are only thinking about this now. Been doing this since college. I blame brogrammers for reinventing the wheel. 😂
@armanmasangkay651323 күн бұрын
We are doing that on PHP way back the time of the dinosaurs
@darylphuah10 ай бұрын
Isn't this how the web was always built till JS devs went bonkers with frontend frameworks.
@ilyayy10 ай бұрын
Jotai's atomWithLocation and atomWithHash 😉
@aleksanderpasato691610 ай бұрын
any library recommendations for next js?
@codingtranquility10 ай бұрын
This feels like a bell curve meme moment ... but yeah this is nice
@oblivion_285210 ай бұрын
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
@duyphamlive9 ай бұрын
Sorry, could you share original link video of Lee Robinson talk relate the URLS
@2mbst110 ай бұрын
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.
@Leto2ndAtreides10 ай бұрын
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.
@RakeGrayFox10 ай бұрын
CSRF & XSS entered the chat
@GamerBoyRobby10 ай бұрын
What about api tokens for the front end. That would be better to store in state regardless right?
@MaartenBusstra10 ай бұрын
This is the way
@bevik1210 ай бұрын
So is it recommended now for personal projects with React or keep using only State. There things make beginners confused.
@Wizatek10 ай бұрын
Been using the URL since PHP3 for this
@ness-ee10 ай бұрын
URL has always been and will always be the single source of truth
@samuelwittlinger779010 ай бұрын
I wish there was a better way of handling search params in next, currently it is really lacking type safety.
@johnchristiancabrera647210 ай бұрын
I’m like 🤯🤯
@leniwyFok10 ай бұрын
The problem is where you have, a lot more complicated app with dozens of filters, and the URL starts to get 1km long
@RamkrishanYT10 ай бұрын
also when you shut down the PC and reboot, the state holds, also goes for browser crashes
@VincenzoCassaro10 ай бұрын
URLThing opportunity? 👀
@asagiai496510 ай бұрын
Query Params are underrated unless . . . you are using php or node
@vaisakhkm78310 ай бұрын
Those are at server side right? Only function of the server is to respond for correct path and query params, here we are talking about client side state management (or idk anything new in server side, my old java brain which still maintianing 20y old app doesn't know new tech )
@asagiai496510 ай бұрын
@@vaisakhkm783 yes that's technically true, but you can also passed this from the client side. and made the server side handle the state management or something. But my point on my comment is query params is not underrated. Some people forget about it, because of React.
@vaisakhkm78310 ай бұрын
@@asagiai4965 got it
@MarcelRobitaille10 ай бұрын
It drives me crazy that azure devops doesn't put important stuff in the URL but puts stuff I wouldn't expect in the URL and in history
@CathalMacDonnacha9 ай бұрын
There is a max character length for the url though right?
@HolgerNestmann10 ай бұрын
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
@br3nto10 ай бұрын
Nice to bring this to client rendered apps. This is REST API and server sided rendering 101.