Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[DevTools] Add DevToolsInstance to Store Stateful Information (#30517)
Stacked on #30494 and #30491. This is setting us up to be able to track Server Components. This is now split into a FiberInstance (Client Component) and a VirtualInstance (Server Component). We're not actually creating any VirtualInstances yet though this is just the data structures. Server Components and potentially other compiled away or runtime optimized away (e.g. calling through a function without creating an intermediate Fiber) don't have a stateful instance. They just represent the latest data. It's kind of like a React Element. However, in the DevTools UI we need them to be stateful partly just so that you can select and refer to them separately. E.g. the same Server Component output rendered into different slots on the client should still have two different representations in the DevTools. Also if the same child Fibers update in place because the Server Component refreshed we shouldn't lose the selection if you've selected a Server Component. I'll implement this by creating Virtual Instances that only exist for the purpose of the DevTools UI and so it'll be implemented in the DevTools. We could just make a Map from `id` to `Fiber | ReactComponentInfo` but that requires a branching without a consistent hidden class. We also need some more states on there. We also have some other Maps that tracks extra states like that of component stacks, errors and warnings. Constantly resizing and adding/removing from a Map isn't exactly fast. It's faster to have a single Map with an object in it than one Map per object. However, having extra fields that are usually just `null` can instead mean more memory gets used. Since only a very small fraction of instances will have errors/warnings or having initialized its component stack, it made sense to store that in a separate Map that is usually just empty. However, with the addition of particularly the `parent` field and the ability to do a fast hidden-class safe branching on the `kind` field I think it's probably worth actually allocating an extra first class object per Instance to store DevTools state into. That's why I converted from just storing `Fiber` -> `id` to storing `Fiber` -> `DevToolsInstance` which then keeps the warnings/errors/componentStack as extra fields that are usually `null`. That is a lot of objects though since it's one per Fiber pair basically.
- Loading branch information