Add ReactDebugInstanceMap #6389
Merged
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.
This PR is the first in a series of pull requests split from the new
ReactPerfimplementation in #6046.Here, we introduce a new module called
ReactDebugInstanceMap. It will be used in__DEV__and, when the__PROFILE__gate is added, in the__PROFILE__builds. It will not be used in the production builds.This module acts as a mapping between “debug IDs” (a new concept) and the internal instances. Not to be confused with the existing
ReactInstanceMapthat maps internal instances to public instances.What are the “debug IDs” and why do we need them? Both the new
ReactPerfand other consumers of the devtool API, such as React DevTools, need access to some data from the internal instances, such as the instance type display name, current props and children, and so on. Right now we let such tools access internal instances directly but this hurts our ability to refactor their implementations and burdens React DevTools with undesired implementation details such as having to support React ART in a special way.1The purpose of adding
ReactDebugInstanceMapis to only expose “debug IDs” instead of the internal instances to any devtools. In a future PR, whenever there is an event such as mounting, updating, or unmounting a component, we will emit an event inReactDebugToolwith the debug ID of the instance. We will also add an introspection API that lets any devtool pass an ID and get the information about the current children, props, state, display name, and so on, without exposing the internal instances.ReactDebugInstanceMaphas a concept of “registering” an instance. We plan to add the hooks that register an instance as soon as it is created, and unregister it during unmounting. It will only be possible to read information about the instance while it is still registered. If we add support for reparenting, we should be able to move the (un)registration code to different places in the component lifecycle without changing this code. The currently registered instances are held in theregisteredInstancesByIDsdictionary.There is also a reverse lookup dictionary called
allInstancesToIDswhich maps instances back to their IDs. It is implemented as aWeakMapso the keys are stable and we’re not holding onto the unregistered instances. If we’re not happy withWeakMap, one possible alternative would be to add a new field called_debugIDto all the internal instances, but we don’t want to do this in production. UsingWeakMapseems like a simpler solution here (and stable IDs are a nice bonus). This, however, means that the__DEV__(and the future__PROFILE__) builds will only work in browsers that support our usage ofWeakMap.