Add notes for May 5 #13

Merged
merged 1 commit into from May 7, 2016

Conversation

Projects
None yet
2 participants
@gaearon
Member

gaearon commented May 7, 2016

Feel free to discuss in this PR!

@gaearon gaearon merged commit a8d5ba0 into master May 7, 2016

@gaearon gaearon deleted the gaearon-patch-1 branch May 7, 2016

+
+* Airbnb’s [Enzyme](https://github.com/airbnb/enzyme) is well maintained and supported.
+* Our [`TestUtils`](https://facebook.github.io/react/docs/test-utils.html) are not in a great shape, and most people prefer Enzyme.
+* Should Enzyme become the official `TestUtils`?

This comment has been minimized.

@glenjamin

glenjamin May 7, 2016

What would it mean to become the "official" test utils?

There is more than one test helpers lib out there, blessing a single one would be a bit harsh on the others.

I'd be in favour of trimming down TestUtils functions and linking to a community list of tools which build on top of it.

@glenjamin

glenjamin May 7, 2016

What would it mean to become the "official" test utils?

There is more than one test helpers lib out there, blessing a single one would be a bit harsh on the others.

I'd be in favour of trimming down TestUtils functions and linking to a community list of tools which build on top of it.

This comment has been minimized.

@gaearon

gaearon May 7, 2016

Member

It would mean that Enzyme is linked to in the documentation and we tell people to use it rather than to scryRenderedComponentsOfType. For us, it would also mean no longer shipping the TestUtils as we don’t use them that much at Facebook.

Whether either of this is something we want to do, or not, is unclear.

@gaearon

gaearon May 7, 2016

Member

It would mean that Enzyme is linked to in the documentation and we tell people to use it rather than to scryRenderedComponentsOfType. For us, it would also mean no longer shipping the TestUtils as we don’t use them that much at Facebook.

Whether either of this is something we want to do, or not, is unclear.

This comment has been minimized.

@glenjamin

glenjamin May 7, 2016

I think having core provide testing primitives and leaving userland to layer on top is a good thing, but I'd be wary of recommending only a single lib.

@glenjamin

glenjamin May 7, 2016

I think having core provide testing primitives and leaving userland to layer on top is a good thing, but I'd be wary of recommending only a single lib.

This comment has been minimized.

@gaearon

gaearon May 7, 2016

Member

This is one of the reasons why there is no decision on this yet. It's a tricky balance. “Testing primitives” is also vague: we do provide them today (TestUtils) but we are not sure that this is the primitives we want to expose. As noted in text, we’d rather see test runner as a custom React renderer. In this version of the future, React does not need to expose any hooks at all because the custom renderer has full control over components. This is probably where we want to go but the obstacle is we don't have a public API for renderers, and the internal APIs will be changing because of the work on incremental reconciler. Therefore writing custom renderers will be turbulent in the coming months. This was the reason React Native renderer code was pulled into React codebase—to allow faster iteration on the internals.

So none of this is clear yet. While TestUtils exist the way they do today, it doesn’t quite make sense to tell people to use something else yet. However in the future, it might make sense for Enzyme to become more tightly coupled with implementation details of React, at least until the renderer API shakes out. If this happens, and it gives us a way to deprecate TestUtils in the future, we’ll likely need to point to something—and I would expect that it’s likely we won’t have other test renderers at that point because creating a renderer right now is somewhat brittle and requires quite a bit of effort. In that case, maybe, recommending Enzyme officially might be sensible.

But we don’t know much yet. These are just thoughts aloud. We are talking through different options and did not choose any particular strategy.

@gaearon

gaearon May 7, 2016

Member

This is one of the reasons why there is no decision on this yet. It's a tricky balance. “Testing primitives” is also vague: we do provide them today (TestUtils) but we are not sure that this is the primitives we want to expose. As noted in text, we’d rather see test runner as a custom React renderer. In this version of the future, React does not need to expose any hooks at all because the custom renderer has full control over components. This is probably where we want to go but the obstacle is we don't have a public API for renderers, and the internal APIs will be changing because of the work on incremental reconciler. Therefore writing custom renderers will be turbulent in the coming months. This was the reason React Native renderer code was pulled into React codebase—to allow faster iteration on the internals.

So none of this is clear yet. While TestUtils exist the way they do today, it doesn’t quite make sense to tell people to use something else yet. However in the future, it might make sense for Enzyme to become more tightly coupled with implementation details of React, at least until the renderer API shakes out. If this happens, and it gives us a way to deprecate TestUtils in the future, we’ll likely need to point to something—and I would expect that it’s likely we won’t have other test renderers at that point because creating a renderer right now is somewhat brittle and requires quite a bit of effort. In that case, maybe, recommending Enzyme officially might be sensible.

But we don’t know much yet. These are just thoughts aloud. We are talking through different options and did not choose any particular strategy.

This comment has been minimized.

@glenjamin

glenjamin May 7, 2016

I'd like to see the shallow rendering capability remain a part of core react - whether that's a custom renderer or not shouldn't make a lot of difference to a consumer.

Enzyme's main utility is in replacing the find/scry methods with ones which work consistently when rendering to DOM, String or Shallow. Having that library be the only place where a shallow renderer exists would be disappointing.

If moving the shallow rendering code out of core is a goal, hopefully the community (myself included) will find a way to keep it decoupled from the test assertion / node traversal stuff.

I hadn't realised enzyme was already prominently featured on the TestUtils docs page. This is a bit disappointing to me, as although I have nothing against enzyme, it pretty much kills any hope similar libraries have of getting takeup when exploring that space.

Anyway, to summarise my thoughts on this:

  • 👍 deprecate (find|scry)*
  • 👎 moving shallow rendering out to enzyme
  • 😑 moving shallow rendering out to userland

This is driven from the fact I have a shallow-rendering based testing lib which is a couple of months older than enzyme and has ~40% of the monthly npm download numbers enzyme does. I'd like to see even more competition / exploration in this space, and having core bless a particular lib could stifle that.

@glenjamin

glenjamin May 7, 2016

I'd like to see the shallow rendering capability remain a part of core react - whether that's a custom renderer or not shouldn't make a lot of difference to a consumer.

Enzyme's main utility is in replacing the find/scry methods with ones which work consistently when rendering to DOM, String or Shallow. Having that library be the only place where a shallow renderer exists would be disappointing.

If moving the shallow rendering code out of core is a goal, hopefully the community (myself included) will find a way to keep it decoupled from the test assertion / node traversal stuff.

I hadn't realised enzyme was already prominently featured on the TestUtils docs page. This is a bit disappointing to me, as although I have nothing against enzyme, it pretty much kills any hope similar libraries have of getting takeup when exploring that space.

Anyway, to summarise my thoughts on this:

  • 👍 deprecate (find|scry)*
  • 👎 moving shallow rendering out to enzyme
  • 😑 moving shallow rendering out to userland

This is driven from the fact I have a shallow-rendering based testing lib which is a couple of months older than enzyme and has ~40% of the monthly npm download numbers enzyme does. I'd like to see even more competition / exploration in this space, and having core bless a particular lib could stifle that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment