We're not expecting to call this very much. Maybe one or two times in the life time of the app. The code size matters more than the allocations/runtime. You might as well just initialize dependencies to an array here so you don't have to conditionally initialize it later.
This takes a snapshot of this once, but what happens if the client hydrates a sibling before this and start inserting links? Fiber can discover newly inserted links but how does the Fizz runtime discover something that Fiber inserted.
Is there a case where it matters given that we don't guarantee sibling order?
Seems like you could end up inserting something in mixed precedence order though.
It might make sense to just query every time even though it's slower. It might help simplify the code too.
This doesn't make sense. This array is the hotest part so we definitely don't want to do anything that messes with its hidden class. Especially conditionally. I think we need to think about this some more.
Maybe the relationship should be inverted here. You only need this code if you also have $RR but you always need $RC.
How about instead emitting a command to call $RR which then calls $RC. So inverse the relationship.
That way this condition doesn't exist here when you don't need it and you can simplify the code to listen to the result.
When we remove this we might cause some recalc to figure out how this applies to the tree and might need to reapply some selectors.
It's probably better to do this at the same time we do the rest of the reveal. So this should move into flipBoundary.
Relatively to the small code, these closures add quite a bit of code. In this case you can move flipBoundary into the plain completeBoundary so you don't need a closure.
It allocates once per complete call instead of once, but these will be very few calls and not long lived so it's not worth optimizing for. It creates an extra environment which isn't great neither.