React

Recent posts

React v0.13

March 10, 2015 by Ben Alpert

Today, we're happy to release React v0.13!

The most notable new feature is support for ES6 classes, which allows developers to have more flexibility when writing components. Our eventual goal is for ES6 classes to replace React.createClass completely, but until we have a replacement for current mixin use cases and support for class property initializers in the language, we don't plan to deprecate React.createClass.

At EmberConf and ng-conf last week, we were excited to see that Ember and Angular have been working on speed improvements and now both have performance comparable to React. We've always thought that performance isn't the most important reason to choose React, but we're still planning more optimizations to make React even faster.

Our planned optimizations require that ReactElement objects are immutable, which has always been a best practice when writing idiomatic React code. In this release, we've added runtime warnings that fire when props are changed or added between the time an element is created and when it's rendered. When migrating your code, you may want to use new React.cloneElement API (which is similar to React.addons.cloneWithProps but preserves key and ref and does not merge style or className automatically). For more information about our planned optimizations, see GitHub issues #3226, #3227, #3228.

The release is now available for download:

We've also published version 0.13.0 of the react and react-tools packages on npm and the react package on bower.

Changelog #

React Core #

Breaking Changes #

  • Deprecated patterns that warned in 0.12 no longer work: most prominently, calling component classes without using JSX or React.createElement and using non-component functions with JSX or createElement
  • Mutating props after an element is created is deprecated and will cause warnings in development mode; future versions of React will incorporate performance optimizations assuming that props aren't mutated
  • Static methods (defined in statics) are no longer autobound to the component class
  • ref resolution order has changed slightly such that a ref to a component is available immediately after its componentDidMount method is called; this change should be observable only if your component calls a parent component's callback within your componentDidMount, which is an anti-pattern and should be avoided regardless
  • Calls to setState in life-cycle methods are now always batched and therefore asynchronous. Previously the first call on the first mount was synchronous.
  • setState and forceUpdate on an unmounted component now warns instead of throwing. That avoids a possible race condition with Promises.
  • Access to most internal properties has been completely removed, including this._pendingState and this._rootNodeID.

New Features #

  • Support for using ES6 classes to build React components; see the v0.13.0 beta 1 notes for details.
  • Added new top-level API React.findDOMNode(component), which should be used in place of component.getDOMNode(). The base class for ES6-based components will not have getDOMNode. This change will enable some more patterns moving forward.
  • Added a new top-level API React.cloneElement(el, props) for making copies of React elements – see the v0.13 RC2 notes for more details.
  • New ref style, allowing a callback to be used in place of a name: <Photo ref={(c) => this._photo = c} /> allows you to reference the component with this._photo (as opposed to ref="photo" which gives this.refs.photo).
  • this.setState() can now take a function as the first argument for transactional state updates, such as this.setState((state, props) => ({count: state.count + 1})); – this means that you no longer need to use this._pendingState, which is now gone.
  • Support for iterators and immutable-js sequences as children.

Deprecations #

  • ComponentClass.type is deprecated. Just use ComponentClass (usually as element.type === ComponentClass).
  • Some methods that are available on createClass-based components are removed or deprecated from ES6 classes (getDOMNode, replaceState, isMounted, setProps, replaceProps).

React with Add-Ons #

New Features #

Deprecations #

  • React.addons.classSet is now deprecated. This functionality can be replaced with several freely available modules. classnames is one such module.
  • Calls to React.addons.cloneWithProps can be migrated to use React.cloneElement instead – make sure to merge style and className manually if desired.

React Tools #

Breaking Changes #

  • When transforming ES6 syntax, class methods are no longer enumerable by default, which requires Object.defineProperty; if you support browsers such as IE8, you can pass --target es3 to mirror the old behavior

New Features #

  • --target option is available on the jsx command, allowing users to specify and ECMAScript version to target.
    • es5 is the default.
    • es3 restores the previous default behavior. An additional transform is added here to ensure the use of reserved words as properties is safe (eg this.static will become this['static'] for IE8 compatibility).
  • The transform for the call spread operator has also been enabled.

JSX #

Breaking Changes #

  • A change was made to how some JSX was parsed, specifically around the use of > or } when inside an element. Previously it would be treated as a string but now it will be treated as a parse error. The jsx_orphaned_brackets_transformer package on npm can be used to find and fix potential issues in your JSX code.

