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
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?
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 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?
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.
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...
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.
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.
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.
@@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.
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.
Wow so cool. Thank you Josh for showing this 😃
Brother, Thanks a lot for this! Really cool and useful!
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.
Life saver video, Josh! Thanks a ton!!
checked this in the midday repo, amazing work from frank
Thank you!
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
Thanks for letting us know the amazing library
That's actually epic! ❤
Its very useful, thanks a lot dude
Such short videos are really useful
Thanks for the explanation!
every 3 month, there's new react state management package that's super useful
This is game changing
lol
Amazing! Thanks
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.
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?
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.
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.
lol setting up query params always been a hassle, this makes it as easy as squeezing a lemon
or probably easier
Hi Josh. Can you do a deep dive in unit testing Nextjs apps?
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)
This feature is already in RemixJS
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.
are those the new starlight airpods? looks great!
Wondering what tthe example Use -Cases for this might be
YO! subscribed
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.
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!
The package is called nuqs
damn i didnt knew
And it's pronounced nuqs (like GIF or SQL).
@@franky47 like nukes??
@@gurvinder1613yes
cool
Could be nice to pair with React Query too
It is! And TanStack Table too.
Can someone explain the difference between useQueryState from nuqs and just using params?
Type safety and ease of use
You can't do that always. That URL bar has limited character long
Bruhhhh I literally coded this myself just a month ago 😂 all that for nothing ahaha even the transition and helper functions “parseIntPrUndefined” kinda things.
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
just use react query button
It’s 2024 and we are still seeing state management in react? Jesus!!
Comment your this kind of mind blowing libraries..
I wake up everyday and 1 million of javascript libraries being f*cked
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
Wow
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.
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.
someone tell him about preact signals, with can be used in react
Tell me more?
npm i nuqs
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.
What the...
Php again
Really? xD Like you can't just create few lines hook for that? xD
try this? NO
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.
3
1
lol
or just use tanstack router
Not in next js bro
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!
6
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
Doing this yourself is literally a 10 minutes job
What's the point 😅
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?
Wow