RFC: simplify `Text` and `TextInput` related queries

Describe the Feature

Currently when looking for Text and TextInput instances we compare to tree elements type with components exported from React Native. This is problematic because exported components are composite ones, while we try to work primarily with host components. It leads to methods like: isHostElementForType which try to navigate from host to composite parent of certain type to verify whether this is a host Text or TextInput.

There is an easy alternative, which is to compare ReactTestInstance.type field with string values of "Text" and "TextInput" which are currently used by these host components. The issue here is that the host types are not “standardised” and have used slightly different names in the past, e.g. RCTText instead of Text, so these could potentially change again.

In order to get the best of both worlds: robust code and being future proof I propose migrating to type matching against configurable host component names.

Possible Implementations

1. hostComponentNames config option

Extend config with hostComponentNames field. User will be able to pass custom values in case they use older version of RN (which we probably do not support) or if RN changes the naming in the future without need for release:

configure({
  hostComponentNames: {
    text: "Text",
    textInput: "TextInput",
  }
})

The default values are matching the current RN naming scheme.

2. Update queries and event handling

Modify queries and fireEvent code that looks for Text and TextInput to use hostComponentNames:

element.type === getConfig().hostComponentNames.text;
element.type === getConfig().hostComponentNames.textInput;

(Optional) 3. add hostComponentNames: "autodetect" option

Add autodetect option to configure that would run a simple auto-detection code:

configure({
  hostComponentNames: "autodetect";
})

Simple auto-detection code:

function autodetectHostComponentNames(): HostComponentNames {
  const { getByTestId } = render(
    <View>
      <Text testID="text">Hello</Text>
      <TextInput tystID="textInput" />
    </View>
  );

  return {
    text: getByTestId("text").props.testID,
    textInput: getByTestId("textInput").props.testID,
  }

This would allow users to quickly resolve any potential issues regarding host component name changes.

(Optional) 4. Suggest proper config setting for hostComponentNames option

Suggest proper values for hostComponentNames option when using auto-detect mode:

You are using host component name auto-detection mode. This might cause a slightly longer test execution time.
To make you tests run faster use the following code in your test setup file:

configure({
  hostComponentNames: {
    text: "New_Text",
    textInput: "New_TextInput",
  }
})

Where the actual names would be filled in by RNTL.

Pros and cons analysis

Benefits:

• simpler logic for analysing component tree (no more composite parent lookups)
• flexible in case of host component name change

Cons:

• not 100% automatic

Related Issues

• #1139 - adding of isHostElementForType to fix within + getByText handling

[pierrezimmermannbam]

This is a very interesting approach and I like the idea of suggesting proper config for users.

I’m thinking of an alternative approach where on failed query we’d match the component name in the config against the actual component name of RN (by running autoDetectHostComponentNames) and we may then suggest the appropriate component name to use in configure. This way failing tests would explain how to fix them so it’s impossible to miss.

Also I think it would be possible that new releases of RNT directly support newer RN versions by changing the default config to match the component names of the RN version used by the user so that no additional configuration would be required

[mdjastrzebski]

Running autoDetectHostComponentNames sounds like an interesting idea. That removes the need for feature 3.

We should take care though to suggest changing the config only if the found component name is different than the current config, as we want to avoid showing suggestion that would not fix anything.