Community Round-up #25

March 4, 2015 by Matthew Johnston

React 101 #

Interest in React has been exploding recently, so it's a good time to explore some great recent tutorials and videos that cover getting started.

Ryan Clark provides a great overview of the basics of React with the goal of building a really simple dropdown nav.

Formidable Labs and Seattle JS recently hosted a series of React, Flux, and Flow workshops, and the first part is available to watch online:

AEFlash writes up some best practices and tips to help you avoid potential pitfalls when developing with React.

Black Mutt Media takes us through their usage of React and Ruby to build an autocomplete field, and some of the pitfalls they encountered along the way.

Our own Sebastian Markbåge was on the Web Platform Podcast to have a chat about all aspects of React.

Community Additions #

Formidable Labs have been busy, as they've also just launched Radium, a React component that provides you with the ability to use inline styles instead of CSS. They're also looking for some help contributing to a Radium Bootstrap implementation.

Reactiflux.com is a new Slack community based around (you guessed it!) React, and Flux.

React Week is a week-long learning workshop, happening next week, for React, Flux, and other related technologies, run by Ryan Florence.

Babel-sublime is a new package which provides Sublime with language definitions for ES6 JavaScript with React JSX syntax extensions.

react-meteor, a package that replaces the default templating system of the Meteor platform with React, recently received a big update.

Rebuilding with React #

Rich Manalang from Atlassian explains why they rebuilt their HipChat web client from scratch using React, and how they're already using it to rebuild their native desktop clients.

Andrew Hillel of the BBC gives an excellent and thorough breakdown of the stack they used to rebuild their homepage, with React as an integral part of the front-end.

A team from New Zealand called Atomic is building web and mobile prototyping and design tools entirely in-browser, and as co-founder Darryl Gray says, “React.js “totally changed” the fact that browser performance often wasn’t good enough for complex tools like this.”.

Polarr have rebuilt their browser-based photo editor with React.

It's F8! #

F8 2015 is just around the corner, and you can sign up for the video streams in advance because we're sure to be covering all things React.

Meetups #

React v0.13 RC2

March 3, 2015 by Sebastian Markbåge

Thanks to everybody who has already been testing the release candidate. We've received some good feedback and as a result we're going to do a second release candidate. The changes are minimal. We haven't changed the behavior of any APIs we exposed in the previous release candidate. Here's a summary of the changes:

  • Introduced a new API (React.cloneElement, see below for details).
  • Fixed a bug related to validating propTypes when using the new React.addons.createFragment API.
  • Improved a couple warning messages.
  • Upgraded jstransform and esprima.

The release candidate is available for download:

We've also published version 0.13.0-rc2 of the react and react-tools packages on npm and the react package on bower.

React.cloneElement #

In React v0.13 RC2 we will introduce a new API, similar to React.addons.cloneWithProps, with this signature:

React.cloneElement(element, props, ...children);

Unlike cloneWithProps, this new function does not have any magic built-in behavior for merging style and className for the same reason we don't have that feature from transferPropsTo. Nobody is sure what exactly the complete list of magic things are, which makes it difficult to reason about the code and difficult to reuse when style has a different signature (e.g. in the upcoming React Native).

React.cloneElement is almost equivalent to:

<element.type {...element.props} {...props}>{children}</element.type>

However, unlike JSX and cloneWithProps, it also preserves refs. This means that if you get a child with a ref on it, you won't accidentally steal it from your ancestor. You will get the same ref attached to your new element.

One common pattern is to map over your children and add a new prop. There were many issues reported about cloneWithProps losing the ref, making it harder to reason about your code. Now following the same pattern with cloneElement will work as expected. For example:

var newChildren = React.Children.map(this.props.children, function(child) {
  return React.cloneElement(child, { foo: true })
});

Note: React.cloneElement(child, { ref: 'newRef' }) DOES override the ref so it is still not possible for two parents to have a ref to the same child, unless you use callback-refs.

This was a critical feature to get into React 0.13 since props are now immutable. The upgrade path is often to clone the element, but by doing so you might lose the ref. Therefore, we needed a nicer upgrade path here. As we were upgrading callsites at Facebook we realized that we needed this method. We got the same feedback from the community. Therefore we decided to make another RC before the final release to make sure we get this in.

