Flow doesn't really support the concept of variables that are non-null but only inside of a `__DEV__` block. There's an internal post about it ( https://www.facebook.com/groups/flowtype/permalink/1132437726804841/ ) and the conclusion is that we should force it to be non-null and trust the developer to put the proper DEV checks in place.
We need to export FlushHistory type and I submitted a PR on flow to fix the type of console.table which is too restrictive.
I'm already starting to see the benefits of flow, I can look at random variables in the code and flow knows what shape the objects are! It's really useful to try and understand what's going on :)
In Type ReactComponentTreeHook #7504, I merged even though travis didn't report green (travis for all the fb repos has been backlogged like crazy since this morning) by manually doing `npm test` and `npm run flow` but I didn't ensure that lint was all green.
@millermedeiros pinged me about it so here's a quick fix
For this one, I wanted to type a non-trivial piece of the codebase and ran into the fact that we do not have types for ReactElement nor ReactInstance, so I had to create them.
I'll add comments inline
It used to be slow whenever a type miss occurred because expensive `Error` objects were being created. For example, with `oneOfType([number, data])`, passing a date would create an `Error` object in `number` typechecker for every item.
The savings depend on how much commonly you used `oneOfType()`, and how often it had “misses”. If you used it heavily, you might see 1.5x to 2x performance improvements in `__DEV__` after this fix.
* Write failing test
* Ensure .min and .max are set before .value
* Adjusting test for false negative
* Revert test adjustment (apparently it was only failing locally)
I already had to aliasify to have better control over the requires
so we might as well do it everywhere for consistency.
This probably makes it easier to rebase the rollup work too
because aliases seems to be how you solve this in that world.
This is needed for flat builds. It also lets us get rid of a bunch
of special cases in the build scripts.
It also allow us to just copy the source files into React Native
instead of having to build first to resolve the special cases.
* Remove onBeforeMountComponent hook event
It is unnecessary.
We now pass the element as part of onInstantiateComponent, and it can't change before mounting.
* Remove onComponentHasMounted hook event
It is unused after #7410.
* Replace on(Begin|End)ReconcilerTimer hook events
We already have onBeforeUpdateComponent.
Let's just have on(Before?)(Mount|Update|Unmount)Component and stick with them.
This removes double event dispatches in some hot spots.
* Remove onComponentHasUpdated hook
The tests still pass so presumably it was not necessary.
* Add missing __DEV__ to TestUtils code
* Replace on(InstantiateComponent|SetParent) with onBeforeMountComponent
This lets us further consolidate hooks.
The parent ID is now passed as an argument to onBeforeMountComponent() with the element.
* Remove onMountRootComponent hook event
It is unnecessary now that we pass the parent ID to onBeforeMountComponent.
* Use parentDebugID = 0 both for roots and production
This removes some awkward branching.
This builds a `react-dom-fiber.js` bundle which exposes ReactDOMFiber.
This allows early experiments with the new Fiber reconciler.
I also expose it in the npm package through `react-dom/fiber`.
This copies modules into three separate packages instead of
putting it all in React.
The overlap in shared and between renderers gets duplicated.
This allows the isomorphic package to stay minimal. It can also
be used as a direct dependency without much risk.
This also allow us to ship versions to each renderer independently
and we can ship renderers without updating the main react package
dependency.
We currently write all our tests against the DOM implementation.
I need a way to run the Fiber tests against it. But I don't want
to take on any package dependencies on Fiber modules yet.
There's a problem with jest right now where you can't globally
mock modules that already exist. So I have to add a global call
to jest.mock.
Luckily we already have a way to test the useCreateElement paths
using a feature flag. I won't activate this flag in travis until
it passes, but the idea is to run all three variants in travis.
I'm not sure that invoking rAF and rIC synchronously is the best
way to test this since it doesn't capture the backwards
compatibility aspect. I.e. the fact that people might be relying
on the synchronous nature in real apps too. It's a start.
Ideally, jest would have these built-in.
* Remove unnecessary indirection from the tree hook
* Replace onSetDisplayName, onSetOwner, onSetText with one event
Less events is better.
onSetDisplayName, onSetOwner, and onSetText only existed because we didn't initially track elements.
* Remove unused variables
* Prevent internal performance regression
This only affects Facebook website, not open source version of React.
On the Facebook website, we don't have a transform for warnings and invariants.
Therefore, expensive arguments will be calculated even if the warning doesn't fire.
This fixes a few cases where that calculation might be more expensive than usually.
In my testing, this brings down average row click time in Power Editor from ~300ms to ~220ms in __DEV__ (vs ~40ms in prod).
* Put warning() that shows up in profile behind condition
* corrected ReactChildrenMutationWarningHook's name
* changed `onComponentHasMounted` to `onMountComponent`
and get element from `ReactComponentTreeHook` instead of keeping an internal store
* Cut out isomorphic dependencies from the renderers
These files reaches into isomorphic files.
The ReactElement functions are exposed on the React object anyway
so I can just use those instead.
I also found some files that are not shared that should be in
renderers shared.
* Found a few more shared dependencies
renderSubtreeIntoContainer is only used by the DOM renderer.
It's not an addon.
ReactClass isn't needed as a dependency since injection doesn't
happen anymore.
* Use a shim file to load addons' dependencies on DOM
By replacing this intermediate file we can do the lazy loading
without needing any lazy requires. This set up works with ES
modules.
We could also replace the globalShim thing with aliased files
instead for consistency.
* Bundle DOM renderers into their individual UMD bundles
Instead of exposing the entire DOM renderer on the react.js
package, I only expose CurrentOwner and ComponentTreeDevtool which
are currently the only two modules that share __state__ with the
renderers.
Then I package each renderer in its own package. That could allow
us to drop more server dependencies from the client package. It
will also allow us to ship fiber as a separate renderer.
Unminified DEV after before
react.js 123kb 696kb
react-with-addons.js 227kb 774kb
react-dom.js 668kb 1kb
react-dom-server.js 638kb 1kb
Minified PROD after before
react.min.js 24kb 154kb
react-with-addons.min.js 37kb 166kb
react-dom.min.js 149kb 1kb
react-dom-server.min.js 144kb 1kb
The total size for react.min.js + react-dom.min.js is +19kb larger
because of the overlap between them right now. I'd like to see
what an optimizing compiler can do to this. Some of that is fbjs
stuff. There shouldn't need to be that much overlap so that's
something we can hunt. We should keep isomorphic absolutely
minimal so there's no reason for other React clones not to use it.
There will be less overlap with Fiber.
However, another strategy that we could do is package the
isomorphic package into each renderer bundle and conditionally
initialize it if it hasn't already been initialized. That way
you only pay an overlap tax when there are two renderers on the
page but not without it. It's also easier to just pull in one
package. The downside is the versioning stuff that the separate
npm package would solve. That applies to CDNs as well.
ReactWithAddons is a bit weird because it is packaged into the
isomorphic package but has a bunch of DOM dependencies. So we have
to load them lazily since the DOM package gets initialized after.