[NEXT-1275] `cookies().get()` fails refreshing Client Cache

Josehower commented 1 year ago

Verify canary release

[X] I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.1.0: Sun Oct  9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103
    Binaries:
      Node: 20.1.0
      npm: 9.6.4
      Yarn: 1.22.19
      pnpm: 8.5.0
    Relevant packages:
      next: 13.4.3-canary.1
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.0.4

Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true), Routing (next/router, next/navigation, next/link)

Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/friendly-field-ssqzdp?file=%2Fapp%2Fpage.tsx%3A10%2C1

To Reproduce

Visit the reproduction example
go to /create-cookie
create a new cookie pressing the create cookie button
check the client cache is refreshed for the current path
visit home page /
check the client cache was not refreshed for other pages depending on the same cookie

Describe the Bug

The client cache is not being fully invalidated for the paths that depend on cookies().get() but only the page that call the cookies.().set() method.

It seems that soft navigation is still enabled after the cookie mutation.

Expected Behavior

updating a cookie should revalidate all the paths that depend on cookies().get()or at very least perform a full cache revalidation similar as arouter.refresh()`

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

_NEXT-1275

Josehower commented 1 year ago

This seems the PR that is most related to this issue https://github.com/vercel/next.js/pull/49582

cc @feedthejim, @shuding

karlhorky commented 1 year ago

I guess one path forward would be revalidatePath('/') (as you mentioned in your code comment in /app/create-cookie/page.tsx), but from the discussion at the issue below, it seems revalidatePath('/') from a Server Action is not yet working:

https://github.com/vercel/next.js/issues/49450

icyJoseph commented 1 year ago

Yeah it doesn't work :( I've tried a bunch of techniques now. In this app, https://next-js-react-ct9wkgsaq-icyjoseph.vercel.app/pokemon/capture

From that route ('/capture'), throw the Pokeball by clicking on it
Regardless of the result, if you now to go collection, you should see the pokemon you interacted with
The problem: You have to refresh the page to see your latest collection

The collection page uses force-dynamic and cookies() yet it stays cached by the client side.

The build printout has:

├ λ /collection                            6.12 kB        98.1 kB

That means it is rendered on demand. Which means that refreshing the page works, but not doing SPA (soft) transitions.

For reference, here's the app in pages dir: https://next-js-react-gbg.vercel.app/pokemon/capture and it works as expected through the power of GSSP.

Btw, this used to work, for a brief time IIRC https://github.com/vercel/next.js/issues/43148

SaveliiLukash commented 1 year ago

Experiencing identical issues and looking/waiting for a solution.

P.S.: Some new fixes on similar issues seem to have been merged to canary, but we'll have to wait for a release to test them in our project. Good to see some progress.

icyJoseph commented 1 year ago

For me, switching to server actions fixed the issue, but it feels like it shouldn't have to be required? This is sort of an, opt-in-to GSSP like behavior, which, yes is blocking, but we can use the loading fallback for that...

vercel / next.js