[DevTools] Support Server Components in Tree

[sebmarkbage]

This adds VirtualInstances to the tree. Each Fiber has a list of its parent Server Components in _debugInfo. The algorithm is that when we enter a set of fibers, we actually traverse level 0 of all the _debugInfo in each fiber. Then level 1 of each _debugInfo and so on. It would be simpler if _debugInfo only contained Server Component since then we could just look at the index in the array but it actually contains other data as well which leads to multiple passes but we don't expect it to have a lot of levels before hitting a reified fiber. Finally when we hit the end a traverse the fiber itself.

This lets us match consecutive ReactComponentInfo that are all the same at the same level. This creates a single VirtualInstance for each sequence. This lets the same Server Component instance that's a parent to multiple children appear as a single Instance instead of one per Fiber.

Since a Server Component's result can be rendered in more than one place there's not a 1:1 mapping though. If it is in different parents or if the sequence is interrupted, then it gets split into two different instances with the same ReactComponentInfo data.

The real interesting case is what happens during updates because this algorithm means that a Fiber can become reparented during an update to end up in a different VirtualInstance. The ideal would maybe be that the frontend could deal with this reparenting but instead I basically just unmount the previous instance (and its children) and mount a new instance which leads to some interesting scenarios. This is inline with the strategy I was intending to pursue anyway where instances are reconciled against the previous children of the same parent instead of the fiberToFiberInstance map - which would let us get rid of that map. In that case the model is resilient to Fiber being in more than one place at a time.

However this unmount/remount does mean that we can lose selection when this happens. We could maybe do something like using the tracked path like I did for component filters. Ideally it's a weird edge case though because you'd typically not have it. The main case that it happens now is for reorders of list of server components. In that case basically all the children move between server components while the server components themselves stay in place. We should really include the key in server components so that we can reconcile them using the key to handle reorders which would solve the common case anyway.

I convert the name to the Env(Name) pattern which allows the Environment Name to be used as a badge.

(Screenshot is with #30667. I haven't tried it with the alternative fix.)

[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	Aug 14, 2024 3:21pm

[hoxyq]

What is the possible case when fiberToFiberInstanceMap.get(fiber) !== fiberInstance? Reparenting case?

[sebmarkbage]

Reparenting can happen in different sequences.

E.g. if it moves to later then it can get removed first and then added. In that case we end up with the situation where we have an alternate but is actually a mount.

If it moves to earlier then it gets added first and then later removed. In this case we steal/claim the fiberToFiberInstanceMap slot for this Fiber using the newly mounted instance. Later the previous instance gets removed which shouldn't delete the newly mounted instance from this map.

[hoxyq]

Is it possible that alternate was not registered in fiberToFiberInstanceMap before?

[sebmarkbage]

In the case where the initial set is flushed such as when we connect to an existing tree, we only register the mounted fibers. Not the alternates so it's possible for alternates to not be registered at any given point.

In the case where we reparent - moving to an earlier point - we insert a new FiberInstance before removing the old one.

In that case we use this pass to override the previous fiber->instance mapping with our new instance.

I'm not sure if we actually need to set the alternate to the new fiber in this case though. We could maybe actually just delete it.