This should be safe because we've been warning for this. The LinkedStateMixin is technically exposed on React.addons without a warning but presumably you wouldn't be using it without a valueLink or checkedLink.
I do this primarily to clear up what the custom onChange listeners are doing.
Renamed the final prop type helper to ReactControlledValuePropTypes.
The script that strips providesModule is very sensitive.
Test plan:
Searched for providesModule in build. No more.
reactComponentExpect used to have problems too but doesn't seem
to anymore. Don't know why.
This one involves a bit more work as I added "phantom" flow types to a bunch of places where the type is a ReactPropTypeLocations even though those files are not `@flow` yet.
A good side effect is that `ReactPropTypeLocationNames` keys are now correctly typed, this means that they cannot go out of sync without breaking flow :)
* 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.
* 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.
* 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
- Removed the prop transitionAppearTimeout from
addons/transitions/ReactTransitionGroup in order to remove a warning
when passing unknown props to DOM elements.
* create failing test case
* Fix renderSubtreeIntoContainer to update context
Fixes#6599
* Also test re-rendering due to prop update
* Address review feedback
Summary:
The only callsite of ReactStateSetters is in LinkedStateMixin which lives in addons/link. Better move it there to avoid cluttering the other folder.
Test Plan:
None
Reviewers: @zpao @spicyj
* Update shallowCompare to accept nextContext
Across our application we are using immutable objects as properties and thus using shallowCompare for all our {{shouldComponentUpdate}}. Because of this children with contextTypes don't get updates when the context on the parent changes. Adding an additional comparison for context (when it is provided) fixes this problem.
* Remove the undefined check
* Add nextContext
This makes it easier to figure out where the docs live.
Googling for e.g. `react-addons-update` also works, but this should
make things easier for people that hyperclick directly to the source.
When referring to mixin, the rest of the comment is in lowercase; see line 36 and line 37.
This change helps with the consistency of the usage of "mixin", and not to confuse it with a variable name.