[DevTools] Include some Filtered Fiber Instances

[sebmarkbage]

When we filter Fiber Instances where have no way to recover our position in the Fiber tree. The extreme form of this is if you filter out all the Fibers and keep only Server Components.

This affects operations that are performed against fibers such as collecting Host Instances for highlighting or emulating suspending/erroring.

Conceptually we don't need to add this into the DevToolsInstance tree because we only need to get to some Fibers from a VirtualInstance. A Virtual Instance can contain more than one conceptual child Fiber. It would be easier if we didn't include them in the tree on one hand because we could just traverse the tree and assume it looks like the one on the frontend. But it's also tricky to manage the lifetime. So I went with a special FilteredFiberInstance node in the tree.

Currently I only add it if its parent would've been a VirtualInstance since we don't need it in any other cases. If the parent was another FiberInstance it already has a Fiber.

There might be need for always tracking all Instances whether they're filtered or not or just moving filtering to the frontend but for now I'm keeping the general architecture as is.

[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	Sep 3, 2024 10:38pm

[sebmarkbage]

I'm lying about the type here because we need to ensure this is a number to preserve the hidden class at runtime, but from a type perspective, we should not attempt to read the .id field from a filtered instance since from the front end's perspective, it never exists.

[hoxyq]

Is this statement true only because of the current implementation (lines 2771-2772)?

Like if I've just filtered out some client component based on its name, then its not Virtual Instance only, right?

[sebmarkbage]

Yes, it's only true based on the current implementation and if that changes then this, and any other place sending instruction to the frontend, would have to turn into a loop backtracking until it hit something unfiltered.

It's basically because all virtual instances themselves come from backtracking from a Fiber. It's impossible for a virtual instance to exist without bottoming out into a Fiber (for example a Server Component that renders null doesn't actually show up in the tree today but it could be modeled by an empty Fragment Fiber). They need some Fiber to find their place in the tree if we traverse filtered things like the Suspense/Error case or finding child Host Instances.

There's no need to do that for fiber instances since they already have a Fiber that we can walk and so therefore this is already a Virtual Instance.

Technically this holds true as long it's not two Filtered Fibers in a row. Once you could have two filtered fibers nested it would need to turn into a loop.