-
Notifications
You must be signed in to change notification settings - Fork 47.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove automatic fetch cache
instrumentation
#28896
Conversation
This removes the automatic patching of the global `fetch` function in Server Components environments to dedupe requests using `React.cache`, a behavior that some RSC framework maintainers have objected to. We may revisit this decision in the future, but for now it's not worth the controversy. Frameworks that have already shipped this behavior, like Next.js, can reimplement it in userspace. I considered keeping the implementation in the codebase and disabling it by setting `enableFetchInstrumentation` to `false` everywhere, but since that also disables the tests, it doesn't seem worth it because without test coverage the behavior is likely to drift regardless. We can just revert this PR later if desired.
Comparing: d4e78c4...5ff57cc Critical size changesIncludes critical production bundles, as well as any change greater than 2%: Significant size changesIncludes any change greater than 0.2%: Expand to show
|
This removes the automatic patching of the global `fetch` function in Server Components environments to dedupe requests using `React.cache`, a behavior that some RSC framework maintainers have objected to. We may revisit this decision in the future, but for now it's not worth the controversy. Frameworks that have already shipped this behavior, like Next.js, can reimplement it in userspace. I considered keeping the implementation in the codebase and disabling it by setting `enableFetchInstrumentation` to `false` everywhere, but since that also disables the tests, it doesn't seem worth it because without test coverage the behavior is likely to drift regardless. We can just revert this PR later if desired. DiffTrain build for [a94838d](a94838d)
This comment was marked as abuse.
This comment was marked as abuse.
Hello:) I think a better idea was to be that there is an option for caching. For example by default there is no caching but if the user passed in the parameter true for caching then to cache. |
Hi @acdlite |
One alternative for the future (that has most likely been considered) is for the Con: It would be slightly more verbose and potentially shadow the global when imported. Pro: App developers can opt into this behavior more explicitly and per file and it won't mess with invariants of the runtime dependent on by libraries. |
This should not be needed, now that React is not patching `fetch` anymore (see facebook/react#28896). It was previously done to fix a memory leak (see #43859). This fixes a race condition where the original `fetch` was stored before experimental test mode patched `fetch`, thus undoing the test mode `fetch` patch when resetting `fetch` during HMR.
This removes the automatic patching of the global
fetch
function in Server Components environments to dedupe requests usingReact.cache
, a behavior that some RSC framework maintainers have objected to.We may revisit this decision in the future, but for now it's not worth the controversy.
Frameworks that have already shipped this behavior, like Next.js, can reimplement it in userspace.
I considered keeping the implementation in the codebase and disabling it by setting
enableFetchInstrumentation
tofalse
everywhere, but since that also disables the tests, it doesn't seem worth it because without test coverage the behavior is likely to drift regardless. We can just revert this PR later if desired.