Without this we end up bundling all of the isomorphic React into
the DOM bundle. This was fixed in #7168 too but I'll just do an
early fix to ensure that #7168 is purely an npm change.
* 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.
This took a while to figure out, but we need to be able to store
children that are currently being worked on separately from the
current children. We always need a canonical "current" children
so that we can update them. However, we also need a different set
that we're currently working on so that we have a way to get to
already progressed work.
This solve the starvation problem in the first render because now
we can reach children that were never rendered and have a place
to store their progressed work on. The unit test changes tests
this.
This lets us get rid of the hasWorkInProgress flag.
When we reconcile new children we need to reconcile them against
progressed work so that we can reuse it. The progressed work is
"work in progress" nodes. So in that case we need to mutate
instead of clone, to preserve the invariant that only two versions
exist at any given point. This effectively forks the
ReactChildFiber implementation.
We need to use the *other* child because we reset it to the
current one on the way up.
We also need to reset the first/last side-effects to that of the
children so that we're committing the right thing.
Thanks @acdlite. Add comment about future unit test coverage.
This was actually hiding the fact that we are only able to reuse
existing work if it was marked as completely finished which it
won't be if we reuse its pending priority.
However, we should be able to bail out even if there is work
remaining in a subtree.
When we downprioritize children we need to remember to reuse the
old children in the update side-effect.
This whole set up is very unfortunate since we can have children
in our active tree that never actually finished rendering. This
strategy might be fundamentally flawed, not sure.
This might become confusing later but is unreachable today. That's
because existing pendingProps only matter when a clone is updated,
but this path can only matter when it is created.
If the current work is higher priority than the new work, then
don't bother resetting the unit of work pointer since it won't
affect the execution order.
I'm paranoid about inline-ability so I use this pattern of adding
a constant to the closure everywhere.
ES6 modules help avoid that but we can't use that consistently
because of the dependency injection so instead I opt for making
this explicit everywhere.
Grep: \b[a-zA-Z_$\d]+\.[a-zA-Z_$\d]+\(
'change' custom events raise "Member not found" in <= IE10. To
circumvent this, the SyntheticEvent class now checks for "typeof
event.cancelBubble !== 'unknown'". This eliminates this exception and
maintains the expected bubbling functionality.
Addresses #7320.
* PropTypes: distinguish nullable from optional object field
This gives a more precise message (no type semantics change) to the case of passing a field in an object, but whose value is `null`:
Before:
```js
propTypes: {
foo: React.PropTypes.number.isRequired
}
```
Would scream "Required prop `foo` was not specified in `MyComp`".
Now it'll be "Required prop `foo` was specified in `MyComp`, but its value is `null`.".
Works as expected in nested objects.
This fixes the issue of a component transitively passing a `null`, specifying the correct field to the child but have the child tell it that it didn't provide the prop.
Optional field and nullable are two different things anyway.
* Add missing test case.
* Reword messages.