Fix cross-fork discrepancy I missed a few lines when syncing an earlier step. Usually I would find which one and patch it but I'm about to squash and merge so meh.

Detect refreshes by comparing to previous parent Removes the fresh/stale distinction from the context stack and instead detects refreshes by comparing the previous and next parent cache. This is closer to one of the earlier implementation drafts, and...

Detect refreshes by comparing to previous parent Removes the fresh/stale distinction from the context stack and instead detects refreshes by comparing the previous and next parent cache. This is closer to one of the earlier implementation drafts, and...

Detect refreshes by comparing to previous parent Removes the fresh/stale distinction from the context stack and instead detects refreshes by comparing the previous and next parent cache. This is closer to one of the earlier implementation drafts, and...

Detect refreshes by comparing to previous parent Removes the fresh/stale distinction from the context stack and instead detects refreshes by comparing the previous and next parent cache. This is closer to one of the earlier implementation drafts, and...

Remove provider fiber from cache context I originally put the provider fiber on the cache context because I expected the semantics to be that a refresh finds the root of the "freshness" boundary; that is, all the data that refreshed or appeared as par...

Remove provider fiber from cache context I originally put the provider fiber on the cache context because I expected the semantics to be that a refresh finds the root of the "freshness" boundary; that is, all the data that refreshed or appeared as par...

Only mutate `root.pooledCache` in complete/unwind Less indirection when accessing during the render phase and less hard to make a mutation mistake.

Only mutate `root.pooledCache` in complete/unwind Less indirection when accessing during the render phase and less hard to make a mutation mistake.

Only mutate `root.pooledCache` in complete/unwind Less indirection when accessing during the render phase and less hard to make a mutation mistake.

Remove default transition priority for refreshes The flaw here is that if another update in the same event is not wrapped in `startTransition`, then it won't be batched with the refresh. The solution is to wrap both in the same `startTransition`. It's...

Wrap more things in flag

Wrap more things in flag

More tests

More tests

useRefresh -> useCacheRefresh useRefresh is probably too general. We may also add additional APIs related to the cache, and including the word "cache" in all of them signals they are related.

Use only a single pooled cache at a time The cache-per-lane approach makes conceptual sense but it's probably not worth it until we complete the Lanes entanglement refactor. In the current implementation we have to do lots of looping to maintain the p...

Previous retry cache takes precedence over pool When committing a fallback, if there's no cache on the stack, check if there's a cache from the previous render. This is what we would have used for new content during the first pass when we attempted to...

Remove useRefresh from unstable-shared-subset From @sebmarkbage's comment > This should not be included in this file. Which means that the error > the dispatcher throws should never be reachable, but worth keep in > case something is misconfigured or...

Remove useRefresh from unstable-shared-subset From @sebmarkbage's comment > This should not be included in this file. Which means that the error > the dispatcher throws should never be reachable, but worth keep in > case something is misconfigured or...

Code size optimizations - Wraped more things in the feature flag. - Removed CacheComponent cases from commit phase.

Restore retry cache from Suspense/Offscreen fiber When a Suspense or Offscreen boundary resumes rendering, the inner tree should use the same cache that the outer one did during the original render. This is important not just for UI consistency reason...

Restore retry cache from Suspense/Offscreen fiber When a Suspense or Offscreen boundary resumes rendering, the inner tree should use the same cache that the outer one did during the original render. This is important not just for UI consistency reason...

Explicitly check if the parent provider is fresh We can track this cheaply because there's only ever a single fresh provider. We don't need to store the fresh caches on the stack, just one if it exists. Then when we unwind the Fiber stack, we reset it...

Explicitly check if the parent provider is fresh We can track this cheaply because there's only ever a single fresh provider. We don't need to store the fresh caches on the stack, just one if it exists. Then when we unwind the Fiber stack, we reset it...

Explicitly check if the parent provider is fresh We can track this cheaply because there's only ever a single fresh provider. We don't need to store the fresh caches on the stack, just one if it exists. Then when we unwind the Fiber stack, we reset it...

Explicitly check if the parent provider is fresh We can track this cheaply because there's only ever a single fresh provider. We don't need to store the fresh caches on the stack, just one if it exists. Then when we unwind the Fiber stack, we reset it...

Every request in initial render shares same cache I noticed this bug when writing some new tests. The HostRoot fiber is special because it's always mounted. The moment you call `createRoot()`, you have a "current" (albeit empty) tree. So the "initial...

Add fast path for nested mounting Caches Only the top most Cache boundary in a newly mounting tree needs to call `requestFreshCache`. Nested caches can inherit the parent cache by reading from context. This is strictly a performance optimization, sin...

Use an update queue for refreshes Refreshes are easier than initial mounts because we have a mounted fiber that we can attach the cache to. We don't need to rely on clever pooling tricks; they're just normal updates. More importantly, we're not at ri...

Add fast path for nested mounting Caches Only the top most Cache boundary in a newly mounting tree needs to call `requestFreshCache`. Nested caches can inherit the parent cache by reading from context. This is strictly a performance optimization, sin...

Use an update queue for refreshes Refreshes are easier than initial mounts because we have a mounted fiber that we can attach the cache to. We don't need to rely on clever pooling tricks; they're just normal updates. More importantly, we're not at ri...

Use an update queue for refreshes Refreshes are easier than initial mounts because we have a mounted fiber that we can attach the cache to. We don't need to rely on clever pooling tricks; they're just normal updates. More importantly, we're not at ri...

Use an update queue for refreshes Refreshes are easier than initial mounts because we have a mounted fiber that we can attach the cache to. We don't need to rely on clever pooling tricks; they're just normal updates. More importantly, we're not at ri...

Add implicit root-level cache If `getCacheForType` or `useRefresh` cannot find a parent <Cache />, they will access a top-level cache associated with the root. The behavior is effectively the same as if you wrapped the entire tree in a <Cache /> bound...

Add implicit root-level cache If `getCacheForType` or `useRefresh` cannot find a parent <Cache />, they will access a top-level cache associated with the root. The behavior is effectively the same as if you wrapped the entire tree in a <Cache /> bound...

Refreshes should not affect "sibling" boundaries I had thought we decided that refreshing a boundary would also refresh all the content that is currently consistent (i.e. shared the same underlying cache) with it, but I was wrong. Refreshing should on...

Refresh with seeded data Usually, when performing a server mutation, the response includes an updated version of the mutated data. This avoids an extra roundtrip, and because of eventual consistency, it also guarantees that we reload with the freshes...

Cache refreshing Implements useRefresh, a method to invalidate the cache and request new data. It will find the nearest <Cache /> boundary, clear its cache, and schedule an update to re-render with fresh data. We had discussed calling this method `u...

Cache refreshing Implements useRefresh, a method to invalidate the cache and request new data. It will find the nearest <Cache /> boundary, clear its cache, and schedule an update to re-render with fresh data. We had discussed calling this method `u...

Cache refreshing Implements useRefresh, a method to invalidate the cache and request new data. It will find the nearest <Cache /> boundary, clear its cache, and schedule an update to re-render with fresh data. We had discussed calling this method `u...

Cache refreshing Implements useRefresh, a method to invalidate the cache and request new data. It will find the nearest <Cache /> boundary, clear its cache, and schedule an update to re-render with fresh data. We had discussed calling this method `u...