React router search parameters manipulation explained with examples

My struggles with URL parameters and the painful lessons I learned that hopefully make your life easier

In case you don’t know what URL search parameter is, it looks like this

Basically it’s everything after ? and before # in a URL.

We initially started using search params not to query the backend but to retain the search state in the frontend.

Imagine this scenario, you are on a search page (/search) and type in a keyword, a list of users shows up and you visit one of the user’s profile page(/user/user-a) and coming back to the search result, unfortunately the original search is gone and it can be quite frustrating if you have to type in the search or navigate to the 4th page again. That’s the problem we had on NEXL, because the search keyword and filters are stored in a state in <Search /> component under route /search, when you leave the route and come back, <Search /> gets unmounted and mounted so the state gets re-initiated.

So I created a context to store all the search states.

And push to URL params when there’s an update using useEffect hook.

A small issue I had here is we have a search filter which is an enum but it’s a string when parsed from URL parameters, so I have to map the string to enum when updating state on URL update.

In this case, we have to assign string values to our enum, like this

So we can find the exact enum by its string value like this

In real code, it looks like

Another minor issue is now whenever you go to the search page, the url always look like this even though all the params are either undefined or default value so we don’t actually need any of them.

So I did a little clean up in history.push function to only add the params that got updated

With this, when you first land on the search page and haven’t done any action, the url is simply /search.

And say you updated search keyword, it looks nice and clean

And you broswe the second page, it’s still pretty straightforward without throwing a long nonsense string at your face.

Not long after we implemented the solution above, we got a bug. When you land on search page and click on “back” on your browser, it doesn’t go back to the previous page until you click the second time, or the 6th time depending on how many search/filters you have done on the page. This is super annoying to our users or even to us working on the platform.

After some online search I found history.push() is to blame. So I updated the effect to use history.replace() so every search update doesn’t get pushed to the history stack.

One drawback of this is now if you navigate to the second page of the search result and click on go back, it goes back to the previous page before landing on the search page instead of the first page of the result. But it’s good enough for now and we’ll fix it when someone complains.

The trick to fix this issue is to add the previous params in the new search object before stringifying it. And the previous params should be added before the search state params so the new search state value will overwrite the previous ones.

Thanks for reading and I hope this helps your project. I still find the solutions and fixes here are quite clumsy, let me know if you have any suggestions to any points. I’d love to hear =)

Related posts:

India is topping the charts in so many world ratings but currently one rating which drew my attention was the world depression list. India is topping the chart by margin and this is one thing we…

Fertilizer has had a major impact in avoiding the oft-trotted out — and Thanos-like — trope that population will outstrip food supplies, a dire prediction that has not come to be. According to Our…

Accurate data is critical for organizations to better understand their customers. Tally is a repository for all corporate transactions and consumer information. Transactions are documented for legal…