[Fiber] Replace setCurrentDebugFiberInDEV with runWithFiberInDEV #29221
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
CLA Signed
React Core Team
fricken yes please |
|
Comparing: 84239da...abd486f 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
|
sebmarkbage
force-pushed
the
runcurrentfiberincallback
branch
from
60edcb3
to
abd486f
Compare
sebmarkbage
changed the title
gnoff
approved these changes
May 23, 2024
eps1lon
approved these changes
May 24, 2024
Comment on lines
-2497
to
+2537
| // The begin phase finished successfully without suspending. Return to the | ||
| // normal work loop. | ||
|
|
||
| if (__DEV__ || !disableStringRefs) { | ||
| resetCurrentFiber(); | ||
| } | ||
| unitOfWork.memoizedProps = unitOfWork.pendingProps; | ||
| if (next === null) { | ||
| // If this doesn't spawn new work, complete the current work. | ||
| completeUnitOfWork(unitOfWork); | ||
| } else { | ||
| workInProgress = next; | ||
| } | ||
| return next; |
There was a problem hiding this comment.
Drive-by refactor? The git diff doesn't make this very obvious but replaySuspendedUnitOfWork now looks more like a fork of performUnitOfWork. Previous version had diverged quite a bit at a surface level.
| @@ -3753,7 +3806,13 @@ function commitDoubleInvokeEffectsInDEV( | |||
| doubleInvokeEffects, | |||
| ); | |||
| } else { | |||
| legacyCommitDoubleInvokeEffectsInDEV(root.current, hasPassiveEffects); | |||
| // TODO: Is this runWithFiberInDEV needed since the other effect functions do it too? | |||
There was a problem hiding this comment.
Should this be addressed before merging?
There was a problem hiding this comment.
I think we can leave it for now since it's equivalent to before. Needs further investigation if we can actually safely remove it.
github-actions bot
pushed a commit
that referenced
this pull request
May 25, 2024
) Stacked on #29044. To work with `console.createTask(...).run(...)` we need to be able to run a function in the scope of the task. The main concern with this, other than general performance, is that it might add more stack frames on very deep stacks that hit the stack limit. Such as with the commit phase where we recursively go down the tree. These callbacks aren't really necessary in the recursive part but only in the shallow invocation of the commit phase for each tag. So we could refactor the commit phase so that only the shallow part at each level is covered this way. DiffTrain build for commit b078c81.
sebmarkbage
added a commit
that referenced
this pull request
May 26, 2024
Stacked on #29206 and #29221. This disables appending owner stacks to console when `console.createTask` is available in the environment. Instead we rely on native "async" stacks that end up looking like this with source maps and ignore list enabled. <img width="673" alt="Screenshot 2024-05-22 at 4 00 27 PM" src="https://github.com/facebook/react/assets/63648/5313ed53-b298-4386-8f76-8eb85bdfbbc7"> Unfortunately Chrome requires a string name for each async stack and, worse, a suffix of `(async)` is automatically added which is very confusing since it seems like it might be an async component or something which it is not. In this case it's not so bad because it's nice to refer to the host component which otherwise doesn't have a stack frame since it's internal. However, if there were more owners here there would also be a `<Counter> (async)` which ends up being kind of duplicative. If the Chrome DevTools is not open from the start of the app, then `console.createTask` is disabled and so you lose the stack for those errors (or those parents if the devtools is opened later). Unlike our appended ones that are always added. That's unfortunate and likely to be a bit of a DX issue but it's also nice that it saves on perf in DEV mode for those cases. Framework dialogs can still surface the stack since we also track it in user space in parallel. This currently doesn't track Server Components yet. We need a more clever hack for that part in a follow up. I think I probably need to also add something to React DevTools to disable its stacks for this case too. Since it looks for stacks in the console.error and adds a stack otherwise. Since we don't add them anymore from the runtime, the DevTools adds them instead.
github-actions bot
pushed a commit
that referenced
this pull request
May 26, 2024
Stacked on #29206 and #29221. This disables appending owner stacks to console when `console.createTask` is available in the environment. Instead we rely on native "async" stacks that end up looking like this with source maps and ignore list enabled. <img width="673" alt="Screenshot 2024-05-22 at 4 00 27 PM" src="https://github.com/facebook/react/assets/63648/5313ed53-b298-4386-8f76-8eb85bdfbbc7"> Unfortunately Chrome requires a string name for each async stack and, worse, a suffix of `(async)` is automatically added which is very confusing since it seems like it might be an async component or something which it is not. In this case it's not so bad because it's nice to refer to the host component which otherwise doesn't have a stack frame since it's internal. However, if there were more owners here there would also be a `<Counter> (async)` which ends up being kind of duplicative. If the Chrome DevTools is not open from the start of the app, then `console.createTask` is disabled and so you lose the stack for those errors (or those parents if the devtools is opened later). Unlike our appended ones that are always added. That's unfortunate and likely to be a bit of a DX issue but it's also nice that it saves on perf in DEV mode for those cases. Framework dialogs can still surface the stack since we also track it in user space in parallel. This currently doesn't track Server Components yet. We need a more clever hack for that part in a follow up. I think I probably need to also add something to React DevTools to disable its stacks for this case too. Since it looks for stacks in the console.error and adds a stack otherwise. Since we don't add them anymore from the runtime, the DevTools adds them instead. DiffTrain build for commit ea6e059.
github-actions bot
pushed a commit
that referenced
this pull request
May 26, 2024
Stacked on #29206 and #29221. This disables appending owner stacks to console when `console.createTask` is available in the environment. Instead we rely on native "async" stacks that end up looking like this with source maps and ignore list enabled. <img width="673" alt="Screenshot 2024-05-22 at 4 00 27 PM" src="https://github.com/facebook/react/assets/63648/5313ed53-b298-4386-8f76-8eb85bdfbbc7"> Unfortunately Chrome requires a string name for each async stack and, worse, a suffix of `(async)` is automatically added which is very confusing since it seems like it might be an async component or something which it is not. In this case it's not so bad because it's nice to refer to the host component which otherwise doesn't have a stack frame since it's internal. However, if there were more owners here there would also be a `<Counter> (async)` which ends up being kind of duplicative. If the Chrome DevTools is not open from the start of the app, then `console.createTask` is disabled and so you lose the stack for those errors (or those parents if the devtools is opened later). Unlike our appended ones that are always added. That's unfortunate and likely to be a bit of a DX issue but it's also nice that it saves on perf in DEV mode for those cases. Framework dialogs can still surface the stack since we also track it in user space in parallel. This currently doesn't track Server Components yet. We need a more clever hack for that part in a follow up. I think I probably need to also add something to React DevTools to disable its stacks for this case too. Since it looks for stacks in the console.error and adds a stack otherwise. Since we don't add them anymore from the runtime, the DevTools adds them instead. DiffTrain build for [ea6e059](ea6e059)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Stacked on #29044.
To work with
console.createTask(...).run(...)we need to be able to run a function in the scope of the task.The main concern with this, other than general performance, is that it might add more stack frames on very deep stacks that hit the stack limit. Such as with the commit phase where we recursively go down the tree. These callbacks aren't really necessary in the recursive part but only in the shallow invocation of the commit phase for each tag. So we could refactor the commit phase so that only the shallow part at each level is covered this way.