We don’t want to have different behavior in development and production.
Previously, we used to ignore getters on key/ref in dev, but we’d read them in prod.
Now, we only ignore the getters that we *know* we created so the production logic doesn’t differ.
This way in other cases both DEV and PROD falls through to the check for undefined.
This fixes#6879 and a similar bug introduced for cloneElement() in 94d0dc68c8.
It currently fails in `createElement` because of #6879 which was introduced in #5744.
It also fails in `cloneElement` because the code with that bug was extracted and shared in 94d0dc68c8.
Previously, this threw:
```
FAIL src/test/__tests__/ReactTestUtils-test.js (7.291s)
● ReactTestUtils › it can fail context when shallowly rendering
- TypeError: Cannot read property '_source' of null
at describeID (src/renderers/shared/devtools/ReactComponentTreeDevtool.js:70:46)
at Object.ReactComponentTreeDevtool.getStackAddendumByID (src/renderers/shared/devtools/ReactComponentTreeDevtool.js:203:15)
at checkReactTypeSpec (src/isomorphic/classic/types/checkReactTypeSpec.js:76:58)
at ReactCompositeComponentMixin._checkContextTypes (src/renderers/shared/stack/reconciler/ReactCompositeComponent.js:668:5)
at ReactCompositeComponentMixin._processContext (src/renderers/shared/stack/reconciler/ReactCompositeComponent.js:607:14)
at ReactCompositeComponentMixin.mountComponent (src/renderers/shared/stack/reconciler/ReactCompositeComponent.js:191:30)
at ReactShallowRenderer._render (src/test/ReactTestUtils.js:483:14)
at _batchedRender (src/test/ReactTestUtils.js:460:12)
at ReactDefaultBatchingStrategyTransaction.Mixin.perform (src/shared/utils/Transaction.js:140:20)
at Object.ReactDefaultBatchingStrategy.batchedUpdates (src/renderers/shared/stack/reconciler/ReactDefaultBatchingStrategy.js:65:19)
at Object.batchedUpdates (src/renderers/shared/stack/reconciler/ReactUpdates.js:112:20)
at ReactShallowRenderer.render (src/test/ReactTestUtils.js:453:16)
at Spec.eval (src/test/__tests__/ReactTestUtils-test.js:289:34)
at jasmine.Block.execute (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:1067:17)
at jasmine.Queue.next_ (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2100:31)
at jasmine.Queue.start (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2053:8)
at Spec.jasmine.Spec.execute (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2380:14)
at jasmine.Queue.next_ (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2100:31)
at onComplete (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2096:18)
at Spec.jasmine.Spec.finish (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2354:5)
at eval [as onComplete] (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2381:10)
at jasmine.Queue.next_ (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2110:14)
at eval (node_modules/jest-jasmine1/vendor/jasmine-1.3.0.js:2090:18)
at Timeout.e [as _onTimeout] (node_modules/jsdom/lib/jsdom/browser/Window.js:440:19)
at tryOnTimeout (timers.js:224:11)
at Timer.listOnTimeout (timers.js:198:5)
```
* Don't count the time inside flushes towards lifecycle hooks
Fixes#6842.
We keep the existing behavior of testing for matching `onBeginLifeCycleTimer`/`onEndLifeCycleTimer` calls, but we push the current timer onto the stack if we enter a flush.
This solves an issue with portals which cause updates while a lifecycle timer is already running.
I chose to subtract the time spent in the flush from the time counted towards the lifecycle method because it would artificially inflate the “total” time of the component due to all the components inside the portal, so it would skew the exclusive table.
* Fix up the comment
This helps us make sure we don't break React ART in a minor or patch release. The idea is to not change these files when making minor or patch changes. Copied directly from react-art with requires fixed. (I also picked a different haste name just in case.)
* Fix componentWillUnmount() not counted by ReactPerf
* Test that functional component render() time shows up in ReactPerf
* Test for setState() code path updates being included
* Update shallowCompare to accept nextContext
Across our application we are using immutable objects as properties and thus using shallowCompare for all our {{shouldComponentUpdate}}. Because of this children with contextTypes don't get updates when the context on the parent changes. Adding an additional comparison for context (when it is provided) fixes this problem.
* Remove the undefined check
* Add nextContext
This adds some tests for getElement() and verifies that it works for text components too.
The code that calls the instrumentation is fixed where necessary so that the tests pass.
Ben Alpert
Nate Norberg
Jim
Paul O’Shannessy
Sebastian Markbage
Robin Berjon
Weizenlol
Dan Abramov
Eric Matthys
Dmitrii Abramov
Ben Alpert
Ali Taheri Moghaddar
Keyan Zhang
Rui Araújo
Roderick Hsiao
chico
Ben Berman
Dustan Kasten
Tony Rossi