My Favorite State Manager Is...URLs?

[@IvanRandomDude]

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.

[@SashaInTheCloud]

I feel so old

[@gintoki_sakata__]

The sarcasm here 😂

[@SimonCoulton]

Topkek

[@vaisakhkm783]

😂

[@goldforest06]

XD

[@blahblahblah3149]

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.

[@Ziko2687s8]

Unless you don't want that info shared, like cart data or some data that needs to be stored in the browser storage.

[@fifty-plus]

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.

[@OnePieceWonPeace]

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.

[@CottidaeSEA]

@@Ziko2687s8 Cart data should be session based, so there's a pretty big difference in my opinion.

[@oreqizer]

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.

[@c7rsed118]

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

[@rumisbadforyou9670]

My man just discovered how absolutely every online store page has been working since 2005! Great job

[@NuncNuncNuncNunc]

More like 1996

[@chriss3404]

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!

[@TheSilasbulan]

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. ❤

[@JonnyJKF]

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.

[@dzienisz]

@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-dn7yl7ms1u]

@@dzienisz if only the seniors shared more tips/were more straight forward instead of gatekeeping we self taught devs would be happy to listen ;)

[@orosales123e]

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.

[@31redorange08]

Just because many people don't know how to SPA doesn't make you less uncool as a PHP "dev".

[@SebastianSativaLivemore]

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!

[@ShredEngineerPhD]

True, brother

[@angelcaru]

Soon we'll ditch JS frameworks! Soon...

[@boreddad420]

theo: react is the best abstraction for web dev also theo: don't use any of reacts built in features

[@t3dotgg]

...fairly accurate tbh

[@frattaro8556]

Reminds me of: the best typescript is no typescript at all

[@SashaInTheCloud]

Dat foolish consistency is the hobgoblin of little minds n we don't take kindly to hobgoblins in these here parts

[@dairyisfine]

can’t help that both things are true

[@aritrachatterjee4189]

the best product is no product at all

[@imbaedin]

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.

[@rand0mtv660]

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.

[@LukeCreates]

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.

[@dealloc]

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.

[@magne6049]

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).

[@mage3690]

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.

[@lukasalvarezdev]

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

[@miggu]

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.

[@bevakad]

It is like going back to 1999. I like it.

[@henrmota]

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.

[@peterdenham]

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.

[@davidmartensson273]

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.

[@NuncNuncNuncNunc]

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

[@davidmartensson273]

@@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.

[@evgeniiegorov261]

Url state management seems like "It's great until it's terrible" thing. Pretty much like all other tech

[@anbiniyar]

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!

[@jozekuhar2895]

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.

[@blueprint7000]

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 .

[@pandasoniccollective]

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. ❤

[@thegrumpydeveloper]

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.

[@helleye311]

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?

[@charltonphan]

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

[@GdeVseSvobodnyeNiki]

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.

[@TheBuddilla]

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.

[@lpon9757]

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

[@caczus]

you should use link rel=“canonical” to address this

[@CottidaeSEA]

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.

[@DarenC]

I used the URL for state back in 1995. Boy, was I ahead of my time! cgi-bin 4 lyfe!

[@Johnny_JTH]

How did Lee Robinson make that video with the huge cursor and subtle animations?

[@rand0mtv660]

Lee mentioned it in comments on his latest video. It's called "Screen Studio".

[@dairyisfine]

thank god people are making more videos about this lately

[@joshuaborseth]

Haven’t even watched this yet but THANK YOU FOR MAKING THIS

[@_romeopeter]

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.

[@guxit]

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!

[@jonathanbriggs4168]

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.

[@matt1988ish]

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.

[@deeves3650]

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

[@israel5450]

Who knew what I needed for so long, was just url utilization

[@thelinuxlich]

Offtopic: Theo is slowly becoming Heimerdinger

[@DexterMorgan]

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.

[@includenull]

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.

[@alexenax1109]

Great video as usual!

[@suuunly]

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.

[@BoodskiBro]

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.

[@keithjohnson6510]

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.

[@claytonkruse]

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.

[@TonyGustafsson]

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?

[@patricknelson]

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.

[@genesisxyz]

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

[@tyronemguni3895]

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.

[@dealloc]

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.

