Janka UrygaandGitHub 701b11c3c4 [after] after is not dynamic anymore (#71231) ...

# Changes

### 1. `unstable_after()` is no longer dynamic

`after()` can now run at build time and in ISR/revalidations.

the principle is "if it ran, then the callback runs too". i.e. if we
encountered an `after()` call during some render task (build / request /
revalidation), then the callback should run at the end of that task.

note that errors thrown inside `after` during a prerender will fail the
build. this is, amongst other things, intended to support the next
section

### 2. calling dynamic APIs inside `unstable_after()` is banned

before:
```ts
after(() => {
  const cookieStore = await cookies();
  doStuff(cookieStore)
})
```

after:
```ts
const cookieStore = await cookies();
after(() => {
  doStuff(cookieStore)
})
```

tracking dynamic things inside `after` is difficult (can't throw at the
callsite, because we're executing after the callsite is finished, so it
doesn't mesh well with `dynamicIO`). it's simpler if we make the user
hoist the dynamic call outside of `after()`, because then it slots right
into the existing mechanisms/docs/metal models we have for this.

# Notes

one notable limitation is that `tags` and `revalidate` written inside
`after` have no effect. this means that if we do
```ts
after(async () => {
  await fetch('...', { next: { tags: ['my-cool-tag']} })
})
```
and try to call `revalidateTag('my-cool-tag')`, nothing will happen,
because the route is not associated with the tag. same applies to
`revalidate`.

i believe this is acceptable for now, because we expect `after` to be
mostly used to perform side effects, and thus not do a lot of
{cached,tagged,revalidatable} data-fetching. it will be addressed in a
follow up.

2024-10-14 12:56:56 +00:00

..

log.js

[after] after is not dynamic anymore (#71231)

2024-10-14 12:56:56 +00:00