Moved ReactFiberClassComponent validateCallback() helper function into a standalone util used by both fiber and stack implementations. Validation now happens in ReactFiberUpdateQueue so that non-DOM renderers will also benefit from it.
Fixes an issue (in both Stack and Fiber) where enqueueSetState causes
a synchronous update that flushes before enqueueCallback is ever called.
Now enqueueSetState et al accept an optional callback so that both
are scheduled at the same time.
We warn about getInitialState() usage in class components because users may have accidentally used it instead of state. If they have also specified state though then we should skip this warning.
Context: https://twitter.com/soprano/status/810003963286163456
This matches what we do in Fiber -- and doing it this way is the only way we can prepare new views in the background before unmounting old ones.
In particular, this breaks this pattern:
```js
class Child1 extends React.Component {
render() { ... }
componentWillMount() {
this.props.registerChild(this);
}
componentWillUnmount() {
this.props.unregisterChild();
}
}
class Child2 extends React.Component {
render() { ... }
componentWillMount() {
this.props.registerChild(this);
}
componentWillUnmount() {
this.props.unregisterChild();
}
}
class Parent extends React.Component {
render() {
return (
showChild1 ?
<Child1
registerChild={(child) => this.registered = child}
unregisterChild={() => this.registered = null}
/> :
<Child2
registerChild={(child) => this.registered = child}
unregisterChild={() => this.registered = null}
/>
);
}
}
```
Previously, `this.registered` would always be set -- now, after a rerender, `this.registered` gets stuck at null because the old child's componentWillUnmount runs *after* the new child's componentWillMount.
A correct fix here is to use componentDidMount rather than componentWillMount. (In general, componentWillMount should not have side effects.) If Parent stored a list or set of registered children instead, there would also be no issue.
This matches the behavior in Fiber. Normally we would change Fiber
to match Stack to minimize breaking changes for the initial release.
However, in this case it would require too large a compromise to change
Fiber to act like Stack.
I tried to add a temporary check for the correct state in https://gist.github.com/spicyj/338147e989215b6eeaf48a6ce2d68d93 and run our test suites over it, but none of our existing test cases would have triggered that invariant. The new one I added does.
* Use the public ReactDOMServer in tests
We need this because it runs the injection.
* Let Fiber skip react data attributes and comments in SSR tests
This markup is testing implementation details rather than behavior.
* Update ESLint to 3.10.2
Also pull in fbjs for extending properly, per @zpao. This also disables consistent-return, which has about 80 failing cases in React currently. If we'd like to turn this back on, we should do it separately and fix all the call sites properly (rather than just adding 'return undefined;' everywhere, which adds no value.
Fixes to all existing lint errors plus an update for yarn.lock to follow.
* Update yarn.lock after the eslint update.
* Fix all new eslint failures
Unfortunately I had to add three eslint-disable-next-line instances. All have explanations inline.
* Switch Travis to use yarn instead of npm
* Reapply Check for event listener in props instead of bank (#8192)
This reverts the previous revert.
* Don't throw on falsy event listeners
Some code relies on passing null. This restores the earlier behavior.
This matches Stack behavior.
Had to rewrite a test that used Simulate because Fiber doesn't support events yet.
Also changed tests for componentDidUpdate() since Fiber intentionally doesn't pass prevContext argument.
I'll plan to change all of our console.error and component-tree expects to expectDev. It's a little annoying that we need to make sure tests don't throw (see my change to normalizeCodeLocInfo) but any alternative would seem to require two separate test runs or a much more cumbersome syntax.
* Use _hostContainerInfo to track test renderer options
The transaction is not available when unmounting or updating the
instance, so we track it using _hostContainerInfo
* Throw if hostContainerInfo is not populated in getPublicInstance
* Linting fixes
* Remove transaction from ref lifecycle code path
We don't need to pass the transaction around anymore since we store the
test options on _hostContainerInfo instead
* Remove unused argument
This reverts commit a878c3056d.
The previous stuff that this builds on didn't successfully land fully. Since I
want to measure this in isolation, I'll revert this for now.
This just reads events from the props instead of storing them in a
listener back.
I had to rewrite a bunch of tests to cover this model.
I removed the tests that just test the adding and removing over listeners
since there is no equivalent behavior anymore.
* Use explicit pass for restoring controlled state instead of asap
This gets rid of the first class ReactUpdates.asap scheduling. Instead of
scheduling a first class function to invoke later, I introduce an explicit
phase for restoring controlled state after dispatching events.
We assume that the deepest event target is the thing that needs its state
restored.
* Drop special cases for onChange in wrappers
We're now not using anything special about onChange handling in the
wrappers. Yay!
Without this fix, in non-batched mode, the update is scheduled first and
synchronously flushed before the callback is added to the queue. The
callback isn't called until the next flush.
Now that commits are treated as atomic, it is possible that componentDidMount, componentDidUpdate, or componentWillUnmount threw in multiple places during the commit. We need to make sure we notify all affected boundaries of the first errors in them.
Prior to this, React was using a nextDebugID variable that was locally
scoped to both `instantiateReactComponent` and `ReactShallowRenderer`.
This caused problems when the debugIDs would collide, the `itemMap` in
`ReactComponentTreeHook` would be overwritten and tests would fail
with the message "Expected onBeforeMountComponent() parent and
onSetChildren() to be consistent".
This change shares the debugID with both modules thus preventing any
collisions in the future.
This is just moving a bunch of DOM files.
It moves things into dom/stack and dom/fiber respectively. The
dom/stack folder remains split into client/server.
Mainly the shared folder is now my best guess for files that
we can reuse in fiber. Everything else will get forked or
reimplemented.
Also moved the event system out of renderers/shared/stack and
into renderers/shared/shared.
* Consider Host Component classes when creating a new internal instance
* Remove unused tagToComponentClass & injectComponentClasses from ReactHostComponent
Dropped the unnecessary use of findDOMNode.
Dropped unnecessary arrow functions.
Math.random() -> id counter, since this used to be
non-deterministic which is not ideal for unit tests.
getOriginalKeys() used to rely on implementation details
to scan that the internal data structure maintained its
structure, however, since that is unobservable we don't
need to test the internal data structure itself. We're
already testing refs and dom structure which is the only
observable effect of the reorder.
* Initial pass at the easy case of updates (updates that start at the root).
* Don't expect an extra componentWillUnmount call
It was fixed in #6613.
* Remove duplicate expectations from the test
* Fix style issues
* Make naming consistent throughout the tests
* receiveComponent() does not accept safely argument
* Assert that lifecycle and refs fire for error message
* Add more tests for mounting
* Do not call componentWillMount twice on error boundary
* Document more of existing behavior in tests
* Do not call componentWillUnmount() when aborting mounting
Previously, we would call componentWillUnmount() safely on the tree whenever we abort mounting it. However this is likely risky because the tree was never mounted in the first place.
People shouldn't hold resources in componentWillMount() so it's safe to say that we can skip componentWillUnmount() if componentDidMount() was never called.
Here, we introduce a new flag. If we abort during mounting, we will not call componentWillUnmount(). However if we abort during an update, it is safe to call componentWillUnmount() because the previous tree has been mounted by now.
* Consistently display error messages in tests
* Add more logging to tests and remove redundant one
* Refactor tests
* Split complicated tests into smaller ones
* Assert clean unmounting
* Add assertions about update hooks
* Add more tests to document existing behavior and remove irrelevant details
* Verify we can recover from error state
* Fix lint
* Error in boundary’s componentWillMount should propagate up
This test is currently failing.
* Move calling componentWillMount() into mountComponent()
This removes the unnecessary non-recursive skipLifecycle check.
It fixes the previously failing test that verifies that if a boundary throws in its own componentWillMount(), the error will propagate.
* Remove extra whitespace
The script that strips providesModule is very sensitive.
Test plan:
Searched for providesModule in build. No more.
reactComponentExpect used to have problems too but doesn't seem
to anymore. Don't know why.
Before this change calling renderToStringImpl would inject
ReactDefaultBatchingStrategy after completion, even if a custom batching
strategy was injected before. This makes renderToStringImpl keep a reference to
the batching strategy before it runs and reinject it afterwards.
Brian Vaughn