And i think u should add some type if configuration to determine whether delete false param or not to delete falsy params but not the 0 value , so if the param is name= it should be removed entirely may be this should be in the third param or something or the second param should be object that has key for default value and another key for this -- i can contribute and do this if u like and if it doesn't already exist because i didn't try it
@@ahmedhassan_saver This is the `clearOnDefault` behaviour/option: when the state is set to the default value (here "josh"), it's not reflected in the URL to save space (remember URLs have limited size). If the default had been an empty string (which is more common), then you'd get no search params when clearing the input, which feels more natural.
@@ahmedhassan_saver First I have to give my two cents, then say directly what is wrong and finally admit that I haven't even looked at the code. Just WOW, dude! xD @franky47 I knew it ^^ start testing right away
@@ianik-br the main point is. You can install and read documentation to work with another library and make client heavy instead of using things already provided. It's not that hard either
@@paw565 Not anymore, since v2 you can use it with Remix, React Router and plain old React SPA (in addition to Next 14 & 15). For React Router, nuqs adds type-safety and declarative scoping to search params on top of the built-in useSearchParams hook. If you are using TanStack Router, you don't need nuqs, it's already got the good stuff baked-in.
Josh, I just want to thank you. You're my number #1 source for keeping up to date in this ever changing behemoth we call tech. You're the best. I saw you're video yesterday and I just want you to know how much you're helping others. I'd watch anything you put out.
Have been using it since next 13. Main benefit of this library is that it allows to abstract updating url without extra requests to server. Next team, are you for real? It has been two years since release of app router, where is native shallow refresh?
I would like to ask, in the ray.so snapshot app, doesn’t the URL have a maximum length? If the number of codes is large today, wouldn't it cause bugs? Is there anything wrong with my understanding? Or did he actually use other techniques to solve it?
@@DJDrewDub That's the default behaviour. You opt-in to pushing new entries on the history stack with the history: push option. (beware of breaking the Back button, great powers = great responsibilities).
not really. connecting URL and state is just one of many features that router libraries or frameworks may support. this library just focuses on this one aspect and that's fine. maybe you already have a router you can't change but that doesn't support this feature, then it's useful.
I don't understand why is this a library? Should be pretty easy to push things into the URL. On load pull in the the query params and push it to local or global state. For updating write a simple function that pushes the data to both the URL and the state. Why install yet another library for that simple task? I would keep a single source or truth by default and do this sycing only when needed. I don't use anything like redux unless absolutely required. What do you think? I would love your opnion.
Benefit of having a library like that is the biggest when you work in a team imo. You get ready set of tools, which is documented. It's easier for collaboration and for newcomers into the project. When you work solo simple util function might enough.
@@debarkamondal6406 Browsers are strange creatures with many quirks. Making something that works 50% of the time is quick. Supporting a wide range of use-cases properly and reliably takes considerably more time and care. You likely don't want to do & maintain this yourself on every project.
It depends on the framework (Next.js, Remix, React Router & plain React are supported). In Next.js, it's a client-side update by default (shallow: true, using the History API), but you can opt-in to notify the server for SSR using `shallow: false`, which does call the router.
I used it two weeks ago on a project, problem is when you try to update multiple values at the same time you will get a race condition and a unsaved state unfortunately...
or add this in settings.json and it will work in save "editor.codeActionsOnSave": { "source.fixAll": "explicit", "source.organizeImports": "explicit", "source.sortMembers": "explicit" },
so can you write your own code to handle client routing? and all of the edge cases between browsers? and keep it performant? and would it be as battle tested as nuqs?
@@PraiseYeezus And type-safe! Type-safety is 50% of the reason behind this package, the other half is the throttling mechanism to keep it working when browsers rate-limit history updates.
@@PraiseYeezus I meant this lib doesn't help a lot as personally I'd always make a small hook for updating the search query, etc. Anyway, I never said anything about implementing client routing from scratch.
It works on top of the hooks provided by each router, adding declarative scoping (working with one or a subset of search params) and type-safety, plus facilities to generate links from state variables.
Bruhhhh I literally coded this myself just a month ago 😂 all that for nothing ahaha even the transition and helper functions “parseIntPrUndefined” kinda things.
Debounce support (to do one eventual update of the URL) is on the roadmap. Configurable throttle can give you something similar, though you get one initial update (eg: one character for text inputs) then regular batches, which may or may not work for some states.
Neat idea but not practical for real use since urls have fairly short limits, even at base 64 a moderately complex form would overflow that limit. That and imagine sharing a url via email and the link is a giant block of code you have to scroll the page to see.
You wouldn't want to store absolutely all state in the URL. Only relevant pieces of what the app needs to configure its data & presentation. The rest can come from the server or stay in-memory if it doesn't need sharing or persistence.
So many things wrong with this vid... Who would ever use a third party Lib to use the query params in the URL? Also this is how it have always been done? There is nothing new? State was always ment to be kept in the URL... The react dev have really came to a full circle of life now.
@@AbhiShake-pl3cf You can create your own parsers too, JSON is good to start but looks ugly in the URL. Kind reminder that URLs are the first UI your users will see, even before hitting your server. Better make them look nice.
@@franky47 woah i cant believe the author reads these comments. I agree that it looks ugly (most browsers hide query params from url but its there when shared). How slow would converting them to b64 for url param and backconverting in every setState call be?
If you do this in a custom parser, it would be optimised: the serialise/parse functions are only called when there are actual changes. Couple that with throttleMs to reduce the update rate of the URL. For larger payloads, you could even throw compression + encoding in the mix.
One of the points raised recently was redirects: /auth/login?redirect=/dashboard, which can lead to open-redirect vulns. I'll make a community parser for this, which validates the path starts with /
Hey josh , awesome video! Your unique style really stands out. I'm a video editing specialist focused on TH-cam growth, and I can help enhance your content with high-quality edits and engaging thumbnails. If you're ever open to exploring new ideas or strategies that can boost your channel further, I'd love to connect and see how we can collaborate. Let me know your thoughts
Thanks Josh! (I'm the author of nuqs). Most people pronounce it "nucks", I pronounce it "nukes" but I'm getting around to it. AMA.
When he typed withDefault("josh") - Why didn't the url start with name=josh ?? - it should have started with this, right? 4:59
Cool package bro
And i think u should add some type if configuration to determine whether delete false param or not to delete falsy params but not the 0 value , so if the param is name= it should be removed entirely may be this should be in the third param or something or the second param should be object that has key for default value and another key for this -- i can contribute and do this if u like and if it doesn't already exist because i didn't try it
@@ahmedhassan_saver This is the `clearOnDefault` behaviour/option: when the state is set to the default value (here "josh"), it's not reflected in the URL to save space (remember URLs have limited size). If the default had been an empty string (which is more common), then you'd get no search params when clearing the input, which feels more natural.
@@ahmedhassan_saver First I have to give my two cents, then say directly what is wrong and finally admit that I haven't even looked at the code. Just WOW, dude! xD
@franky47 I knew it ^^ start testing right away
We're developing backwards if storing state in the URL is rediscovered 😄Great video though!
I think it's a baby with the bathwater scenario. People tried all URL state, then no URL state and now settling on a mix.
it's not being "rediscovered" it's being adapted to eliminate the trade offs that it used to have (another request to the server, stale values, etc)
exactly write a function yourself. Once you get the hang of it its easy. I don't understand it existing as a separate library.
Every 20 years many products, services and functions are relaunched for the new generations like "new discoveries"
@@ianik-br the main point is. You can install and read documentation to work with another library and make client heavy instead of using things already provided. It's not that hard either
This package is very useful and time-saving. I will use it in my projects
2:16 This "In-Memory" term has been living in my head rent-free for so long. Thanks boss, I just freed up some space.
if you're using react-router or tanstack router, you want to use their URL+state features instead of another library.
It's primary for next js I think
@@paw565 Not anymore, since v2 you can use it with Remix, React Router and plain old React SPA (in addition to Next 14 & 15).
For React Router, nuqs adds type-safety and declarative scoping to search params on top of the built-in useSearchParams hook.
If you are using TanStack Router, you don't need nuqs, it's already got the good stuff baked-in.
Josh, I just want to thank you. You're my number #1 source for keeping up to date in this ever changing behemoth we call tech. You're the best. I saw you're video yesterday and I just want you to know how much you're helping others. I'd watch anything you put out.
Brother, Thanks a lot for this! Really cool and useful!
checked this in the midday repo, amazing work from frank
Thank you!
Thanks for letting us know the amazing library
Wow so cool. Thank you Josh for showing this 😃
Life saver video, Josh! Thanks a ton!!
Thanks for the explanation!
This is game changing
lol
Such short videos are really useful
That's actually epic! ❤
Its very useful, thanks a lot dude
every 3 month, there's new react state management package that's super useful
Have been using it since next 13. Main benefit of this library is that it allows to abstract updating url without extra requests to server. Next team, are you for real? It has been two years since release of app router, where is native shallow refresh?
How did you get it to create a hash for some of the content that you wanted to make obscured/private in the url?
Oh it's November, and a new react state management is out, don't use this one for any sensitive data...😅
nuqs (the topic of this video) has been out for over 4 years and has close to 5k stars on GitHub. 2.0 just came out.
Amazing! Thanks
Great video ❤
I would like to ask, in the ray.so snapshot app, doesn’t the URL have a maximum length?
If the number of codes is large today, wouldn't it cause bugs?
Is there anything wrong with my understanding?
Or did he actually use other techniques to solve it?
2 things
- either they have set a limit to the amount of characters you can insert
- they hash it or reduce the size (less possibility)
Cool. But what about encrypting the state within a URL?
lol setting up query params always been a hassle, this makes it as easy as squeezing a lemon
or probably easier
Wondering what tthe example Use -Cases for this might be
the first example would pollute the window.history real quick, best way is to store them after a form submit or saving state with debouncing.
I mean you could remove the previous history at the same time as setting the current, I'd hope the author thought of this.
@@DJDrewDub That's the default behaviour. You opt-in to pushing new entries on the history stack with the history: push option. (beware of breaking the Back button, great powers = great responsibilities).
@@franky47 can the library be used in plain react projects? that's what the video seems to imply
These guys reinvented react router
not really. connecting URL and state is just one of many features that router libraries or frameworks may support.
this library just focuses on this one aspect and that's fine. maybe you already have a router you can't change but that doesn't support this feature, then it's useful.
I don't understand why is this a library? Should be pretty easy to push things into the URL. On load pull in the the query params and push it to local or global state. For updating write a simple function that pushes the data to both the URL and the state. Why install yet another library for that simple task? I would keep a single source or truth by default and do this sycing only when needed. I don't use anything like redux unless absolutely required. What do you think? I would love your opnion.
Exactly what I thought.
Benefit of having a library like that is the biggest when you work in a team imo. You get ready set of tools, which is documented. It's easier for collaboration and for newcomers into the project. When you work solo simple util function might enough.
I don't think syncing a state variable with URL is that hard. Its just 2 liner. Unless this library does anything more than that
@@debarkamondal6406 it gives you typesafety, you can with ease put entire object state into the url.
@@debarkamondal6406 Browsers are strange creatures with many quirks. Making something that works 50% of the time is quick. Supporting a wide range of use-cases properly and reliably takes considerably more time and care. You likely don't want to do & maintain this yourself on every project.
Hi Josh. Can you do a deep dive in unit testing Nextjs apps?
How this works under the hood though? Does it do router.replace for every change?
It depends on the framework (Next.js, Remix, React Router & plain React are supported). In Next.js, it's a client-side update by default (shallow: true, using the History API), but you can opt-in to notify the server for SSR using `shallow: false`, which does call the router.
@@franky47bro you are legend. You have created this awesome library and now you are actively answering questions. Cheers!
@@paw565 Founder mode.
The video is very similar to the sam selikoff's video on " How to share React component with the URL".
Is there a better way to do this in nextjs?
This feature is already in RemixJS
I wake up everyday and 1 million of javascript libraries being f*cked
I used it two weeks ago on a project, problem is when you try to update multiple values at the same time you will get a race condition and a unsaved state unfortunately...
Would you mind opening an issue for this please? repo is 47ng/nuqs.
are those the new starlight airpods? looks great!
great
just use react query button
shift + alt + 0 removes all unused import statements
or add this in settings.json and it will work in save "editor.codeActionsOnSave": {
"source.fixAll": "explicit",
"source.organizeImports": "explicit",
"source.sortMembers": "explicit"
},
@RemindMe12 thanks
Could be nice to pair with React Query too
It is! And TanStack Table too.
You can't do that always. That URL bar has limited character long
Doesn't help much to add an extra dependency, btw react router already has similar kinda hook.
so can you write your own code to handle client routing? and all of the edge cases between browsers? and keep it performant? and would it be as battle tested as nuqs?
It's just setting search params bro, chill out@@PraiseYeezus
@@PraiseYeezus And type-safe! Type-safety is 50% of the reason behind this package, the other half is the throttling
mechanism to keep it working when browsers rate-limit history updates.
@@PraiseYeezus I meant this lib doesn't help a lot as personally I'd always make a small hook for updating the search query, etc. Anyway, I never said anything about implementing client routing from scratch.
@@NilotpaulNandi Exactly
The package is called nuqs
damn i didnt knew
And it's pronounced nuqs (like GIF or SQL).
@@franky47 like nukes??
@@gurvinder1613yes
How does this lib work with other libs like react-router for example? do they overlap?
It works on top of the hooks provided by each router, adding declarative scoping (working with one or a subset of search params) and type-safety, plus facilities to generate links from state variables.
cool
Bruhhhh I literally coded this myself just a month ago 😂 all that for nothing ahaha even the transition and helper functions “parseIntPrUndefined” kinda things.
This is for "Next.js" and not "React". We need to start separating things.
Wow
Comment your this kind of mind blowing libraries..
someone tell him about preact signals, with can be used in react
Tell me more?
Yo!
If it changes the url in real time on input, you're gonna need to debounce that!
Good call!
Debounce support (to do one eventual update of the URL) is on the roadmap. Configurable throttle can give you something similar, though you get one initial update (eg: one character for text inputs) then regular batches, which may or may not work for some states.
@@franky47 Waiting for the debounce support frank
YO! subscribed
It’s 2024 and we are still seeing state management in react? Jesus!!
Gid bless you sir😊
Neat idea but not practical for real use since urls have fairly short limits, even at base 64 a moderately complex form would overflow that limit. That and imagine sharing a url via email and the link is a giant block of code you have to scroll the page to see.
You wouldn't want to store absolutely all state in the URL. Only relevant pieces of what the app needs to configure its data & presentation. The rest can come from the server or stay in-memory if it doesn't need sharing or persistence.
i use zustand😁
Yo sir
Make a video on how u started coding from zero and how u got the job.
And btw don't ignore my comment. Else I'll share your details with fbi
npm i nuqs
Really? xD Like you can't just create few lines hook for that? xD
So many things wrong with this vid... Who would ever use a third party Lib to use the query params in the URL? Also this is how it have always been done? There is nothing new? State was always ment to be kept in the URL... The react dev have really came to a full circle of life now.
or just use tanstack router
Not in next js bro
What the...
Misleading title..
Sorry, im stupid. They do have parseAsJson and parseAsArrayOf. And i loved their adapters usage
@@AbhiShake-pl3cf You can create your own parsers too, JSON is good to start but looks ugly in the URL. Kind reminder that URLs are the first UI your users will see, even before hitting your server. Better make them look nice.
@franky47 most browsers hide search params so i wouldnt mind. Objects look ugly when shared but base64 representation looks fine to me
@@franky47 woah i cant believe the author reads these comments. I agree that it looks ugly (most browsers hide query params from url but its there when shared). How slow would converting them to b64 for url param and backconverting in every setState call be?
If you do this in a custom parser, it would be optimised: the serialise/parse functions are only called when there are actual changes. Couple that with throttleMs to reduce the update rate of the URL. For larger payloads, you could even throw compression + encoding in the mix.
I would not recommend this approach for a prod app. Security is a big issue here, also many ways of retaining data without using URL params.
One of the points raised recently was redirects: /auth/login?redirect=/dashboard, which can lead to open-redirect vulns. I'll make a community parser for this, which validates the path starts with /
Php again
3
6
try this? NO
It's 'nuqs' BTW. Pretty frustrating to not mention the npm package name anywhere in the video description.
1:10
He literally spell it at 1:30
the internet really is full of bots. no one reads, no one actually watches content, they just comment. incredible.
Posting this comment without actually watching a minute and a half into the video is wild!
bro it's literally in the thumbnail
2
React came as a happy framework but with many problems and now we are using hundreds of external libraries to fix React 😅
just use vue
Just use farming
1
lol
who the hell needs state management? keep your app simple ffs. Developers always overcomplicating things
When app shares state between components, you'll need a way to manage state efficiently. That's why.
But yeah for most projects, it's unnecessary.
so, a wrapper around window.history.replaceState?
Hey josh , awesome video! Your unique style really stands out. I'm a video editing specialist focused on TH-cam growth, and I can help enhance your content with high-quality edits and engaging thumbnails. If you're ever open to exploring new ideas or strategies that can boost your channel further, I'd love to connect and see how we can collaborate. Let me know your thoughts
Wow