We plan to eventually deprecate React.addons.cloneWithProps. We're not doing it yet, but this is a good opportunity to start thinking about your own uses and consider using React.cloneElement instead. We'll be sure to ship a release with deprecation notices before we actually remove it so no immediate action is necessary.

React v0.13 RC

February 24, 2015 by Paul O’Shannessy

Over the weekend we pushed out our first (and hopefully only) release candidate for React v0.13!

We've talked a little bit about the changes that are coming. The splashiest of these changes is support for ES6 Classes. You can read more about this in our beta announcement. We're really excited about this! Sebastian also posted earlier this morning about some of the other changes coming focused around ReactElement. The changes we've been working on there will hopefully enable lots of improvements to performance and developer experience.

The release candidate is available for download:

We've also published version 0.13.0-rc1 of the react and react-tools packages on npm and the react package on bower.

Changelog #

React Core #

Breaking Changes #

  • Mutating props after an element is created is deprecated and will cause warnings in development mode; future versions of React will incorporate performance optimizations assuming that props aren't mutated
  • Static methods (defined in statics) are no longer autobound to the component class
  • ref resolution order has changed slightly such that a ref to a component is available immediately after its componentDidMount method is called; this change should be observable only if your component calls a parent component's callback within your componentDidMount, which is an anti-pattern and should be avoided regardless
  • Calls to setState in life-cycle methods are now always batched and therefore asynchronous. Previously the first call on the first mount was synchronous.
  • setState and forceUpdate on an unmounted component now warns instead of throwing. That avoids a possible race condition with Promises.
  • Access to most internal properties has been completely removed, including this._pendingState and this._rootNodeID.

New Features #

  • Support for using ES6 classes to build React components; see the v0.13.0 beta 1 notes for details
  • Added new top-level API React.findDOMNode(component), which should be used in place of component.getDOMNode(). The base class for ES6-based components will not have getDOMNode. This change will enable some more patterns moving forward.
  • New ref style, allowing a callback to be used in place of a name: <Photo ref={(c) => this._photo = c} /> allows you to reference the component with this._photo (as opposed to ref="photo" which gives this.refs.photo)
  • this.setState() can now take a function as the first argument for transactional state updates, such as this.setState((state, props) => ({count: state.count + 1})); -- this means that you no longer need to use this._pendingState, which is now gone.
  • Support for iterators and immutable-js sequences as children

Deprecations #

  • ComponentClass.type is deprecated. Just use ComponentClass (usually as element.type === ComponentClass)
  • Some methods that are available on createClass-based components are removed or deprecated from ES6 classes (for example, getDOMNode, setProps, replaceState).

React with Add-Ons #

Deprecations #

  • React.addons.classSet is now deprecated. This functionality can be replaced with several freely available modules. classnames is one such module.

React Tools #

Breaking Changes #

  • When transforming ES6 syntax, class methods are no longer enumerable by default, which requires Object.defineProperty; if you support browsers such as IE8, you can pass --target es3 to mirror the old behavior

New Features #

  • --target option is available on the jsx command, allowing users to specify and ECMAScript version to target.
    • es5 is the default.
    • es3 restored the previous default behavior. An additional transform is added here to ensure the use of reserved words as properties is safe (eg this.static will become this['static'] for IE8 compatibility).
  • The transform for the call spread operator has also been enabled.

JSX #

Breaking Changes #

  • A change was made to how some JSX was parsed, specifically around the use of > or } when inside an element. Previously it would be treated as a string but now it will be treated as a parse error. We will be releasing a standalone executable to find and fix potential issues in your JSX code.

Streamlining React Elements

February 24, 2015 by Sebastian Markbåge

React v0.13 is right around the corner and so we wanted to discuss some upcoming changes to ReactElement. In particular, we added several warnings to some esoteric use cases of ReactElement. There are no runtime behavior changes for ReactElement - we're adding these warnings in the hope that we can change some behavior in v0.14 if the changes are valuable to the community.

If you use React in an idiomatic way, chances are, you’ll never see any of these warnings. In that case, you can skip this blog post. You can just enjoy the benefits! These changes will unlock simplified semantics, better error messages, stack traces and compiler optimizations!

