feat: Add search params cache

[franky47]

This simplifies the use of parsers on the server, and allows accessing search params in a type-safe manner in deeply nested server components.

Big thanks to @eric-burel for the tip on how to use React's cache this way.

• Test that cache is indeed empty in layouts (NUQS-500) -> It's not, if the whole page is switched to dynamic rendering
• Ignore react from size-limit on server side code

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
next-usequerystate	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 23, 2023 11:08pm

[franky47]

This API does not make much sense, when the useQueryState(s) hooks could be used server-side as a read-only interface for type-safe search params, leveraging the useSearchParams hook, which brings the same behaviour as using the searchParams props at the top of the page, but without the need to parse anything at the top level.

Edit: it still makes sense. useSearchParams only works in Client Components, so if a deeply nested RSC needs access to search params, there's no current way to do that in stock Next.js.

[Talent30]

This API does not make much sense, when the useQueryState(s) hooks could be used server-side as a read-only interface for type-safe search params, leveraging the useSearchParams hook, which brings the same behaviour as using the searchParams props at the top of the page, but without the need to parse anything at the top level.

Edit: it still makes sense. useSearchParams only works in Client Components, so if a deeply nested RSC needs access to search params, there's no current way to do that in stock Next.js.

Yes, It definitely has value in terms of preventing prop drilling in server components. Good stuff! I have learned something new from this PR.

[franky47]

CI is failing with the weirdest bug..

Changing the cache test case by adding two children pages /app/cache/a and /app/cache/b, and have them <Link> to each other, breaks the pages router non-shallow updates, but only when there's a basePath present, and only in Next.js 13.5 and after 🙃

Edit: links are not at fault, it's just the mere presence of the second child page. Even if both of them contains a simple static Hello world.

Starting to question my sanity here.

[Talent30]

CI is failing with the weirdest bug..

Changing the cache test case by adding two children pages /app/cache/a and /app/cache/b, and have them <Link> to each other, breaks the pages router non-shallow updates, but only when there's a basePath present, and only in Next.js 13.5 and after 🙃

Edit: no, it's just the mere presence of the second child page. Even if both of them contains a simple static Hello world.

Starting to question my sanity here.

How about when you are using router.push to go to page b?

[Talent30]

@Talent30 that's the thing, I'm not even navigating to those pages!! Their mere presence in the build causes the pages router (a completely different subsection of the app) to fail in weird ways. I feel like this is a Next.js bug which has been dormant until then, and somehow this very specific combination of setup causes it.

The effect is that updates in the pages router don't apply the basePath correctly, and end up shallow-navigating to a 404.

It's so weird I'm considering just dropping those test pages just to restore CI and move on with the cache feature. Maybe our paths will cross again, and I will be ready ⚔️ . Until then, 🤷‍♂️

Ah sorry I missed the part. Yea I don't think we should worry about the page router since it is not designed for RSC(cache is part of the RSC proposal) and I don't think Next.js team would fix it even you report it.

[franky47]

Actually it made me realise the e2e test did not properly catch the underlying issue: basePath support is broken on the pages router at the moment, and the issue above only uncovered the problem in another way. But running the e2e test bench shows the basePath not being properly handled.

I'll rework those tests in a separate PR.

As for the cache, I think it's good to go, there should be an error thrown at build time if it's being used in a Layout (or any component under a layout), to highlight the fact that even though Layouts may receive searchParams via the cache feature on page reload, it goes stale instantly on client-side navigation, so it should not be trusted.

[github-actions]

🎉 This PR is included in version 1.13.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