add native-testing-library and update react faqs

[bcarroll22]

Per a request from Kent on Twitter, I'm adding some information about the native-testing-library I built to the docs site. The page is bare, but only because the docs site is so comprehensive, so I just linked the readers to it.

The reason I added it to the ecosystem instead of wrappers is because it isn't really a dom-testing-library wrapper, but it does effectively implement the API... so I consider it part of the ecosystem. I know that doesn't really match with what the "ecosystem" section is right now, but it seemed like a better match than wrappers.

If there's somewhere else you'd like me to put it, just let me know... I was just guessing that was the best place to put it. Thanks!

[alexkrolick]

Thanks for the PR. A few questions -

1. What is the difference between https://github.com/bcarroll22/native-testing-library and https://github.com/callstack/react-native-testing-library?

2. Are you sure you want to fork the entire docs site? Maybe wrappers isn't the right word for the heading, but it seems like a reasonably comparable version of the docs you have now could be maintained as a directory within this site. I just mention this as a way to opt in to any future improvements we add to the layout, formatting, or meta pages. And maybe SEO?

[alexkrolick]

We could change "Wrappers" to "Frameworks". The sidebar heading isn't navigable so changing it doesn't break any links.

[bcarroll22]

Yeah no problem!

1. To be honest, I believe the two probably have kinda the same intent, my team just wasn’t happy with existing solutions. To me, the best parallel are the early days of navigation in react native. Everyone wanted to get you screen to screen, and they all had a take on how to do it right. For transparency on this PR, my goal was to fully adhere to the guiding principles, and my success criteria was that all tests from testing-library pass in native-testing-library. That’s a great transition to the next question.
2. The tests from -testing-library are all implemented, and do pass, but basically every one needed to be refactored to use the native library syntax. That’s true about most everything about this project. I would have loved to coexist in the testing-library docs, I also would’ve loved to leverage a lot of the dom-testing-library repo, but I truly believe it would do a disservice to us both. I believe that one of the great things about using *TL is that the docs are a clear, informative resource. Also, everything in the code is clear and straightforward. One of the things we were unhappy with regarding existing solutions was that they didn’t feel as thorough/supportive as testing-library.com, and to us, that was a miss. Although with this library, you can probably infer a lot from community resources of react-testing-library, I don’t believe official docs should force you to infer, and that’s what we would’ve ended up expecting.

In summary, I just had to refactor so much to get things to work in native, and had to re-word/edit so much of the docs to get to the end goal of giving native users the same confidence, that I believe it would be wrong to co-locate them. My original intent was to try to PR to dom-testing-library to support native, but it would’ve been gross. Everything, with the exception of maybe 2 or 3 files, had to change to accomplish this goal. I’ll modify the PR to put the sections wherever you want, but I think it’s unfair to DOM and native users to share a docs site, because although I want more than anything for them to “feel” the same, under the hood they are different libraries with different needs, and I think users of both should expect to maintain the same level of clarity when using the respective libraries. I hope this made sense 😬

[kentcdodds]

Personally, I think that even though this doesn't use dom-testing-library under the hood, it still makes sense to get the same first class treatment as the other implantations on the docs site. Lots of people ask me about a native solution despite the existing link. Having it as an actual part of the docs like everything else will give it more legitimacy I think.

[bcarroll22]

Makes sense to me!

You guys can just let me know what changes you want me to make to this PR to get it merged. The only thing that really matters to me is that it have its own site because of the fundamental differences between this and every other implementation in the family (I really think it'll cause less friction for the users). That said, whatever info about it you want in testing-library.com I'd be happy to provide!

[alexkrolick]

At the risk of sounding like I'm proposing a corporate merger (avoiding the word "synergy" 😄), I think there's a lot of value in trying to stick to one site:

• Presenting as one site helps keep a consistent narrative across frameworks. All the libraries are unified by the guiding principles; many users use Cypress and React together and React Native is another part of the broader React community.
• Splitting up and partially referencing pages like the principles, Jest setup, and examples will split search engine traffic and potentially confuse some users.

I think we can come up with a way to maintain a solid experience within the site that encapsulates all the React Native-specific stuff you've done. As Kent said on Twitter this is the strongest effort yet to get something that adheres to user-centric patterns on React Native and pairing it with the existing documentation should give it a string boost in terms of visibility and adoption.

[bcarroll22]

This is still on my mind, I'm just still thinking about it. I don't want to rush to any conclusion. I think we both have a pretty deep conviction, and I want to make sure we've thought it through pretty thoroughly.

I've been going back through the docs of both, there's just so much specific to react-native on every page because of the underlying differences between native and dom. My only thought is that all we could duplicate nearly every page on testing-library.com, but does that seem right? To me, it seems wrong.

Could they merge the docs for react-dom and react-native? I honestly believe that might be a good parallel. I think it would be so confusing for users if that were the case. I'm not trying to be combative or contrarian, I just really think there needs to be a dedicated site. I don't leverage anything from dom-testing-library, whereas every other wrapper on the site has an easy path to success; just mostly use dom-testing-library docs, library specific docs are small and thin. That's not our scenario with native, almost nothing is exactly the same.

<div role="button" /> means nothing to native-testing-library, <View accessibilityRole="button" /> does though.

queryAllByValueText() doesn't exist in native-testing-library, but queryAllByValue() does though.

These are just two examples, but really everything in the library would've been just as worthy of an example (except like, maybe getByText()and a few other things?

Summary: although native-testing-library and dom-testing-library are kindred spirits, but so are react-dom and react-native, and they're different enough to warrant docs sites for the sake of end users. Maybe the right answer is to pivot testing-library.com to a very generic philosophy/guiding principle site and have separate sites for dom-testing-library and its family of wrappers as well as a site for native-testing-library? Maybe dom.testing-library.com and native.testing-library.com? Just an idea, not saying I believe that's right 🤔

[kentcdodds]

Honestly I don't feel super strongly about it personally. It sounds like you do though and you have good reasons. I'm fine with just linking to the site instead 👍

[alexkrolick]

I'm OK with merging this as-is and thinking about how to better organize this later. I'll open a follow-up issue.