Immutable Props #

In React 0.12, the props object was mutable. It allows you to do patterns like this:

var element = <Foo bar={false} />;
if (shouldUseFoo) {
  element.props.foo = 10;
  element.props.bar = true;
}

The problem is that we don’t have a convenient way to tell when you’re done mutating.

Problem: Mutating Props You Don’t Own #

If you mutate something, you destroy the original value. Therefore, there is nothing to diff against. Imagine something like this:

var element = this.props.child;
element.props.count = this.state.count;
return element;

You take a ReactElement through props.child and mutate its property before rendering it. If this component's state updates, this render function won't actually get a new ReactElement in props.child. It will be the same one. You're mutating the same props.

You could imagine that this would work. However, this disables the ability for any component to use shouldComponentUpdate. It looks like the component never changed because the previous value is always the same as the next one. Since the DOM layer does diffing, this pattern doesn't even work in this case. The change will never propagate down to the DOM except the first time.

Additionally, if this element is reused in other places or used to switch back and forth between two modes, then you have all kinds of weird race conditions.

It has always been broken to mutate the props of something passed into you. The problem is that we can’t warn you about this special case if you accidentally do this.

Problem: Too Late Validation #

In React 0.12, we do PropType validation very deep inside React during mounting. This means that by the time you get an error, the debugger stack is long gone. This makes it difficult to find complex issues during debugging. We have to do this since it is fairly common for extra props to be added between the call to React.createElement and the mount time. So the type is incomplete until then.

The static analysis in Flow is also impaired by this. There is no convenient place in the code where Flow can determine that the props are finalized.

Solution: Immutable Props #

Therefore, we would like to be able to freeze the element.props object so that it is immediately immutable at the JSX callsite (or createElement). In React 0.13 we will start warning you if you mutate element.props after this point.

You can generally refactor these pattern to simply use two different JSX calls:

if (shouldUseFoo) {
  return <Foo foo={10} bar={true} />;
} else {
  return <Foo bar={false} />;
}

However, if you really need to dynamically build up your props you can just use a temporary object and spread it into JSX:

var props = { bar: false };
if (shouldUseFoo) {
  props.foo = 10;
  props.bar = true;
}
return <Foo {...props} />;

It is still OK to do deep mutations of objects. E.g:

return <Foo nestedObject={this.state.myModel} />;

In this case it's still ok to mutate the myModel object in state. We recommend that you use fully immutable models. E.g. by using immutable-js. However, we realize that mutable models are still convenient in many cases. Therefore we're only considering shallow freezing the props object that belongs to the ReactElement itself. Not nested objects.

Solution: Early PropType Warnings #

We will also start warning you for PropTypes at the JSX or createElement callsite. This will help debugging as you’ll have the stack trace right there. Similarly, Flow also validates PropTypes at this callsite.

Note: There are valid patterns that clones a ReactElement and adds additional props to it. In that case these additional props needs to be optional.

var element1 = <Foo />; // extra prop is optional
var element2 = React.addons.cloneWithProps(element1, { extra: 'prop' });

Owner #

In React each child has both a "parent" and an “owner”. The owner is the component that created a ReactElement. I.e. the render method which contains the JSX or createElement callsite.

class Foo {
  render() {
    return <div><span /></div>;
  }
}

In this example, the owner of the span is Foo but the parent is the div.

There is also an undocumented feature called "context" that also relies on the concept of an “owner” to pass hidden props down the tree.

Problem: The Semantics are Opaque and Confusing #

The problem is that these are hidden artifacts attached to the ReactElement. In fact, you probably didn’t even know about it. It silently changes semantics. Take this for example:

var foo = <input className="foo" />;
class Component {
  render() {
    return bar ? <input className="bar" /> : foo;
  }
}

These two inputs have different owners, therefore React will not keep its state when the conditional switches. There is nothing in the code to indicate that. Similarly, if you use React.addons.cloneWithProps, the owner changes.

Problem: Timing Matters #

The owner is tracked by the currently executing stack. This means that the semantics of a ReactElement varies depending on when it is executed. Take this example:

