We need to use dump cache because we don't enable it by default internally.
While I'm at it, I might as well kill the ComponentFactory variable which
is now just an alias.
Classes are now pure classes without a legacy factory around them.
Since classes will become just any function that returns a valid instance,
let's drop isValidClass.
There's some hacks in here for auto-mocking frameworks (jest) that mock the
prototype of these classes. These hacks allow these classes to be mounted.
On ios device, browser simulates mouse events, but does that with
a delay, because of double tap gesture. The problem is that
TapEventPlugins listens to both types of events, so it fires twice
Everytime there is a touch event, we should ignore mouse events that
follow it. This way, we still respond to both mouse and touch events,
just ignore the device generated ones.
For example, warning might be replaced with a module that throws errors,
as is the case internally when running tests. Previously we were
whitelisting this test to provide time to update callsites. Now we
aren't and it fails.
This prevents feature tests like:
var ReactElement = React.createElement(...).constructor;
if (element.constructor === ReactElement)
This is intentional so that we have the option to make these plain objects.
E.g. for direct inlining or replacing them with value types.
This moves logic responsible for class creation and mixins into
the ReactClass module. This currently creates a class that extends
the ReactCompositeBase but in the future, this will be decoupled as
ReactCompositeComponent will compose these classes.
This is just a cut/paste.
Fixes#1392.
Previously, ReactComponent.updateComponent set the new props and owner and updated the component's refs. Because it did the actual props assignment, it had to be called by ReactCompositeComponent between componentWillMount and componentDidMount, meaning that it was skipped if shouldComponentUpdate returned false. Now, updateComponent takes the old and new descriptors and only updates refs, allowing a subclass to call updateComponent at a convenient time (specifically, it can be before `this._descriptor` is updated if the subclass also overrides performUpdateIfNecessary).
The new update cycle for composites is:
- receiveComponent is called which stores `this._pendingDescriptor` and calls performUpdateIfNecessary directly or a state update is enqueued, in which case ReactUpdates will call performUpdateIfNecessary
- performUpdateIfNecessary ensures that an update is still pending (which might no longer be the case if an update is queued for a subcomponent that was updated through a parent's reconciliation) and calls updateComponent with the old and new descriptors
- updateComponent calls super to update refs, then calls componentWillReceiveProps (if applicable) and shouldComponentUpdate -- if shouldComponentUpdate returns false, `this._descriptor`, `this.props`, and `this.state` are updated and the update is skipped; else, _performComponentUpdate is called
- _performComponentUpdate calls componentWillUpdate and _updateRenderedComponent, and enqueues the componentDidUpdate call (in that order)
- _updateRenderedComponent calls render and updates the rendered component appropriately
For DOM components (essentially unchanged):
- receiveComponent is called which does a short-circuit check for descriptor equality and delegates to super (which stores `this._pendingDescriptor` and calls performUpdateIfNecessary)
- performUpdateIfNecessary (not overridden) sets new values for `this.props`, etc. and calls updateComponent
- updateComponent does the DOM property and children updates (some synchronously, some queued for the transaction close)
For text and ART components (unchanged):
- receiveComponent updates the DOM or ART directly based on the new props
- updateComponent is never called
Notable changes:
- When shouldComponentUpdate returns false, refs are still updated
- ReactDefaultPerf now includes lifecycle methods in component timings
- updateComponent's signature changed (technically this is part of the public API, though we've never documented it)
Test Plan: jest
Same for <pre> and <listing>. Browsers are crazy.
Test Plan: jest, verify in Chrome that starting textareas with a value starting with two newlines renders both newlines instead of one newline, as it did before.
This lets you use any kind of iterable as a container of react child elements. It also preserves keys when possible if the iterable is keyed.
* Use an ES6 Map or Set to hold children.
* Use an Immutable-js collection to hold children.
* Use a function* which yields children.
Concretely, this removes the necessary conversion to JS objects if you're mapping over Immutable-js collections to get children, i.e.:
```
<div>
{myImmutable.map(val => <span>{val}</span>).toJS()
</div>
```
Now we can remove the `toJS()` and the intermediate allocation along with it.
This also cleans up the traverseAllChildrenImpl method.
Because the JS community's polyfilling infrastructure sucks and we'll
have to fix it for them before we require this.
JSX spread uses React.__spread
(which might get special behavior for key/ref, not sure yet)
This never uses the native implementation and throws for prototype chains.
Once the native implementations are faster, we'll start using them.
People may have a bad time if they're depending on these but we can
delay that a little bit. Unless they're using directly and not
polyfilling Object.assign.
Because we're using innerHTML to generate DOM Elements, we need to make
sure that the tag is sane and doesn't try to do injection.
This wouldn't be an issue if we used document.createElement instead.