[DevTools] Add DevToolsInstance to Store Stateful Information

[sebmarkbage]

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.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 30, 2024 7:07pm

[sebmarkbage]

This is needed to get back from a VirtualInstance back into the Fiber tree.

We could store both children - e.g. a linked list like child and next like Fibers do. However, given either parent or children we can reverse engineer our location by traversing it until we hit a Fiber and then reverse engineer either parent or children.

The cheapest to store is the parent.

However, this will make findHostInstancesForElementID slower to implement when the ElementID is a VirtualInstance because we'll need to traverse siblings and filter out any siblings not relevant to this Virtual Instance. That operation is just used for one ElementID at a time though so it's not so bad. We could also alternatively implement this on the front-end. E.g. find all HostComponents that the front-end thinks are the children a Component and then pass those ids to the backend. Since the front-end already has this tree.

[sebmarkbage]

We could perhaps merge errors and warnings into a single nested object to save bit of memory in the common case.

[sebmarkbage]

This is only used by getSourceForFiber and it really doesn't need the full parent stack to do that so it's a bit overkill. The parent stacks appended to consoles aren't cached and they're really not used once we ship enableOwnerStacks anyway.

We could probably drop this field.

[hoxyq]

Yup, we can drop this together with getSourceForFiber once we enable enableOwnerStacks by default

[sebmarkbage]

One potential alternative to storing a wrapper object while solving the hidden class issue would be to encode the kind in the id. E.g. odds are virtual, evens are fibers. However, that would still mean two maps that has everything in it since we'd need to store the virtual parent along with the Fiber or ReactComponentInfo.

[eps1lon]

They just represent the latest data. It's kind of like

Second sentence is incomplete.