The approach is pretty good. But in this particular case i would do it differently. A better way imo would be to use the URL to store the state of the filters and have your filter component completely independent with 0 props. Also you can throw inside of it if it is used on a URL that is not meant to be used with product filter.
yup. Same here. Since I've made my custom useSearchParams hook, this has become a trivial thing to use filters anywhere and consume their values wherever needed
What is the best approach for doing this? Something like this? const [searchParams, setSearchParams] = useSearchParams(); const search = searchParams.get("search") || "";
Great video! The filters are saved in 2 states that update with an extra useState. Instead, I think it would be better to give the filter component both the state and the onChange as props, thus removing the extra state and the extra useEffect.
Very clear video, thank you. Could it be better to keep the state variables in the parent (App) component and pass the setters to the filters? That way you are not duplicating the state and you wouldn’t need the useEffect?
you can, but then you lose the ability to have different filters for the inputs and for the query at the same time. For example if you had a save button that applied the filters to the query on click instead of on change. The filters would still update locally onChange in the filter component, but only update the parent on click. Also you could have done it by manually calling the refetch function with the filters onChange without storing them in App. But then you wouldn't have them in the query cache. Ultimately it depends on your specific component and what you need. All of the ways I suggested are valid!
Great video and awesome content but for more code refactoring . it would be great to change filter properties to only one object instead of seperate each of them to usestate hook we can do this in only one state and it helps us to add another property easily in future 🙂 Thank so much for your great content keep going like this 🔥
I would do differently, using url as state for the filter, and pass them to the query key, in queryFn argument you have access to the query key, making it possible to read the first and second index containing the url state.
sir, that's really good content. Could you advise the best practices if there will be many filter parameters like 10 to 15, not like the 3 as this example
It is a great example of customer filter but we would like to request you to achieve the same filter by using url to store the state of the filters and please post your next video to achieve the same by using url
@15:03 - I don't understand how the search from the filter-components gets sent to the App.tsx. In my head, we would need to pass the "search" state from App.tsx to the filter--component in order to access it. Does the concept youre doing have a name, so i can read into it?
not here, because we want to control when the value changes. With useDeferredValue the re-render happens as soon as possible where as we want minimum 500ms
@@cosdensolutions I see. So it's because you want to suppress frequent re-renders, right? The debounce ensures a minimum delay between updates, which can help reduce unnecessary re-renders and potentially improve performance, especially if the onChange handler triggers expensive operations or API calls. Is that the main reasoning behind using debounce here instead of useDeferredValue?
@@logconsole-s2f yes, but not for those reasons. Frequent re-renders aren't a problem, but when each render causes a new fetch, they are. useDeferredValue will re-render as fast as the processor will allow of the user's machine. So if they have a decent computer, it will happen quickly. Each render will trigger a new fetch request, which we don't want. Using useDebounce will always delay by 500ms after last update, which is preferred when dealing with requests after each render
In my opinion, the example does not follow good practice. Problem 1: We have three so-called shadow states, i.e. the same filter states twice unnecessarily. Ideally, the logic should always be derived from one single source of truth. Problem 2: The useEffect with onChange is an unnecessary side effect that will cause problems in large apps. I would always recommend connecting the handlers (here onChange) directly to the action, i.e. to the input onChange event.
First this is not close to being senior developer code and I’m not hating at all imagine if I for example where to look at the product page and apply certain filters and then would like to share that with someone else it won’t work because when they their page loads, the page state is lost category max price, and all filters are back to their initial state. A better solution would be to store the filters as URL parameters And use them as the initial state and when user changes them update the parameters so that the state in the application matches with the search parameters and also inside the fetch product function instead of using three if statements, we could just filter the products one time and apply all the filters at the same time any product that matches all the filters will then be returned
The approach is pretty good.
But in this particular case i would do it differently.
A better way imo would be to use the URL to store the state of the filters and have your filter component completely independent with 0 props. Also you can throw inside of it if it is used on a URL that is not meant to be used with product filter.
yup. Same here. Since I've made my custom useSearchParams hook, this has become a trivial thing to use filters anywhere and consume their values wherever needed
@@leroviten I like that
What is the best approach for doing this?
Something like this?
const [searchParams, setSearchParams] = useSearchParams();
const search = searchParams.get("search") || "";
We are learning best practices and becoming a senior developer) Thank you so much 😊
Such a clean way. Much appreciated.
Great video!
The filters are saved in 2 states that update with an extra useState. Instead, I think it would be better to give the filter component both the state and the onChange as props, thus removing the extra state and the extra useEffect.
You are an incredible teacher! Thank you very much for all the time and effort you put into making these videos!
Very helpful, keep it up with these type of videos.
Very clear video, thank you.
Could it be better to keep the state variables in the parent (App) component and pass the setters to the filters? That way you are not duplicating the state and you wouldn’t need the useEffect?
I am doing the same @cosden please answer on this
you can, but then you lose the ability to have different filters for the inputs and for the query at the same time. For example if you had a save button that applied the filters to the query on click instead of on change. The filters would still update locally onChange in the filter component, but only update the parent on click.
Also you could have done it by manually calling the refetch function with the filters onChange without storing them in App. But then you wouldn't have them in the query cache.
Ultimately it depends on your specific component and what you need. All of the ways I suggested are valid!
I usually do it this way. I'd avoid unnecessary useEffect
Great video and awesome content but for more code refactoring .
it would be great to change filter properties to only one object instead of seperate each of them to usestate hook we can do this in only one state and it helps us to add another property easily in future 🙂
Thank so much for your great content keep going like this 🔥
Hi mate, appreciate for the wonderful content, please teach us how to do pagination best practice using an example.
I would do differently, using url as state for the filter, and pass them to the query key, in queryFn argument you have access to the query key, making it possible to read the first and second index containing the url state.
Yes that's also a great option
sir, that's really good content.
Could you advise the best practices if there will be many filter parameters like 10 to 15, not like the 3 as this example
It is a great example of customer filter but we would like to request you to achieve the same filter by using url to store the state of the filters and please post your next video to achieve the same by using url
Hi thanks for the best content that you have created please develope a big project from zero ❤
Is it better use queryParams to manage the filters and search??
hey really great video and btw whats the name of your theme?
Thankyou sir. Will you give videos on "React Query" in detail which is very rare?
Yeah why not
I noticed the useQuery is not inside useEffect. Does that mean anything change in the search value, the useQuery will be called?
Always bangers !!!
Hi mate, would like to suggest datetime picker and complex form input types from real world.
@15:03 - I don't understand how the search from the filter-components gets sent to the App.tsx.
In my head, we would need to pass the "search" state from App.tsx to the filter--component in order to access it.
Does the concept youre doing have a name, so i can read into it?
is adding hooks (like useState) in our useDebounce necessary?
in your search, what if the category or maxprice is null, then wouldn't setSearch give an error?
Your discord link doesn't work, same with project-react link😢
Are these links location dependent?
use reactQuery selet for filtering is good?
why react is still working when there's a typescript error?
Shouldn't we use useDefferdValue instead of debounce?
not here, because we want to control when the value changes. With useDeferredValue the re-render happens as soon as possible where as we want minimum 500ms
@@cosdensolutions
I see. So it's because you want to suppress frequent re-renders, right? The debounce ensures a minimum delay between updates, which can help reduce unnecessary re-renders and potentially improve performance, especially if the onChange handler triggers expensive operations or API calls. Is that the main reasoning behind using debounce here instead of useDeferredValue?
@@logconsole-s2f yes, but not for those reasons. Frequent re-renders aren't a problem, but when each render causes a new fetch, they are. useDeferredValue will re-render as fast as the processor will allow of the user's machine. So if they have a decent computer, it will happen quickly. Each render will trigger a new fetch request, which we don't want. Using useDebounce will always delay by 500ms after last update, which is preferred when dealing with requests after each render
that useEffect is totally unnecessary and can evolve into a mess really quick if we were to scale this up
Is the alternative useCallback?
In my opinion, the example does not follow good practice.
Problem 1: We have three so-called shadow states, i.e. the same filter states twice unnecessarily. Ideally, the logic should always be derived from one single source of truth.
Problem 2: The useEffect with onChange is an unnecessary side effect that will cause problems in large apps. I would always recommend connecting the handlers (here onChange) directly to the action, i.e. to the input onChange event.
When you solve problem 2, you don’t have problem 1 anymore 😄
Agree
First this is not close to being senior developer code and I’m not hating at all imagine if I for example where to look at the product page and apply certain filters and then would like to share that with someone else it won’t work because when they their page loads, the page state is lost category max price, and all filters are back to their initial state. A better solution would be to store the filters as URL parameters And use them as the initial state and when user changes them update the parameters so that the state in the application matches with the search parameters and also inside the fetch product function instead of using three if statements, we could just filter the products one time and apply all the filters at the same time any product that matches all the filters will then be returned
even deps in alphabet order?! maniac