[@tyronemguni3895]

@@dealloc Lovely response man. Thanks

[@eindbaas]

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).

[@MRtorki55]

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.

[@FabuBrik]

Wow truly revolutionary

[@JordanRiser]

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.

[@ricoaw500]

I remember ever visit google documentation which use url when tab changes.

[@ashish_prajapati_tr]

url state management is great way to persist the state. like for persisting table sorting status, pagination etc.

[@bassemmagdi6671]

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

[@echobucket]

Also the other place state is stored that people forget about is the actual DOM. it's literally the state of the page.

[@RhysSullivan]

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

[@Sammysapphira]

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

[@restartit1788]

@@Sammysapphira wcag

[@Theguy831blah]

⁠@@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

[@rand0mtv660]

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.

[@rand0mtv660]

@@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.

[@trongquocnguyen2786]

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.

[@trongquocnguyen2786]

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

[@yohendryy]

The best state management a browser can provide is the HTML, remember the old 'data-' props?

[@mattburgess5697]

I love watching everyone “discover” the patterns Ember has been advocating for a decade while simultaneously smirking at Ember.

[@dalechyn]

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

[@Atmos41]

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!

[@joelv4495]

Probably would be pretty straightforward to define a hook that consumes a zod schema to reference the query params.

[@firebrickfilmstv]

Me: I want deep linking! Mum: We have deep linking at home deep linking at home:

[@TeaBroski]

Blowing my mind

[@TeaBroski]

you need to be veeery careful for xss tho

[@jhonyhndoea]

Yup. URLs and😮 Cookies is all you need🎉

[@kiyov09]

this is a hard requirement for every feature we do in my company, super useful to have everything in the URL.

[@BosonCollider]

React is slowly catching up to the usability that PHP web sites had over two decades ago as react devs learn basic web development

[@natescode]

😂 exactly. They're so "smart"

[@solvm1652]

excellent point

[@pyplacca]

Would it be better to use replace instead of push in this case to make backwards navigation less annoying for the user

[@jamonh]

Turns out that globally accessible, easily exported / restored state is valuable.

[@stefangarofalo3131]

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()?

[@franciscokloganb]

I am surprised people are only thinking about this now. Been doing this since college. I blame brogrammers for reinventing the wheel. 😂

[@armanmasangkay6513]

We are doing that on PHP way back the time of the dinosaurs

[@darylphuah]

Isn't this how the web was always built till JS devs went bonkers with frontend frameworks.

[@ilyayy]

Jotai's atomWithLocation and atomWithHash 😉

[@aleksanderpasato6916]

any library recommendations for next js?

[@codingtranquility]

This feels like a bell curve meme moment ... but yeah this is nice

[@oblivion_2852]

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

[@duyphamlive]

Sorry, could you share original link video of Lee Robinson talk relate the URLS

[@2mbst1]

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.

[@Leto2ndAtreides]

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.

[@RakeGrayFox]

CSRF & XSS entered the chat

[@GamerBoyRobby]

What about api tokens for the front end. That would be better to store in state regardless right?

[@MaartenBusstra]

This is the way

[@bevik12]

So is it recommended now for personal projects with React or keep using only State. There things make beginners confused.

[@Wizatek]

Been using the URL since PHP3 for this

[@ness-ee]

URL has always been and will always be the single source of truth

[@samuelwittlinger7790]

I wish there was a better way of handling search params in next, currently it is really lacking type safety.

[@johnchristiancabrera6472]

I’m like 🤯🤯

[@leniwyFok]

The problem is where you have, a lot more complicated app with dozens of filters, and the URL starts to get 1km long

[@RamkrishanYT]

also when you shut down the PC and reboot, the state holds, also goes for browser crashes

[@VincenzoCassaro]

URLThing opportunity? 👀

[@asagiai4965]

Query Params are underrated unless . . . you are using php or node

[@vaisakhkm783]

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 )

[@asagiai4965]

@@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.

[@vaisakhkm783]

@@asagiai4965 got it

[@MarcelRobitaille]

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

[@CathalMacDonnacha]

There is a max character length for the url though right?

[@HolgerNestmann]

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

[@br3nto]

Nice to bring this to client rendered apps. This is REST API and server sided rendering 101.