Fix inspect stack not returning all ancestors

[km1chno]

Changes

Fixes #692

This PR is also necessary for #666

This PR aims to fix the issue with inspector stack that not all ancestors of inspected elements are discovered. It turns out that the hierarchy returned by getInspectorData() is already missing these ancestors, so we have to traverse the component tree ourselves.

The first node is the closestInstance in object returned by getInspectorDataViewAtPoint. To access parent node of a node, we look at node.return. This way we can simply traverse the whole path from first node up to the root. Along the way, we collect all necessary information and create a stack that is returned at the end. We use getInspectorDataForInstance(node) renderer function to obtain inspector data for given fiber node.

This version is a lot more accurate, from my testing it returns all the most used visible components (like <View>, <Text>, <Button>), which is already an improvement compared to the current solution.

Demos

The following are demos how the inspect stack looks like before and after changes from this PR. The component hierarchy of the app consists of several nested components, which have border for visualization.

Before

better_stack_demo_before.mov

After

better_stack_demo_after.mov

How Has This Been Tested:

Open test app, use inspector tool, use right click to show inspector stack.

Tested on Android:

• expo-router
• react-native-74
• react-native-75
• react-native-76

Test on iOS:

• expo-router
• react-native-75
• react-native-76

[vercel]

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

Name	Status	Preview	Comments	Updated (UTC)
radon-ide	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 12, 2024 4:43pm

[kmagiera]

Please see my inline comments. I think it'd be good to test this on RN76 on both Android and iOS, as this is the only project that we have that's currently setup with the new architecture where some of the internals that you're accessing here may work differently.

[km1chno]

I tested this on rn76 (both Android and iOS), it looks like it's working 😄

[kmagiera]

I'm not a fan of using arrow function when without a specific reason. Specifically when defining top level methods.

[kmagiera]

This PR seems to refactor some bits of the old codebase w/o qestioning why they've been implemented in the certain way. Specifically:

1. inline requies
2. try catch around measure
3. Promise.all approach

The use of promises here doesn't seem to make a lot of sense. Before the role of promises was such that we can call async measure in parallel. This PR changes it and makes all measure calls sequential and thus potentially slower.

[km1chno]

@kmagiera As for the Promise.all - I missed the fact that it makes the promise resolution parallel. I put it back because why not, it could be potentially faster this way in some scenarios, as you said.

I also changed the recursive procedure of traversing the tree into an iterative one, also could be a bit faster

[kmagiera]

Thanks for addressing all the comments. This looks good now

[kmagiera]

Appears like there are some issues with this change on React Native 76. Marking this as 'request changes" to avoid it being accidentally merged.