A note about replace vs push, the Link component takes a `replace` prop that you can set to true (default is false) if you want the replace behaviour. It also has a `scroll` prop that you should set to false (default is true) if you don't want to scroll to the top of the page each time you click on an option.
We’ve actually used this technique 4 years ago on a react application, worked great and still does. We’ve also made a search component to listen for changes on the url and update a context. Our app was complex and many components had to be updated so using a context was the way to go. It’s funny though that no matter what we do we always coming back to 00’s concepts. It’s like php back in the days.
It depends on the requirements. If you're developing apps that don't share data like admin panels, use states and react. But if you're developing sites that do share data like e-commerce websites, use params and next js.
It's not a niche concept putting stuff in query parameters was how Web1.0 did things because there was no client state, we've officially come full circle.
What you mean niche concept? That’s how the internet works and always worked 😊 It’s just that some websites are broken so he’s teaching how to fix it 😅
You are so good at teaching web dev. I love that you show how something can be done with just JS and then proceed to show how a framework like Next.js makes it much simpler! Also, I really appreciate that you cover the edge cases and best practices. I'm learning a lot from watching your videos!
Great tutorial. There are situations where useState still shines better and there are situations where this method would be perfect. I remember doing same thing on a client's project earlier this year. I needed to keep the state on the url since I would be navigating back to that same page after user completed their stripe integration. Storing in useState didn't make sense to me, so I stored the state on the url and it worked perfectly. If you're dealing with object states, useState remains the best. If you do not need to persist the state when you share the url, useState is still the best.
I found your videos last week and I've seen more than 10 hours of your content. The way you explain things is amazing. Thanks, Wesley! I'm making an e-commerce myself to practice react and next.js, using app router. This solution to avoid using state and making components CC is great! I can't wait for the next js course!! 🥳
somehow your teaching method resonates best with me. There are several popular youtubers on JS but you explain why we are doing things with alternatives. Thank you.
I stumbled upon your RU-vid channel just today and had to reach out immediately to express my gratitude for the incredible content you’re sharing. Even though it's only been a day, I've already spent hours soaking in your insights. The way you explain concepts is nothing short of amazing 🔥🔥
Randomly this video popped up in my break session and I thought let's open this and omg I didn't even realized that i needed this for more efficient code. The way you explained it never felt like someone is teaching, i just watched whole video and learned without any hesitations. You are just a piece of art!
I recently started a project on a brand new framework recently (Next.js) with TypeScript as well (first typescript experience as well) and discovered this method of handling something like "state" in server components. Basically I had a product page and needed to do pagination and filtering, I did it using the query string.
Query strings are usually a lot harder to work with than useState, you have to validade the input to avoid errors, specially if you change things and the query data becames stale, but anyways query strings provides a great UX
If your data/endpoint inferred from the searchParams, it won't become stale. searchParams should be the SSOT (single source of truth). And as these are user-controlled, there should be some validation - yes. A small validation function is the trade-off for the greater UX
Validation is always an issue and honestly, in a case like this it is simply absurd to expect query parameters to exist immediately. For these things you should always have a fallback.
Thank you for this video - I've watched a lot of tutorials lately that go down the route of useState and useEffect but they never felt like the best way - glad I came across this video!
It's a great tutorial. Nice pros and good pacing with good examples. A bit of constructive feedback - I think you're missing several important points. 1) Validation - treating the URL as a single source of truth is fine - however it's super easy to mangle, incorrectly enter or purposefully break the URL - would have loved to see some patterns to deal with that. (as a side note - putting `as string` is not asserting anything - it's just telling typescript to ignore the fact that the URL param can actually be an array type) 2) Async examples - in your case - setting the attributes for the t-shirt (esp. on the server side) is straightforward. However if you have a more complicated example where the product details are being retrieved from a database - it gets tricky to validate and apply the URL params against a dynamically set object. Also need to handle resyncing the URL if they are invalid. While the pros are good - there are some cons to this that become obvious with advanced usage.
not using react or next, or tsx but this is so true! especially for modals, i like to keep my active modal info on the hash part of the url that way both page data and modal data can be placed on the url but of course you can use url params too i mean you realize that your site/app needs this the moment you refresh the page
Beautiful, it made me smile for a sec as I would write it exactly as you mentioned at the beginning via useEffect(). Now while transitioning to Next.js, I like definitely this one-way approach
Thanks for the video. I heard of this and needed to see an example of how to go about it and this went above and beyond with even the pitfalls to watch out for.
Hey! I really glad to see that someone show this method to handling state in url, but this solution has potential disadvantage. It's animations. It's harder control when they're removed from the React tree. So when I use Framer motion, I can't make nice animations. Maybe vanilla css will, idk
Thank you so much! This way of handling state is nothing knew, but I personally never put much thought into it until this video, and always defaulted to client state, with all the issues you listed. Typical aha moment. From now on you convinced me to always default to query params to handle state, unless there is a serious reason not to do so.
Another amazing video. I do have a follow-up question: In your example, the page is a presumably dynamic route? How do we utilize those dynamic elements (again, in your example, 'product' and 't-shirt') at the same time we are accessing the query-params? Thanks as always!
My Professional React & Next.js course is OUT NOW now! Find it here: bytegrad.com/courses/professional-react-nextjs -- this is the #1 resource to master the latest React & Next.js, my absolute best work.
i was looking to make a seperate context for a boolean value as a side effect of another context state change, but with the abuse of url its free state across the app😁 thank you
yes, I recently had a problem keeping state with ssr and client at the same time. It was pain in the ass, I moved it to url and it feels so good, and at the same time, url is sharable, so your state is not only in your app but you can even share it to someone and they'll immediately see the thing you want them to see. I was thinking what could be the down sides of doing this, i mean my state is not big and only about 1-3 query params most of the time? What could go bad with this ? And I just started to watch the video, and OMG the intro, he talks about all the pain points I had. This is gonna be enjoyable watch, I can smell it.
Love this solution for handling state especially when you want to set state down the tree and read it across other components. The issue I’ve run in Next 13 is setting the paean jumps you to the top of the page. Even when using replace…
i usually make a function for changing spesific item in query without effecting others, like this: changeQuery("size" , "sm") -----> change size in url to md, this will not effect others like color and name
I actually think the back button going back to the last selection is pretty bad user experience. Say you are looking at a list of tshirts, then you select one to view its color and size options, you click a few different colors and sizes to see how it looks and you then decide you want to go back to the list of tshirts to see some more, now you have to hit back a bunch of times to get back to the list or you have to click the nav bar to get back there and lose where you were in the list of tshirts in case of pagination. Sometimes devs get excited about different ways to do things that are easier for dev experience but don't actually help the user
This is a really great video :) and super interesting. I know it's nothing to do with the video but the "JavaScript magic" to make the first letter uppercase on those buttons is just "text-transform: capitalize;" in CSS 👍
In the color button section, if u want to uppercase the first letter, u can do it with css, so in tailwind u can use "uppercase" class name. Sorry if im misunderstanding ur intention.
I learned this when I was working with react router lifting state up to the url so even when user navigates around in app we can pass on this state so when they come back to same page the state doesn't get lost
mind blowing I always work with states, i'm looking foward to implement this solution in some of my works *-* and it works really good together with server side in next
Great video. One thing is I wouldn’t use useEffect to sync with the url - I know it was part of the “don’t do this example” but if you were to use state and push to the url, having the state updates and the url updates in a function that’s called when the user selects an option would be better IMO
Sounds like bad UX to force the user to go back through query params in the history, since it’s not what the user expects, but I like the idea of using query strings for the other reasons. So I would just do it the way you did before you used , and turn it into its own reusable hook.
Nice tutorial, I was curious how far you'd take this! Counter argument is: ONLY STOP using useState if you know what you're getting into! 😬 In a real world app, this will at least require - generic param handling that won't discard other params from other parts of the app from the url - generic param serialization, url-encoding and sanitizing - support for arrays + objects as params And then you'll have to take care that your URL won't grow absolutely HUGE in the next couple of months. And then, in case you don't want to send a server request for every small state change, there needs to be a client-only version of this, like a custom hook with a useState-like signature: useParam(name: string, defaultValue: T): [T, (val: T) => void]. That gets tricky as well if other components require the url state state and you have to use context. But I do agree: the benefits for medium-sized apps are worth the implementation. I wish there was a library that would do all of this + handle both the server & client side. Keep up the good work!
Great video, but how would this work if you have a search component to search something, and want to handle and display the loading state while its being fetched? a solution i could think of is using ternary but what if I wanted to use the next.js default loading.tsx file?
I agree a lot with this. I'm not really a frontend dev but when i use ecommerces that have state stored locally not in the query itself it frustrates me because I can simply send someone a link with all the right product details already choosen instead I have to tell them all the specifics
1:59 You state that this is good for SEO, but I've met experts who say the exact opposite: "search engines cannot parse url params and treat every variant as page duplication". Can you provide the source of your claim? I just wanted to read some more about this topic and any additional data to prove to SEO masters that good UX is also good practice for search optimization.
One of the problems with using this method on Next.js is that the UI does not update until page.tsx is finished rendered. So if you click "White", it will not update the UI until the client finishes fetching the next page. It will be better to maintain some client state and listen to updates so the client UI can update immediately. Let me know if I'm missing something.
Obviously i knew that but i did not have the mindset that you show in that video. Great content ! I have to say that queries can lead to security issues if the content of the query is meant to be displayed somewhere in the UI ! So in some usecases, queries have to be sanitized.
Navigation has been an absolute nightmare for apps with multiple entry points and mutiple journeys... Been wondering why we have not used query strings... hopefully we get the budget to refactor this mess...
