Make _owner from ReactElement non-enumerable

[gaearon]

This makes it invisible to test frameworks which solves #5292 and #6194.

Reviewers: @sebmarkbage

[gaearon]

Before this PR, this comparison used to break due to _owner. See https://github.com/bmullan91/react-shallow-renderer-bug for a repro case.

[quantizor]

I believe this will break IE8 compatibility.

[sebmarkbage]

This is the hottest path in React. Worried about perf. We can do it in DEV but a bit risky if someone uses spread. However I thought this worked at one point. Is it because we didn't attach owner in shallow renderer?

[gaearon]

I believe this will break IE8 compatibility.

I don’t think so. Still using canDefineProperty and falling back to setting it directly when we can’t. And this is identical to how we already do this with element._source, for example.

However I thought this worked at one point. Is it because we didn't attach owner in shallow renderer?

Asserting on render output for classes works fine as they normally don’t get the _owner in shallow rendering. We have problems in two cases:

• Testing class components that generate elements during the constructor (Change in _owner causes issues with shallow rendered tests #5292)
• Testing functional components (shallow rendering stateless components vs stateful components - different _owner #6194)

The reason these two case are problematic is the following. Normally, for composites, during shallow rendering we replace _renderValidatedComponent with _renderValidatedComponentWithoutOwnerOrContext. This doesn’t seem very nice encapsulation-wise but I guess it does the job.

However, functional components create element during the initial constructor call. Same is true for #5292 where elements end up being created in the constructor. The constructor call is inlined in mountComponent which always sets ReactCurrentOwner, and there is no corresponding _callConstructorWithoutOwnerOrContext. We can introduce it and use a similar pattern as with _renderValidatedComponent if we want to. Would you like to go down that road instead?

[sebmarkbage]

Setting owner during the constructor was always sketchy. I guess it was for some error message. It should use a different flag. I think I have PR for it somewhere.

Creating elements in the constructor is sketchy too because you might be tempted to mutate it which would break with automatic bailouts for elements.

[gaearon]

Setting owner during the constructor was always sketchy.

It was added with the first stateless component commit: 5a7bd96. If we remove the owner completely, are we also going to remove information about it from ReactPerf? It’s quite useful as the aggregation key in the inclusive summary.

[sebmarkbage]

I believe the reason it was added was because in 0.14 we didn't know if something would be a stateless component or not before calling it. With 0.15 we could remove it since we have the isReactComponent check.

We had an idea to infer ownership based on source code location for debugging purposes. The babel plugin that adds source file and line information would let us do that. Not sure if that would be solid enough for ReactPerf.

[gaearon]

We had an idea to infer ownership based on source code location for debugging purposes. The babel plugin that adds source file and line information would let us do that. Not sure if that would be solid enough for ReactPerf.

Ideally we’d like to know the name of closest enclosing class or createClass() expression but it’s doable with Babel.

[gaearon]

Superseded by #6362. @sebmarkbage Mind taking a look?