searchParams as a method of holding state client-side
Answered
Ocicat posted this in #help-forum
OcicatOP
Hi everyone,
I had this idea of creating reusable composable components to hold their state in the URL via search params. I got it to work, but trying to use that global state held in the URL as a query string to filter out data entirely client-side, with no additional fetching to the database, has proven to be extremely laggy and unsustainable.
After searching around, I found this thread: https://github.com/vercel/next.js/issues/52870 My understanding is that there is/was some sort of issue with the App router and searchParams.
Has this been resolved or has a way to circumvent the problem been found? If not, I will just have to revert back to good old useState().
Thanks for your time!
I had this idea of creating reusable composable components to hold their state in the URL via search params. I got it to work, but trying to use that global state held in the URL as a query string to filter out data entirely client-side, with no additional fetching to the database, has proven to be extremely laggy and unsustainable.
After searching around, I found this thread: https://github.com/vercel/next.js/issues/52870 My understanding is that there is/was some sort of issue with the App router and searchParams.
Has this been resolved or has a way to circumvent the problem been found? If not, I will just have to revert back to good old useState().
Thanks for your time!
Answered by B33fb0n3
yes. Of course third partys can slow down your app. But if you think around the other way: if you have no correct solution, that also slow down your app (like you see now). So use the third partys, that are really useful for your case and install them.
Nusq only updates the clientstate and you can choose if you want to refresh the component (for example to render search results) or only update it clientside. You can also add debouncing to the nusq refreshes of server components
Nusq only updates the clientstate and you can choose if you want to refresh the component (for example to render search results) or only update it clientside. You can also add debouncing to the nusq refreshes of server components
17 Replies
@Ocicat Hi everyone,
I had this idea of creating reusable composable components to hold their state in the URL via search params. I got it to work, but trying to use that global state held in the URL as a query string to filter out data entirely client-side, with no additional fetching to the database, has proven to be extremely laggy and unsustainable.
After searching around, I found this thread: https://github.com/vercel/next.js/issues/52870 My understanding is that there is/was some sort of issue with the App router and searchParams.
Has this been resolved or has a way to circumvent the problem been found? If not, I will just have to revert back to good old useState().
Thanks for your time!
I like this: https://nuqs.47ng.com/
OcicatOP
Hi @B33fb0n3 . Thanks for your suggestion.
Is it normal to experience this kind of lag when using searchParams in Next,js14 App router? The lag , mind you, is just to filter data clien side. I'm not even fecthing new data from the Databse based on those search params.
I'm trying to decided whether my implementation is terrible or if I should blame Next,
Is it normal to experience this kind of lag when using searchParams in Next,js14 App router? The lag , mind you, is just to filter data clien side. I'm not even fecthing new data from the Databse based on those search params.
I'm trying to decided whether my implementation is terrible or if I should blame Next,
@Ocicat Hi <@301376057326567425> . Thanks for your suggestion.
Is it normal to experience this kind of lag when using searchParams in Next,js14 App router? The lag , mind you, is just to filter data clien side. I'm not even fecthing new data from the Databse based on those search params.
I'm trying to decided whether my implementation is terrible or if I should blame Next,
well.. I haven't seen your code yet. Before I known nuqs I just pushed it via the router and the result was: laggy pages. After using nuqs everything is fine and it's like updating a usestate, but with the save inside the url. Pretty nice ^^
OcicatOP
@B33fb0n3 , the searchBar i still laggy.
What do you think of this:
Can this be improved to get rid of the lag?
What do you think of this:
import { ChangeEvent , useCallback } from "react";
import { useRouter, usePathname, useSearchParams } from "next/navigation";
type SearchBarProps = {
label: string;
};
const SearchBar = ({ label }: SearchBarProps) => {
const router = useRouter();
const pathName = usePathname()
const existingSearchParams = useSearchParams();
const existingSearchBarSearchParams = existingSearchParams.get(label);
const handleOnChange = (event: ChangeEvent<HTMLInputElement>) =>
{
const newSearchParams = new URLSearchParams(existingSearchParams);
newSearchParams.set(label, event.target.value);
const newQueryString = newSearchParams.toString();
const newURL = `${pathName}?${newQueryString}`;
router.replace(newURL);
};
return (
<div className="flex h-full">
<div className="flex items-center space-x-1">
<label
htmlFor="searchBar"
className="flex border-s-[0.7px] border-black ps-1.5 font-aperçu text-sm font-[700] leading-[.5rem] tracking-wide text-black small-caps dark:text-neutral-300 md:text-xs"
>
{`${label}:`}
</label>
<div className="flex items-baseline">
<input
type="text"
id="searchBar"
onChange={handleOnChange}
value={existingSearchBarSearchParams as string}
className="h-4 w-full appearance-none border-b border-black bg-neutral-300 pb-[.1rem] font-aperçu focus:border-b focus:outline-none dark:border-[#D9D9D9] md:text-xs"
/>
</div>
</div>
</div>
);
};
export default SearchBar;Can this be improved to get rid of the lag?
@Ocicat <@301376057326567425> , the searchBar i still laggy.
What do you think of this:
typescript
import { ChangeEvent , useCallback } from "react";
import { useRouter, usePathname, useSearchParams } from "next/navigation";
type SearchBarProps = {
label: string;
};
const SearchBar = ({ label }: SearchBarProps) => {
const router = useRouter();
const pathName = usePathname()
const existingSearchParams = useSearchParams();
const existingSearchBarSearchParams = existingSearchParams.get(label);
const handleOnChange = (event: ChangeEvent<HTMLInputElement>) =>
{
const newSearchParams = new URLSearchParams(existingSearchParams);
newSearchParams.set(label, event.target.value);
const newQueryString = newSearchParams.toString();
const newURL = `${pathName}?${newQueryString}`;
router.replace(newURL);
};
return (
<div className="flex h-full">
<div className="flex items-center space-x-1">
<label
htmlFor="searchBar"
className="flex border-s-[0.7px] border-black ps-1.5 font-aperçu text-sm font-[700] leading-[.5rem] tracking-wide text-black small-caps dark:text-neutral-300 md:text-xs"
>
{`${label}:`}
</label>
<div className="flex items-baseline">
<input
type="text"
id="searchBar"
onChange={handleOnChange}
value={existingSearchBarSearchParams as string}
className="h-4 w-full appearance-none border-b border-black bg-neutral-300 pb-[.1rem] font-aperçu focus:border-b focus:outline-none dark:border-[#D9D9D9] md:text-xs"
/>
</div>
</div>
</div>
);
};
export default SearchBar;
Can this be improved to get rid of the lag?
yea, you experience the same, that I just said 🙂
Before I known nuqs I just pushed it via the router and the result was: laggy pages
After using nuqs everything is fineI recommend you using nuqs, to get rid of the lag
OcicatOP
@B33fb0n3 , looking at hte code, do you notice any glarring mistakes?
@Ocicat <@301376057326567425> , looking at hte code, do you notice any glarring mistakes?
yes, this is the problem:
router.replace(newURL);OcicatOP
@B33fb0n3 , what would you replace that with? .push?
do you read my messages? I am saying to you, that you should use nusq to get rid the of the lag.
OcicatOP
@B33fb0n3 Ah, sorry. I thought you meant there wereadditional problems in the code, that should be solved before , or in parallel, to using nusq .
My bad.
My bad.
ah sorry, I made it not clear enought. You know how to use nusq?
OcicatOP
No, but if I have to, I will learn to. I was trying not to use too many third-party libraries. So I was ready to debounce the input. But debouncing also requires a thrid-party libary. So there's that.
I take it taht nusq updates teh URL via some other method , othr than router.repalce/push, that is.
I take it taht nusq updates teh URL via some other method , othr than router.repalce/push, that is.
yes. Of course third partys can slow down your app. But if you think around the other way: if you have no correct solution, that also slow down your app (like you see now). So use the third partys, that are really useful for your case and install them.
Nusq only updates the clientstate and you can choose if you want to refresh the component (for example to render search results) or only update it clientside. You can also add debouncing to the nusq refreshes of server components
Nusq only updates the clientstate and you can choose if you want to refresh the component (for example to render search results) or only update it clientside. You can also add debouncing to the nusq refreshes of server components
Answer
try it: https://nuqs.47ng.com/
OcicatOP
@B33fb0n3 , thanks. That's helpful guidance!