Architecture: render tree presentation

[mdjastrzebski]

This is a rather long-term architectural discussion, and changing any of this stuff would probably break a lot of user code.

In the current codebase we rely heavily on ReactTestInstance as our representation of component tree node. While it seems it has been created to facilitate testing by providing find/findAll methods, there are certain limitations to it:

• it contains both host (View, Text, etc) and composite components (class or function, framework or user-defined) which forces us to filter composite components in test and also prevents easy user access to traversing only-host components
• similar composite component filtering code needs to be placed in random places like fireEvent
• it lacks access to low level text nodes (see: Error: Unable to find an element with text: "My text", while that text exist. #937, testing-library can't find i18next Trans texts #964, Fix translations text not being found by getByText #967)

React Test Renderer provides two alternatives representations of component tree, namely ReactTestRendererJSON returned by toJSON() method and related ReactTestRendererTree returned by toTree() method. These methods are only exposed on ReactTestRenderer create method output, so there is no easy transition between ReactTestInstance and ReactTestRendererJSON/Tree.

ReactTestRendererJSON/Tree have certain benefits:

• ReactTestRendererJSON seems to expose only host components
• both seem to expose leaf text nodes
• they expose props, children and rendered fields

While they also have their drawbacks:

• there is no built in findAll method - but that should be relatively easy to reimplement
• they lack parent field for upward tree navigation

If we were to open this can of architectural worms and revisit our existing architectural assumptions we have broadly three options:

1. Stick with current ReactTestInstance based code
2. Migrate towards ReactTestRendererJSON/Tree
3. Build our own tree node representation and populate it based on any of the above (probably ReactTestRendererJSON would be the best candidate).

Options 3 is the most complex to build but could potentially allow us to encapsulate a lot of RN runtime env simulation code inside, building a sort of mini JS Dom environment. Probably some POC would be necessary to research benefits and limitations of such solution.

@thymikee @AugustinLF @pierrezimmermannbam wdyt?

[AugustinLF]

I agree that we probably hit the limitations of RestTestInstance. A benefit of RTL is the mentality of "we care about the DOM, not react", and I feel that currently our implementation depends way too much on specific internals of react-native. We should indeed only have the host components.

Another thing to keep in mind is that we don't handle native components (List, inputs, etc.). Even though I'm not sure that'd be a problem with any of the discussed implementations, we need to make sure that at least the implementation is the same as before (for instance, being able to trigger onMomentumDrag).

Regarding the difference between the 2nd and 3rd solution, I guess the main question is what will we miss with it? What is the drawback?