Umbrella 0.14

[sebmarkbage]

New Cool Features

• Pure Functions as Stateless Components https://github.com/reactjs/react-future/blob/master/01%20-%20Core/03%20-%20Stateless%20Functions.js Minimal implementation of stateless components #4587
• Allow arbitrary attributes on dashed tags i.e. custom elements. (@jimfb) see Support arbitrary attributes on elements with dashes in the tag name.  #3067
• Fix the error utils guard. See ReactCompositeComponentError-test (Mostly affects FB internals but ties into better error handling in general.) (@sebmarkbage)
• Add trusted key for ReactElements? [RFC] Trusted sources for React elements. #3583 / Use a Symbol to tag every ReactElement #4832 (@leebyron / @sebmarkbage)

Package changes

• Build Separate Packages for react isomorphic, dom and server rendering [Still need to handle https://github.com/How to use Perf and TestUtils #4279 ] (@zpao)
• Deprecate the dom renderer in the react package. Replace with separate package. Warnings if used. (@zpao)
• Ship all React addons as separate packages. Remove from react repo. (Possibly kill already deprecated ones like classSet) Build with warnings if existing package is used? (@zpao)
• End-of-life of react-tools. Clean up legacy in react-native and in the react repo (@zpao)
  • Figure out react-native needs for @providesModule React (@amasad, @sebmarkbage)
• Ship index.ios.js with react so that react-native components can immediately start using the react package. (@sebmarkbage)
• Decouple dependencies between React DOM and React Isomorphic, except for currentOwner which React DOM still needs to set on React Isomorphic. (@sebmarkbage) See comment in Reorganize Src Directory for Isomorphic React Package #3866
• Browser build for ReactDOM (@zpao)

Kill Deprecations from 0.13

• Object.freeze props in createElement in DEV, remove old props mutation warnings. (@jimfb) see Freeze ReactElement.props in dev mode #4172.
• Make React.addons.createFragment return a toArray from objects (@spicyj)
• Kill _isReactElement (@spicyj)
• Kill ComponentClass.type (@jimfb) see Kill .type (was deprecated in 0.13, to be removed in 0.14) #4009
• Clean up the remaining owner/context stuff (@jimfb)

New Deprecations

• Deprecate setProps/replaceProps and replace with external ReactRenderer package, don't forget to include replaceProps in the renderer API and ship the package. (@jimfb, see Make events propagate through shadow DOMs.  #4150)
• Deprecate getDOMNode (replaced with React.findDOMNode) (@spicyj)
• Expose DOM component refs as the actual DOM nodes. Expose refs on DOM Components as Direct Handles to the actual DOM Node #3223 (@spicyj)
• Warnings on using a DOM Component's ref's getDOMNode or props Expose refs on DOM Components as Direct Handles to the actual DOM Node #3223 (@spicyj)
• Clean up remainders of context (@jimfb)

Probably not

• Deprecate replaceState? Deprecate replaceState #3236 Needs Immutable.js solution. (@sebmarkbage)
• Deprecate isMounted? Docs - Recommendations for isMounted() alternative #3417 Needs Promise solution. (@sebmarkbage)
• Detect event target through event.path if available. E.g. in shadow DOM. (@jimfb) see Make events propagate through shadow DOMs.  #4150. (Disabled in Disable event.path handling #4585)

[syranide]

Expose DOM component refs as the actual DOM nodes. (Monkey patch props, setProps, getDOMNode onto it as an upgrade path.)

Hmm, this seems kind of weird to me, especially in-light of ReactDOMInput, etc unless we intend to discontinue them as (recommended) addons or w/e. I would think the preferable direction would be away from direct DOM interaction. Going off on a tangent here; including in some sense basically discontinuing the use of DOM events in-favor of passing a ReactEvent or even just the new value to onChange callbacks (which perhaps only really makes sense as an addon perhaps).

[sebmarkbage]

Breaking this out into a separate discussion in #3223. Not sure what you mean by "passing a ReactEvent"...? Anyway we

[kharin]

Deprecate replaceState? What about things like: https://github.com/facebook/immutable-js/wiki/Immutable-as-React-state

[sebmarkbage]

@kharin As that page mentions, it is safer to use a nested state property anyway.

We could build native support so that this would work:

  getInitialState() {
    return Immutable.Record({count:0})();
  },
  handleClick() {
    this.setState(this.state.update('count', v => v + 1));
  },

We would merge it in React. We would likely only support the Record type, and not Maps though. It would still have problems with mixins.

[kharin]

@sebmarkbage the Record trick looks great! I'm not sure what would be performance implications, though. If React were to merge it as usual it's likely to be slower since V8 de-ops property setters.

Just wanted to know you thoughts on the practice. So, if I understood correctly, using replaceState() (in this use-case) is discouraged until React lends some sort of native support?

[sebmarkbage]

That's right. I added a spin-off Issue for discussion. #3236

[busticated]

I wouldn't be surprised if i'm just coming to this conversation without the proper context, etc (still somewhat new to react :) but perhaps this will be helpful to others in my position. I have two basic questions:

1. re: Expose refs on DOM Components as Direct Handles to the actual DOM Node #3223 - today i use refs to get a handle on a component - sometimes to call .getDOMNode(), sometimes just to call some method on the instance itself. while i realize this might not be the ideal, it's super-handy. is the plan to prevent this kind of thing or will it continue to be supported in a different way?

2. re: Deprecate setProps - i currently have a top-level app component which receives all of its data / state via .setProps() & .setState(). for this use-case, is the aim to get folks to move over to using .render() directly for prop updates? (i realize the docs suggest this approach) will we still have access to the component instance / .setState() ?

thanks for a great lib :)

[sophiebits]

1. Yeah, refs to components you define yourself will still work the same way – Expose refs on DOM Components as Direct Handles to the actual DOM Node #3223 talks just about what happens if you take a ref to a node directly, like <img ref="photo" />. We're looking at making this.refs.photo be the img node directly in that case.

2. Yeah, re-calling React.render at the top level is the preferred solution. No plans to change how the instance is returned, though you should treat state as private to a component and only call setState on yourself (i.e., this.setState) and never on another instance you have a handle to. You can expose a custom setter method, but in most cases it's better to just pass the new values via props.

[busticated]

@spicyj great - thanks!

[staltz]

Stateless Functions https://github.com/reactjs/react-future/blob/master/01%20-%20Core/03%20-%20Stateless%20Functions.js (who wants to do it? should be easyish.)

Naming nitpicking: "Stateless function" is redundant. It's like saying "Wingless dog". "Functions as stateless components" is more correct.

[sophiebits]

Well, React supports winged birds, wingless birds, and (soon) wingless dogs. I'll change the name in the checklist above though.