Skip to content

V7 getByText no longer find translation string #553

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dephiros opened this issue Sep 25, 2020 · 10 comments
Closed

V7 getByText no longer find translation string #553

dephiros opened this issue Sep 25, 2020 · 10 comments
Labels
bug Something isn't working duplicate This issue or pull request already exists

Comments

@dephiros
Copy link

dephiros commented Sep 25, 2020

Describe the bug

In our codebase, we implement translation with jsLingui and have code like this:

// trivial implementation of Trans

const Trans = (message) => message;

const Component = () => (
    <Text>
      <Trans>There was a problem fetching data.</Trans>
    </Text>
)

Trans would render a string.
Previously, getByText("There was a problem fetching data.") would return a match and it no longer does

Expected behavior

getByText("There was a problem fetching data.") should return a match

Steps to Reproduce

See above

Screenshots

debug() would render

        <Text>
          There was a problem fetching data.
        </Text>

Versions

  npmPackages:
    @testing-library/react-native: ^7.0.2 => 7.0.2
    react: 16.11.0 => 16.11.0
    react-native: 0.62.2 => 0.62.2
    react-test-renderer: 16.11.0 => 16.11.0
@thymikee
Copy link
Member

This should definitely pass. cc @AugustinLF working on this field

@thymikee thymikee added the bug Something isn't working label Sep 28, 2020
@AugustinLF
Copy link
Collaborator

Yep, there's some changes incoming to the way we find text in the rendered component. This use case should be covered, I also feel that it was already covered. Would you mind having a look at #554 and see if it works for your use case?

@dephiros
Copy link
Author

Yep, there's some changes incoming to the way we find text in the rendered component. This use case should be covered, I also feel that it was already covered. Would you mind having a look at #554 and see if it works for your use case?

@AugustinLF , thanks for the response. I will try today and report back

@jbolotin
Copy link

Experiencing this as well with react-intl

@dattarzadeh-evidation
Copy link

We are possibly experiencing this as well. We are using i18n-js and expo-localization. We are on react-native v0.63.3.

@vcarl
Copy link

vcarl commented May 6, 2021

Also experiencing this with Lingui, I've set up a reproduction of the issue.

Calling debug() appears that the text is present in the output correctly

  console.log
    <View>
      <Text>
        Unwrapped text
      </Text>
      <Text>
        ES In Trans
      </Text>
    </View>

But it still fails to be found.

 FAIL  __tests__/components/Repro.js (7.229 s)
  Repro
    ✕ renders (5270 ms)

  ● Repro › renders

    Unable to find an element with text: ES In Trans

      10 |       debug();
      11 |       await findByText("Unwrapped text");
    > 12 |       await findByText("ES In Trans");
         |             ^
      13 |     } catch (e) {
      14 |       console.error(e);
      15 |       throw e;

@nirbenya
Copy link

I'v found a workaround for react-intl.
When you test your component with RTL you probably wrap your component with an intl-provider.
Something like that:

const { getByText } = render(<IntlProvider><MyComponent /> </IntlProvider>

So what fixes the issue for me and allowing me to use getByText is turning this to:


const { getByText } = render(<IntlProvider textComponent={Text}><MyComponent /> </IntlProvider>

This forces the FormattedMessage component to use Text as a wrapper instead of React.Fragment which is the default.

@thymikee
Copy link
Member

@nirbenya thanks for sharing! This makes sense, because RNTL uses native Text for matching text nodes.

@jehartzog
Copy link

We are using i18n-js and are seeing this too. I ended up with a patch-package which fixes it, although you end up with duplicate nodes matching. Doesn't really matter for our current use case, I end up just matching text via:

expect(queryAllByText(/look for me/i).length).toBeGreaterThanOrEqual(1);

@AugustinLF AugustinLF added the duplicate This issue or pull request already exists label Mar 29, 2022
@AugustinLF
Copy link
Collaborator

The issue is also related to #937. We're discussing potential solutions there and will therefore close this issue meanwhile. If you disagree with me, please let me know :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

8 participants