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.
Hi in chrome debugger, the files that use sourcemaps from the transformer get "null" as the filename during debug, https://github.com/facebook/react/blob/master/main.js#L15 "sourceFilename" is used instead of "filename" to specify the filename in the sourcemap.
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 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.
Paul O’Shannessy