[DevTools] Unify by using ReactFunctionLocation type instead of Source #33955
Conversation
This file contains hidden or 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
This collects locations from parent Component Stacks. These are conceptually ReactFunctionLocations (top of the function) as opposed to ReactCallSite that are usually part of stacks like owner stacks.
Ideally we'd parse the function name out of the sourceContent of the original position.
github-actions
bot
added
the
React Core Team
sebmarkbage
commented
Jul 21, 2025
| export type ViewElementSource = ( | ||
| source: Source, | ||
| symbolicatedSource: Source | null, | ||
| source: ReactFunctionLocation, |
Collaborator
Author
There was a problem hiding this comment.
I don't know if there are any consumers of this in fusebox that needs to be updated. If so, it's probably just the same as the standalone.
Contributor
There was a problem hiding this comment.
This package is private and the only user is React Native DevTools.
This should be fine, I will update this next time I upgrade React DevTools for React Native DevTools.
sebmarkbage
commented
Jul 21, 2025
| source: source && source.sourceURL ? source : null, | ||
| // Previous backend implementations (<= 6.1.5) have a different interface for Source. | ||
| // This gates the source features for only compatible backends: >= 6.1.6 | ||
| source: Array.isArray(source) ? source : null, |
Collaborator
Author
There was a problem hiding this comment.
Not sure where this is needed but following the same pattern.
Contributor
There was a problem hiding this comment.
This is needed in case there is a version mismatch between Backend and Frontend. Not applicable to browser extensions, only to standalone / inline / fusebox versions, where only Frontend is shipped, and Backend is used from react-devtools-core npm package.
For example, if Frontend would have your change, but Backend didn't, there would be type mismatch and Frontend would potentially treat plain object as an array.
hoxyq
approved these changes
Jul 22, 2025
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Jul 26, 2025
facebook#33955) In RSC and other stacks now we use a lot of `ReactFunctionLocation` type to represent the location of a function. I.e. the location of the beginning of the function (the enclosing line/col) that is represented by the "Source" of the function. This is also what the parent Component Stacks represents. As opposed to `ReactCallSite` which is what normal stack traces and owner stacks represent. I.e. the line/column number of the callsite into the next function. We can start sharing more code by using the `ReactFunctionLocation` type to represent the component source location and it also helps clarify which ones are function locations and which ones are callsites as we start adding more stack traces (e.g. for async debug info and owner stack traces). DiffTrain build for [7513996](facebook@7513996)
github-actions bot
pushed a commit
to code/lib-react
that referenced
this pull request
Jul 26, 2025
facebook#33955) In RSC and other stacks now we use a lot of `ReactFunctionLocation` type to represent the location of a function. I.e. the location of the beginning of the function (the enclosing line/col) that is represented by the "Source" of the function. This is also what the parent Component Stacks represents. As opposed to `ReactCallSite` which is what normal stack traces and owner stacks represent. I.e. the line/column number of the callsite into the next function. We can start sharing more code by using the `ReactFunctionLocation` type to represent the component source location and it also helps clarify which ones are function locations and which ones are callsites as we start adding more stack traces (e.g. for async debug info and owner stack traces). DiffTrain build for [7513996](facebook@7513996)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
In RSC and other stacks now we use a lot of
ReactFunctionLocationtype to represent the location of a function. I.e. the location of the beginning of the function (the enclosing line/col) that is represented by the "Source" of the function. This is also what the parent Component Stacks represents.As opposed to
ReactCallSitewhich is what normal stack traces and owner stacks represent. I.e. the line/column number of the callsite into the next function.We can start sharing more code by using the
ReactFunctionLocationtype to represent the component source location and it also helps clarify which ones are function locations and which ones are callsites as we start adding more stack traces (e.g. for async debug info and owner stack traces).