I'm iterating on our search overlay which is currently using shallow routing to set the query string when the search input and facets change. We're using shallow routing since it's an overlay, to avoid having to fetch all the paginated search results as well as the fetch requests made by the page below the search overlay. So shallow routing to update the query string without triggering a page load + React Query useInfiniteQuery with first page of data initially loaded from the server, and subsequent pages loaded client side.

However... it's rather complicated with all this client side state, providers etc... so I was thinking..

It's rather simple to update the update the query string when the search input field and faceted checkboxes change, so would correct use of server components be viable here to replace all the client state so the url becomes the single source of truth?

The solution I came up with was to simply use un-shallow updates for the querystring every time the search input and facets change - this causes a lot of excess requests at first, but it makes to code really simple and react query becomes obsolete, since I can just send all query string params to my getProducts(querystringparams) endpoint.

The problem is now the excess requests - both from the search overlay itself as well as from the page below - every time the query string changes. So I wrapped it in unstable_cache and it mitigated this problem... I'm building a rather large ecommerce site, which will get a lot of traffic, so I wanted to hear you guys if this way of relying on the cache to do its magic is indeed a valid use of server components?

In a way you load a lot more data up front, but once the cache is warmed up, I suspect the difference of loading all products data every time a searchparam changes (search query + facets + sorting + pagination) will be less and less as more combinations of filters and searches gets cached.