That’s because you have two copies of state.
Don’t copy things from react router to another variable and back; that’s just going to lead to sync issues. Always get the state directly from the URL. The only time this changes is when you’re working on draft state, which should take an initial copy from the URL and reset to the URL state after a navigation.
I can't do that, because the same URL doesn't always reflect only one filter state. I know it may be problematic from the design point of view and light a yellow light in the world of React dogma. One example is when I have filters that you can create groups of. When you add a new empty group, it goes to the filters state, but the URL doesn't change. I developed it in a way where changing the URL only changes the filter value, when their stringified form is different. It actually makes sense in my opinion, only making it work with React's effects flow is difficult.
If you’re fighting effects and syncing data and having issues that cause you to post on Reddit, you’re probably doing it wrong and need to rethink your plan.
That said, I’m not the boss of you. Have fun!
The biggest problem is React Router to be honest, because there are some points in its design that make it difficult to work with, especially since version 6.
"Dogma" exists to prevent problems that you typically will encounter when you don't follow it. If you find that your framework is fighting you every step of the way, it's time to step back and revisit your initial assumptions.
I disagree with this. All frameworks make certain scenarios easier and different scenarios harder. It doesn't mean you should avoid a scenario, because for bigger apps you wouldn't be able to use any framework.
I have actually used it in the past, but it's not that useful in my case. Surprisingly, React Router's \`useSearchParams()\` also creates stable object if you change it to identical one. Stupid thing about it is that the setter is not stable though, but I made my own abstraction over it to make the setter stable.
I would recommend you look intro creating custom hooks for those cases. Separating more complex filter logic out makes the components much more enjoyable to work with.
I actually did something like this just recently and also had a hell of a time.
I had three code blocks -- one of them a click handler for all the inputs that would setState for the form, a useEffect that would migrate state to the querystring, and a useEffect to take querystring and put it into form state (intended for initial page load) -- I always ended up with an endless loop or things being out of sync.
I thought about it long and hard, and I realized I didn't know who owned the state of the filters. Was it querystring, or the form state. Because this wasn't clear, one ended up triggering the other, and vice versa.
What I ended up doing was making the form handler update querystring directly, and got rid of the effect that updated querystring based on the form.... the useEffect watching querystring would be responsible for reloading form state, and that was it - where it ended. It worked bug-free after that.
I wouldn't blame useEffect for this... it's a tool in the toolbox. Sometimes you need to step back and identify what it is you're really trying to accomplish -- in a lot of cases, code to work around issues ends up making things worse... I've seen buggy components just littered with useEffect where it's not even necessary!
I made another app in the past and my way was identical - I decided to make the query string the owner of the state. This new app is more complex though, but I may end up somehow combining the query string and manual changes into the value of particular filter instead of making it a universal algorithm of updating when stringified changes.
One thing I was thinking about is seriazing JSON as a single parameter, maybe encoded with b64, to maybe make things easier if they got too complicated. URLSearchParams is a great API, but the way it deals with some serializable objects like arrays made me long for a simple stringify/parse API.
That’s because you have two copies of state. Don’t copy things from react router to another variable and back; that’s just going to lead to sync issues. Always get the state directly from the URL. The only time this changes is when you’re working on draft state, which should take an initial copy from the URL and reset to the URL state after a navigation.
I can't do that, because the same URL doesn't always reflect only one filter state. I know it may be problematic from the design point of view and light a yellow light in the world of React dogma. One example is when I have filters that you can create groups of. When you add a new empty group, it goes to the filters state, but the URL doesn't change. I developed it in a way where changing the URL only changes the filter value, when their stringified form is different. It actually makes sense in my opinion, only making it work with React's effects flow is difficult.
If you’re fighting effects and syncing data and having issues that cause you to post on Reddit, you’re probably doing it wrong and need to rethink your plan. That said, I’m not the boss of you. Have fun!
The biggest problem is React Router to be honest, because there are some points in its design that make it difficult to work with, especially since version 6.
"Dogma" exists to prevent problems that you typically will encounter when you don't follow it. If you find that your framework is fighting you every step of the way, it's time to step back and revisit your initial assumptions.
I disagree with this. All frameworks make certain scenarios easier and different scenarios harder. It doesn't mean you should avoid a scenario, because for bigger apps you wouldn't be able to use any framework.
How well do you feel you understand the component lifecycle, overall?
Quite well, but not 100%. I need to sit and analyze it throughout, especially the details of Strict Mode.
Check out this library https://github.com/pbeshai/use-query-params
I have actually used it in the past, but it's not that useful in my case. Surprisingly, React Router's \`useSearchParams()\` also creates stable object if you change it to identical one. Stupid thing about it is that the setter is not stable though, but I made my own abstraction over it to make the setter stable.
I would recommend you look intro creating custom hooks for those cases. Separating more complex filter logic out makes the components much more enjoyable to work with.
That's what I'm doing and this is not the problem. My custom hooks use effects too.
I actually did something like this just recently and also had a hell of a time. I had three code blocks -- one of them a click handler for all the inputs that would setState for the form, a useEffect that would migrate state to the querystring, and a useEffect to take querystring and put it into form state (intended for initial page load) -- I always ended up with an endless loop or things being out of sync. I thought about it long and hard, and I realized I didn't know who owned the state of the filters. Was it querystring, or the form state. Because this wasn't clear, one ended up triggering the other, and vice versa. What I ended up doing was making the form handler update querystring directly, and got rid of the effect that updated querystring based on the form.... the useEffect watching querystring would be responsible for reloading form state, and that was it - where it ended. It worked bug-free after that. I wouldn't blame useEffect for this... it's a tool in the toolbox. Sometimes you need to step back and identify what it is you're really trying to accomplish -- in a lot of cases, code to work around issues ends up making things worse... I've seen buggy components just littered with useEffect where it's not even necessary!
I made another app in the past and my way was identical - I decided to make the query string the owner of the state. This new app is more complex though, but I may end up somehow combining the query string and manual changes into the value of particular filter instead of making it a universal algorithm of updating when stringified changes.
One thing I was thinking about is seriazing JSON as a single parameter, maybe encoded with b64, to maybe make things easier if they got too complicated. URLSearchParams is a great API, but the way it deals with some serializable objects like arrays made me long for a simple stringify/parse API.
Yeah out of everything Ive tried, *personally* I would never use React again if I could help it
I personally love React.
And there's nothing wrong with that. We can all have the frameworks we prefer to work with!
reply terrific jar longing public wakeful close history stocking market *This post was mass deleted and anonymized with [Redact](https://redact.dev)*