BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News React 0.14 Hits Release Candidate, Adding New Package Split, Refs Syntax, and More

React 0.14 Hits Release Candidate, Adding New Package Split, Refs Syntax, and More

This item in japanese

Bookmarks

Two months after entering beta, React 0.14 has reached release candidate status. React 0.14 will enforce separation of rendering and core concerns, make it easier to declare stateless components, and add new refs syntax.

React 0.14 will be split in two packages: react and react-dom. This decision is aimed at enforcing separation of concerns between React and the way it is rendered to the DOM. In keeping with this split, react will contain methods to create components, such as React.createElement, React.createClass, React.Component, React.PropTypes, React.children; react-dom, on the other hand, will contain rendering methods such as ReactDOM.render, ReactDOM.unmountComponentAtNode y ReactDOM.findDOMNode, while react-dom/server will provide support for server-side rendering of components.

What Facebook is trying to achieve through this split is twofold:

  • enabling the possibility for any developer to replace Facebook’s DOM rendering implementation with its own;
  • enabling the sharing of components across several rendering engines, such as react-dom, react-native, react-art, react-canvas, and react-three.

The second major change that React 0.14 introduces concerns refs to built-in DOM nodes. In React 0.13, if you wanted to access a node property from a ref, you had to write the following:

const nameNode = this.refs.name.getDOMNode();

In React 0.14, a ref to a built-in React node is the node itself, so you can more easily write:

const nameNode = this.refs.name;

This change, which affects built-in nodes but not user-defined nodes, has been dictated by the idea that the only useful thing that can be done with a ref node is accessing its DOM node. Contextually, .getDOMNode() has been deprecated and replaced with ReactDOM.findDOMNode. To help with the transition, Facebook has released a script called codemod.

Additionally, React 0.14 also tries to make it easier to declare stateless components that are composed of other components. This goes in line with what Facebook’s engineer stated when launching React 0.13:

Unfortunately, we will not launch any mixin support for ES6 classes in React. That would defeat the purpose of only using idiomatic JavaScript concepts. […] We will also start designing a new compositional API that will help make common tasks easier to do without mixins.

The new syntax in React 0.14 will allow to use props as an argument and return the element to render:

var Aquarium = (props) => {
  var fish = getFish(props.species);
  return <Tank>{fish}</Tank>;
};

React 0.14 also includes new deprecations, such as the mentioned this.getDOMNode(), setProps and replaceProps, etc. Furthermore, all React 0.13 deprecation warnings have been converted into errors.

React 0.14 can be installed from npm:

npm install --save react@0.14.0-rc1
npm install --save react-dom@0.14.0-rc1

Issues can be reported through React GitHUB repo bug tracker.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Your message is awaiting moderation. Thank you for participating in the discussion.

    It's a bit disappointing that the React team does not seem to focus (a bit of) their attention on integrating API calls in a more straightforward way with the React programming model.

    The only Pattern that the team came up with is Flux, but Flux is:
    a) way too heavy for simple scenarios (read-only) where the model can be populated (in a lazy way or not) with a hierarchy of API calls.

    b) Flux is lacking proper State semantics for more complex scenarios (forms) where the "state" of the UI is intimately related to the sequence of API calls, it's only action-oriented, when its model should be truly State-Action based. Flux forces all state decision to fit in the dispatcher implemented in a bespoke way which is not necessary the best choice.

    This architectural oversight limits the ability for API providers to create React-based API SDKs. I also know developers who prefer to stay with Angular.js just because of the difficulty of weaving API calls in the React programming model.

    I suggest using a couple of patterns:
    - ReaCall for simple scenarios. ReaCall decouples the API call(s) from the Model or the View.
    - SAM (State-Action-Model pattern), a TLA+ based pattern that introduces the concept of UI states to control which action can be applied (automatic actions or user triggered)

    SAM is a replacement for Flux.

  • SAM Link

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The SAM link I provided above points to a the small framework people can use to implement SAM.

    Here is an introduction to the pattern.

    Here is an example where the pattern is used to implement a "reliable API call" component.

    SAM is not specific to React and can be used in Java or JavaScript, client side or server-side.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT