Previously, the extract-components script would create the same number of layers of composites as the page it captures, but it would output a new class for each time any composite is used (since we don't want to replicate all the component logic).
I changed the script to output a single type for each type in the input -- and each generated component takes an index for which output it should return. This should be closer to how the original code behaves, especially with respect to VM function call lookups where the amount of polymorphism makes a difference.
I re-recorded the benchmarks with the new scripts. They run significantly faster:
```
Comparing old.txt (control) vs new.txt (test)
Significant differences marked by ***
% change from control to test, with 99% CIs:
* ssr_pe_cold_ms_jsc_jit
% change: -41.73% [-43.37%, -40.09%] ***
means: 39.3191 (control), 22.9127 (test)
* ssr_pe_cold_ms_jsc_nojit
% change: -44.24% [-46.69%, -41.80%] ***
means: 45.8646 (control), 25.5764 (test)
* ssr_pe_cold_ms_node
% change: -45.61% [-47.38%, -43.85%] ***
means: 90.1118 (control), 49.0116 (test)
```
This is probably in part due to the changes here, but also the page I captured has changed somewhat in the meantime and there seem to be slightly fewer components in the hierarchy, so they're not really comparable. But going forward we can use this benchmark which should be more accurate. I also included an identical copy that uses stateless functional components so we can test optimizations to those later.
As reported in #7227, unmounting performance regressed with React 15.
It seems that `delete` has become much slower since we started using numeric keys.
Forcing dictionary keys to start with a dot fixes the issue.
* Add failing test demonstrating a ReactPerf warning
* Make the failing ReactPerf test more precise
* Make ReactPerf.start() work during reconciliation
* Reorder lifecycle methods for greater clarity
* Fix memory leak
* Error boundaries should not break ReactPerf
* Put onBeginFlush/onEndFlush into transaction wrappers
This looks cleaner even though it is not strictly necessary.
We still call them manually for unmounting because it doesn't have a transaction.
This provides an easy way to indicate that components should only rerender when given new props, like PureRenderMixin. If you rely on mutation in your React components, you can continue to use `React.Component`.
Inheriting from `React.PureComponent` indicates to React that your component doesn't need to rerender when the props are unchanged. We'll compare the old and new props before each render and short-circuit if they're unchanged. It's like an automatic shouldComponentUpdate.
* Add failing tests for #7187 and #7190
* Pass shouldHaveDebugID flag to instantiateComponent
This allows us to remove a hack that was added in #6770 and caused #7187 and #7190.
* Move logic for choosing whether to use debugID outside instantiate
Touch behavior is inconsistent across different platforms, and ResponderTouchHistoryStore currently fatals when assumptions are broken. In addition, the behavior differs between development and production.
This pull request does a few things to make ResponderTouchHistoryStore easier to deal with:
Adds Flow to keep the TouchEvent, Touch, and TouchRecord types straight.
Changes behavior to be consistent across environments. This means either always throwing or never throwing (and making use of warning and console.error as appropriate).
When an orphaned move or end event is received, print debug information and ignore it instead of crashing and burning.
* Warn if PropType function is called in production
* Check if console is undefined before warning
* Randomize value of ReactPropTypesSecret
* Remove dev environment tests
* Rename typeCheckPass to productionWarningCheck
* Rename productionWarningCheck to expectWarningInProduction
* Call toString on Math.random()
* Rename test block for React type checks
* Make sure warning isnt emitted for failing props
* Cache warning by component and prop, warn in dev
* Pass ReactPropTypesSecret to internal checks
* Move tests to ReactPropTypes-test.js
* Update the warning message to include link
* Do not test warning for unions with invalid args
Summary:
I had to cast into any because flow doesn't think that checking the lowercase version of nodeName is a valid way to refine the variable from HTMLElement to HTMLInputElement. I'm also not confident enough in changing the implementation to an instanceof HTMLInputElement to please flow. It also takes care of the null check in the process.
The `nodeName &&` condition wasn't useful since the two branches are checking it against concrete values and actually makes the type different since nodeName is not a boolean per se. I replaced them with if conditions to make it clearer what it actually did instead of doing boolean logic tricks.
It is unclear why I had to type supportedInputTypes, see this internal post for a discussion: https://www.facebook.com/groups/flowtype/permalink/1084168611631753/
The only difference in behavior is that I now explicitely convert to boolean the object dereference via `!!`.
Test Plan:
npm run flow
Careful inspection of the code
Reviewers: @zpao @spicyj
* Inline dev-only requires
This reduces the production bundled build size.
* Use new references after resetting module registry in tests
This fixes the tests which were broken due to inlining some requires.
This commit fixes#5473: ReactDOMServer.renderToString: presence of onClick
handler causes errors on async update
This commit performs the following changes:
- Adds a getUpdateQueue method to ReactServerRenderingTransaction,
ReactReconcileTransaction, ReactNativeReconcileTransaction and
ReactTestReconcileTransaction
- Make the ReactCompositeComponent call this getUpdateQueue instead of using
ReactUpdateQueue that was unwanted at certain moments on server
- On ReactServerRenderingTransaction, dispatch ReactUpdateQueue's methods
while rendering and warning methods afterwards. This is done through the new
ReactServerUpdateQueue class
- Added a series of tests that mimics the case presented in #5473 with setState,
forceUpdate and replaceState
- Add flow typechecking on concerned files
- Removed the prop transitionAppearTimeout from
addons/transitions/ReactTransitionGroup in order to remove a warning
when passing unknown props to DOM elements.
This is only for host nodes so that the DOM tree is fully updated
by the time we've flushed.
Classes will schedule their life-cycles *after* their children's
side-effects.
This creates a new API for processing side-effects on the host
environment.
During initial reconciliation host instances are created during
the time sliced periods.
During updates there is an opportunity for the host
to prepare something on the instance during the time slicing, and
to determine whether there were any changes. The could be thrown
away.
At the commit phase, these changes are finally committed to the
host instance.
This adds tracking of side-effects that gets scheduled during an
update.
As the tree gets reconciled, the side-effectful fibers are linked
together in an ordered singly linked list. That way we can walk
the linked list to commit only the work that needs to be
synchronous - quickly.
We also store first and last nodes within a fiber. That
way when we reuse an already processed subtree, we can reuse that
subset of the linked list.
