Umbrella 0.13

[sebmarkbage]

• refs - make them callbacks instead of first class (@spicyj / @sebmarkbage)
• Move propType validation to element instead of class (@JSFB)
• Warning if class.type is accessed (@sebmarkbage)
  • Clean up internal (@JSFB)
• Expose React.Component base class (@sebmarkbage)
  • Fix context (Set up context before getInitialState is called #2898)
• Deprecate keyed objects as children with warning. (@JSFB / @sebmarkbage)
  • Add ReactFragment API, expose as React.addons.fragment?
• Fix ReactPerf
• Change unmounted setState checks from invariant to warning (@zpao)
• Add enqueueStateUpdate (name?) to enqueue updates that depend on this.state being consistent (since this._pendingState is gone). (@sebmarkbage)
• fix devtools (@sebmarkbage)
• do something about refs timing(Regression in 0.13: refs of siblings aren't resolved in previous siblings componentDidMount #3128) (@sebmarkbage)
• warn for getDOMNode, isMounted uses within render (Moar Warnings #3171)
• warn for Maps as children (Moar Warnings #3171)
• @providesModule react (@zpao) (needs syncup with flow, internal)
• --target option for jsx (@zpao)

Won't fix:

• Expose DOM component refs as the actual DOM nodes. (Monkey patch props, setProps, getDOMNode onto it as an upgrade path.)
• Warnings on using a DOM Component's ref's getDOMNode or props
• Fix the error utils guard. See ReactCompositeComponentError-test
• Deprecate setProps? What's the alternative?
• expose cloneWithProps on React proper (not actual cloneWithProps but the other one)
• Deprecate replaceState?

[sophiebits]

Deprecate keyed objects as children sometime?

[sebmarkbage]

ah yes.

[syranide]

@sebmarkbage getDOMNode() is not defined for React.Component, shouldn't it fall under "warn for one release and drop the next"? PS. Well... it is defined with a warning, but it doesn't actually return a function.

[sebmarkbage]

@syranide No, because React.Component didn't exist in previously releases. Not exposing it explicitly to prevent new code from relying on it.

[syranide]

@sebmarkbage Makes sense, the problem I see with it is this.refs.foobar.getDOMNode() will now fail "arbitrarily", depending on whether the component moved away from React.createClass or not. I realize these are fairly rare circumstances, but it did bite me. I.e, it is not only the component itself that is affected, but the consumer of the component as well.

[sebmarkbage]

@syranide That's why we also have React.findDOMNode(this.refs.foobar) which moves the responsibility out of the instance itself into a global escape hatch.

[syranide]

@sebmarkbage Yeah definitely, what I'm saying is just this breaks the "first warn then break" approach React seems to generally take. Now, doing npm update and also getting an updated component could mean your app instantly breaks telling you to use React.findDOMNode rather than warning and also working as it should for now. But I personally don't mind, I've already fixed all call-sites... just saying :)

[sebmarkbage]

This scenario doesn't break because of npm update but because you're also adding a new component which is why I think it is fine. :)

[andreypopp]

@syranide those who maintain React components and upgrade from React.createClass(...) to ES6 classes should bump major version then. Probably a good thing to be noted in 0.13 release announcement.