class A {
  render() {
    return <B renderer={text => <span>{text}</span>} />;
  }
}
class B {
  render() {
    return this.props.renderer('foo');
  }
}

The owner of the span is actually B, not A because of the timing of the callback. This all adds complexity and suffers from similar problems as mutation.

Problem: It Couples JSX to React #

Have you wondered why JSX depends on React? Couldn’t the transpiler have that built-in to its runtime? The reason you need to have React.createElement in scope is because we depend on internal state of React to capture the current "owner". Without this, you wouldn’t need to have React in scope.

Solution: Make Context Parent-Based Instead of Owner-Based #

The first thing we’re doing is warning you if you’re using the "owner" feature in a way that relies on it propagating through owners. Instead, we’re planning on propagating it through parents to its children. In almost all cases, this shouldn’t matter. In fact, parent-based contexts is simply a superset.

Solution: Remove the Semantic Implications of Owner #

It turns out that there are very few cases where owners are actually important part of state-semantics. As a precaution, we’ll warn you if it turns out that the owner is important to determine state. In almost every case this shouldn’t matter. Unless you’re doing some weird optimizations, you shouldn’t see this warning.

Pending: Change the refs Semantics #

Refs are still based on "owner". We haven’t fully solved this special case just yet.

In 0.13 we introduced a new callback-refs API that doesn’t suffer from these problems but we’ll keep on a nice declarative alternative to the current semantics for refs. As always, we won’t deprecate something until we’re sure that you’ll have a nice upgrade path.

Keyed Objects as Maps #

In React 0.12, and earlier, you could use keyed objects to provide an external key to an element or a set. This pattern isn’t actually widely used. It shouldn’t be an issue for most of you.

<div>{ {a: <span />, b: <span />} }</div>

Problem: Relies on Enumeration Order #

The problem with this pattern is that it relies on enumeration order of objects. This is technically unspecified, even though implementations now agree to use insertion order. Except for the special case when numeric keys are used.

Problem: Using Objects as Maps is Bad #

It is generally accepted that using objects as maps screw up type systems, VM optimizations, compilers etc. It is much better to use a dedicated data structure like ES6 Maps.

More importantly, this can have important security implications. For example this has a potential security problem:

var children = {};
items.forEach(item => children[item.title] = <span />);
return <div>{children}</div>;

Imagine if item.title === '__proto__' for example.

Problem: Can’t be Differentiated from Arbitrary Objects #

Since these objects can have any keys with almost any value, we can’t differentiate them from a mistake. If you put some random object, we will try our best to traverse it and render it, instead of failing with a helpful warning. In fact, this is one of the few places where you can accidentally get an infinite loop in React.

To differentiate ReactElements from one of these objects, we have to tag them with _isReactElement. This is another issue preventing us from inlining ReactElements as simple object literals.

Solution: Just use an Array and key={…} #

Most of the time you can just use an array with keyed ReactElements.

var children = items.map(item => <span key={item.title} />);
<div>{children}</div>

Solution: React.addons.createFragment #

However, this is not always possible if you’re trying to add a prefix key to an unknown set (e.g. this.props.children). It is also not always the easiest upgrade path. Therefore, we are adding a helper to React.addons called createFragment(). This accepts a keyed object and returns an opaque type.

<div>{React.addons.createFragment({ a: <div />, b: this.props.children })}</div>

The exact signature of this kind of fragment will be determined later. It will likely be some kind of immutable sequence.

Note: This will still not be valid as the direct return value of render(). Unfortunately, they still need to be wrapped in a <div /> or some other element.

Compiler Optimizations: Unlocked! #

These changes also unlock several possible compiler optimizations for static content in React 0.14. These optimizations were previously only available to template-based frameworks. They will now also be possible for React code! Both for JSX and React.createElement/Factory*!

See these GitHub Issues for a deep dive into compiler optimizations:

* If you use the recommended pattern of explicit React.createFactory calls on the consumer side - since they are easily statically analyzed.

Rationale #

I thought that these changes were particularly important because the mere existence of these patterns means that even components that DON’T use these patterns have to pay the price. There are other problematic patterns such as mutating state, but they’re at least localized to a component subtree so they don’t harm the ecosystem.

As always, we’d love to hear your feedback and if you have any trouble upgrading, please let us know.