Is there a way to update a search param without triggering navigation hooks like beforeLoad?
I tried to use
window.history.replaceState({}, "", newUrl); but even that causes the beforeLoad of routes to run.25 Replies
correct-apricot•5mo ago
no
why would you need that?
sunny-greenOP•5mo ago
For that: https://discord.com/channels/719702312431386674/1357819520173215957/1359225936406511847
When the user types into a an inputfield and i want to use a search param for the state it becomes slow/sluggish even to the point where it is not acceptable performance.
Debouncing as you suggested might be a workaround but it would be great to have a hook that allows updating a search param without running anything else (basically a
window.history.replaceState that does not cause TSR to run its matching logic) 🙂correct-apricot•5mo ago
what exactly is causing the slowdown here?
re-rendering?
sunny-greenOP•5mo ago
really hard to nail it down to a single thing. When i test it with just a single route with no beforeLoad(ers) and a more basic UI it works nearly as fast as a html input field that does not call navigate.
From my testing it is a combination of beforeLoad and a couple of re-renders that happen. The UI is pretty complex too unfortunately. We might be able to optimize more and get rid of one re-render per keystroke but from the lagging we see now that most likely won't make a big enough difference
correct-apricot•5mo ago
are you using fine grained selectors for search?
sunny-greenOP•5mo ago
yes! I tried them both with useSearch and useLocation as I saw Sean suggest that in the nuqs PR here: https://github.com/47ng/nuqs/pull/953#discussion_r2025395513
sunny-greenOP•5mo ago
I tried to record the lagging. You can even hear my keystrokes 😆
I also tried to create a sample in stackblitz but it is hard as there is no bug. I would just have to blow up the example to become complex enough for the lagging to become an issue i think.
sunny-greenOP•5mo ago
a single keystroke right now causes 2 re-renders of the Mui TextField I am using for my searchbox. i think that is fine 🙂
correct-apricot•5mo ago
no idea if nuqs adds rerenders here
are you using that on top?
sunny-greenOP•5mo ago
i no longer use nuqs 🙂 i did previously with RR6 and we had no issues
correct-apricot•5mo ago
ah ok
so still not clear what is the issue here
rerendering or beforeLoad?
sunny-greenOP•5mo ago
For reading and updating I use this hook that I wrote to replace nuqs with TSR 🙂
https://discord.com/channels/719702312431386674/1357819520173215957/1357822919593431112
i will try to strap away all beforeLoads and add some mocks for all the data required that far down the route tree. We use beforeLoad to ensure tanstack query has all necessary data 🙂
Right now i can't point to a single thing that definitely is the slow-down.
sunny-greenOP•5mo ago
i got it down to a single beforeLoad and a single re-render on each keystroke. the beforeLoad takes between 10-20ms only. Next I will try to strip away some UI elements form that page now
sunny-greenOP•5mo ago
Is it possible that it is the amount of routes we have in (file-based) routing? I boiled it down to a minimal UI on the actual page with no performane increase. Then i stripped away more of the _layout routes UI that was being added (and any hooks that ran there). No changes still. Now i just deleted nearly all other routes and it is significantly faster.
usually we have around 70 routes.
correct-apricot•5mo ago
is this in prod or dev
70 routes nested ? or 70 routes in total
if thats nested, woah
😄
if in total, we might have a perf issue in route matching
sunny-greenOP•5mo ago
dev but we noticed the issue first on our QA instance which uses a prod deployment.
luckly just 70 routes 😄 not 70 nested onces 🙂
correct-apricot•5mo ago
can you measure in prod as well please
just to make sure
sunny-greenOP•5mo ago
what exactly should i meassure? just if it is slow or something specific we are looking for?
correct-apricot•5mo ago
the same thing here
sunny-greenOP•5mo ago
we use the useMatches hook in a variety of places too so that might add to it as each navigate causes that hook to run too
correct-apricot•5mo ago
just with a prod build
sunny-greenOP•5mo ago
will do tomorrow 👍 i am still trying to confirm what causes it locally first.
Ok it is much much less in production. It does not feel like a plain html input field but no users would smash their keyboards like i am right now. I added a couple more fine-grained selectors in other places and replaced one useMatches() with a useRouter().state.matches where i did not reactive values to reduce re-renders 🙂
correct-apricot•5mo ago
I still think we can optimize so that the number of routes matters less
can you please create a GitHub issue for that
sunny-greenOP•5mo ago
yes. i am trying to reproduce it in a plain TSR app for the ticket. I have 200 routes now and the problem is not so clearly visible as in our actual app though. Sooo I still think it is a TSR performance issue but it only shows if you have enough routes, data in the context (we discussed this in the past that structural sharing is a big performance hit for bigger objects in the context) and usage of hooks like useMatches without a fine-grained selector.
sunny-greenOP•5mo ago
I created an issue to keep track of it: https://github.com/TanStack/router/issues/3965
GitHub
Performance of navigation drops with increasing complexity · Issue...
Which project does this relate to? Router Describe the bug When trying to find a way to update a search param without calling navigate, performance of navigate decreases with increasing complexity ...