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.

Introducing Relay and GraphQL

February 20, 2015 by Greg Hurrell


Data fetching for React applications #

There's more to building an application than creating a user interface. Data fetching is still a tricky problem, especially as applications become more complicated. At React.js Conf we announced two projects we've created at Facebook to make data fetching simple for developers, even as a product grows to include dozens of contributors and the application becomes as complex as Facebook itself.

The two projects — Relay and GraphQL — have been in use in production at Facebook for some time, and we're excited to be bringing them to the world as open source in the future. In the meantime, we wanted to share some additional information about the projects here.

What is Relay? #

Relay is a new framework from Facebook that provides data-fetching functionality for React applications. It was announced at React.js Conf (January 2015).

Each component specifies its own data dependencies declaratively using a query language called GraphQL. The data is made available to the component via properties on this.props.

Developers compose these React components naturally, and Relay takes care of composing the data queries into efficient batches, providing each component with exactly the data that it requested (and no more), updating those components when the data changes, and maintaining a client-side store (cache) of all data.

What is GraphQL? #

GraphQL is a data querying language designed to describe the complex, nested data dependencies of modern applications. It's been in production use in Facebook's native apps for several years.

On the server, we configure the GraphQL system to map queries to underlying data-fetching code. This configuration layer allows GraphQL to work with arbitrary underlying storage mechanisms. Relay uses GraphQL as its query language, but it is not tied to a specific implementation of GraphQL.

The value proposition #

Relay was born out of our experiences building large applications at Facebook. Our overarching goal is to enable developers to create correct, high-performance applications in a straightforward and obvious way. The design enables even large teams to make changes with a high degree of isolation and confidence. Fetching data is hard, dealing with ever-changing data is hard, and performance is hard. Relay aims to reduce these problems to simple ones, moving the tricky bits into the framework and freeing you to concentrate on building your application.

By co-locating the queries with the view code, the developer can reason about what a component is doing by looking at it in isolation; it's not necessary to consider the context where the component was rendered in order to understand it. Components can be moved anywhere in a render hierarchy without having to apply a cascade of modifications to parent components or to the server code which prepares the data payload.

Co-location leads developers to fall into the "pit of success", because they get exactly the data they asked for and the data they asked for is explicitly defined right next to where it is used. This means that performance becomes the default (it becomes much harder to accidentally over-fetch), and components are more robust (under-fetching is also less likely for the same reason, so components won't try to render missing data and blow up at runtime).

Relay provides a predictable environment for developers by maintaining an invariant: a component won't be rendered until all the data it requested is available. Additionally, queries are defined statically (ie. we can extract queries from a component tree before rendering) and the GraphQL schema provides an authoritative description of what queries are valid, so we can validate queries early and fail fast when the developer makes a mistake.

Only the fields of an object that a component explicitly asks for will be accessible to that component, even if other fields are known and cached in the store (because another component requested them). This makes it impossible for implicit data dependency bugs to exist latently in the system.

By handling all data-fetching via a single abstraction, we're able to handle a bunch of things that would otherwise have to be dealt with repeatedly and pervasively across the application:

  • Performance: All queries flow through the framework code, where things that would otherwise be inefficient, repeated query patterns get automatically collapsed and batched into efficient, minimal queries. Likewise, the framework knows which data have been previously requested, or for which requests are currently "in flight", so queries can be automatically de-duplicated and the minimal queries can be produced.
  • Subscriptions: All data flows into a single store, and all reads from the store are via the framework. This means the framework knows which components care about which data and which should be re-rendered when data changes; components never have to set up individual subscriptions.
  • Common patterns: We can make common patterns easy. Pagination is the example that Jing gave at the conference: if you have 10 records initially, getting the next page just means declaring you want 15 records in total, and the framework automatically constructs the minimal query to grab the delta between what you have and what you need, requests it, and re-renders your view when the data become available.
  • Simplified server implementation: Rather than having a proliferation of end-points (per action, per route), a single GraphQL endpoint can serve as a facade for any number of underlying resources.
  • Uniform mutations: There is one consistent pattern for performing mutations (writes), and it is conceptually baked into the data querying model itself. You can think of a mutation as a query with side-effects: you provide some parameters that describe the change to be made (eg. attaching a comment to a record) and a query that specifies the data you'll need to update your view of the world after the mutation completes (eg. the comment count on the record), and the data flows through the system using the normal flow. We can do an immediate "optimistic" update on the client (ie. update the view under the assumption that the write will succeed), and finally commit it, retry it or roll it back in the event of an error when the server payload comes back.

How does it relate to Flux? #

In some ways Relay is inspired by Flux, but the mental model is much simpler. Instead of multiple stores, there is one central store that caches all GraphQL data. Instead of explicit subscriptions, the framework itself can track which data each component requests, and which components should be updated whenever the data change. Instead of actions, modifications take the form of mutations.

At Facebook, we have apps built entirely using Flux, entirely using Relay, or with both. One pattern we see emerging is letting Relay manage the bulk of the data flow for an application, but using Flux stores on the side to handle a subset of application state.

Open source plans #

We're working very hard right now on getting both GraphQL (a spec, and a reference implementation) and Relay ready for public release (no specific dates yet, but we are super excited about getting these out there).

In the meantime, we'll be providing more and more information in the form of blog posts (and in other channels). As we get closer to the open source release, you can expect more concrete details, syntax and API descriptions and more.

Watch this space!

React.js Conf Round-up 2015

February 18, 2015 by Steven Luscher


It was a privilege to welcome the React community to Facebook HQ on January 28–29 for the first-ever React.js Conf, and a pleasure to be be able to unveil three new technologies that we've been using internally at Facebook for some time: GraphQL, Relay, and React Native.

The talks #

Keynote #

Tom Occhino opened with a history of how React came to be, before announcing Facebook’s answer to a long-looming what-if question: what if we could use React to target something other than the DOM?

Tweaking in real time #

Brenton Simpson showed us how eBay brings Bret Victor’s feedback loop to your favorite editor using Webpack, react-hot-loader, and Ambidex.

Abstract Syntax Trees #

Gurdas Nijor showed us how we can leverage some conventions of React to perform source code transformations that unlock an inspirational set of use cases.

Relay and GraphQL #

Daniel Schafer and Jing Chen showed us how Facebook approaches data fetching with React, giving us an early peek at the forthcoming duo of Relay and GraphQL.

Channels #

James Long explores what might happen if we introduce channels, a new style of coordinating actions, to React.

React Router #

Michael Jackson reminded us that URLs should be part of our design process, and showed us how react-router can help to manage the transitions between them.

Full-stack Flux #

Pete Hunt showed us how a Flux approach can help us scale actions and questions on the backend in addition to the frontend.

High-performance #

Jason Bonta showed us how complex user interfaces can get, and how his team keeps them performant as they scale. He also had the pleasure of open-sourcing his team’s work on FixedDataTable.

FormatJS and react-intl #

Eric Ferraiuolo showed how you can bring your app to a worldwide audience using a series of polyfills and emerging ECMAScript APIs.

Hype! #

Ryan Florence showed us how easy it is to transition from a career selling life insurance, to a burgeoning one as a software developer. All you have to do is to learn how to say “yes.”

React Native #

Christopher Chedeau showed us how to bring the developer experience of working with React on the web to native app development, using React Native.

Components #

Andrew Rota explained how React and Web Components can work together, and how to avoid some common pitfalls.

Immutability #

Lee Byron led a master-class on persistent immutable data structures, showing us the world of possibility that they can unlock for your software, and perhaps Javascript in general.

Beyond the DOM #

Jafar Husain told us a story about how Netflix was able to push React into places where the DOM could not go.

Data Visualization #

Zach Nation showed us how we can produce visualizations from over 45 million data points without breaking a sweat.

React Refracted #

David Nolen gave us a view of React from a non-JavaScript perspective, challenging some common intuition along the way.

Flux Panel #

Bill Fisher coordinated a Flux panel together with Michael Ridgway, Spike Brehm, Andres Suarez, Jing Chen, Ian Obermiller, and Kyle Davis.

Component communication #

Bonnie Eisenman led us through the ‘adapter’ approach to inter-component communication taken by her team at Codecademy.

Flow and TypeScript #

James Brantly demonstrated how we can reap the benefits of static typing using both Flow and TypeScript.

Core Team Q&A #

Tom Occhino, Ben Alpert, Lee Byron, Christopher Chedeau, Sebastian Markbåge, Jing Chen, and Dan Schafer closed the conference with a Q&A session.

Reactions #

The conference is over, but the conversation has just begun.

Mihai Parparita detailed his efforts to hack his way to a React.js Conf ticket; James Long blogged about his first encounter with React Native; Eric Florenzano talked about how he perceives the impact of Relay, GraphQL, and React Native on software development; Margaret Staples blogged about her experience of being on-campus at Facebook HQ; Jeff Barczewski tied his experience of attending the conference up with a bow in this blog post filled with photos, videos, and links; Kevin Old left us with his takeaways; Paul Wittmann found React Native freshly on his radar; and finally, undeterred by not being able to attend the conference in person, Justin Ball summarized it from afar.

And, in case you missed a session, you can borrow Michael Chan’s drawings, Mihai Parparita’s summary, or Shaohua Zhou’s day 1 / day 2 notes.

All proceeds from React.js Conf 2015 were donated to the wonderful programs at code.org. These programs aim to increase access to the field of computer science by underrepresented members of our community. Watch this video to learn more.

React v0.13.0 Beta 1

January 27, 2015 by Sebastian Markbåge


React 0.13 has a lot of nice features but there is one particular feature that I'm really excited about. I couldn't wait for React.js Conf to start tomorrow morning.

Maybe you're like me and staying up late excited about the conference, or maybe you weren't one of the lucky ones to get a ticket. Either way I figured I'd give you all something to play with until then.

We just published a beta version of React v0.13.0 to npm! You can install it with npm install react@0.13.0-beta.1. Since this is a pre-release, we don't have proper release notes ready.

So what is that one feature I'm so excited about that I just couldn't wait to share?

Plain JavaScript Classes!! #

JavaScript originally didn't have a built-in class system. Every popular framework built their own, and so did we. This means that you have a learn slightly different semantics for each framework.

We figured that we're not in the business of designing a class system. We just want to use whatever is the idiomatic JavaScript way of creating classes.

In React 0.13.0 you no longer need to use React.createClass to create React components. If you have a transpiler you can use ES6 classes today. You can use the transpiler we ship with react-tools by making use of the harmony option: jsx --harmony.

ES6 Classes #

class HelloMessage extends React.Component {
  render() {
    return <div>Hello {this.props.name}</div>;
  }
}

React.render(<HelloMessage name="Sebastian" />, mountNode);

The API is mostly what you would expect, with the exception for getInitialState. We figured that the idiomatic way to specify class state is to just use a simple instance property. Likewise getDefaultProps and propTypes are really just properties on the constructor.

export class Counter extends React.Component {
  constructor(props) {
    super(props);
    this.state = {count: props.initialCount};
  }
  tick() {
    this.setState({count: this.state.count + 1});
  }
  render() {
    return (
      <div onClick={this.tick.bind(this)}>
        Clicks: {this.state.count}
      </div>
    );
  }
}
Counter.propTypes = { initialCount: React.PropTypes.number };
Counter.defaultProps = { initialCount: 0 };

ES7+ Property Initializers #

Wait, assigning to properties seems like a very imperative way of defining classes! You're right, however, we designed it this way because it's idiomatic. We fully expect a more declarative syntax for property initialization to arrive in future version of JavaScript. It might look something like this:

// Future Version
export class Counter extends React.Component {
  static propTypes = { initialCount: React.PropTypes.number };
  static defaultProps = { initialCount: 0 };
  state = { count: this.props.initialCount };
  tick() {
    this.setState({ count: this.state.count + 1 });
  }
  render() {
    return (
      <div onClick={this.tick.bind(this)}>
        Clicks: {this.state.count}
      </div>
    );
  }
}

This was inspired by TypeScript's property initializers.

Autobinding #

React.createClass has a built-in magic feature that bound all methods to this automatically for you. This can be a little confusing for JavaScript developers that are not used to this feature in other classes, or it can be confusing when they move from React to other classes.

Therefore we decided not to have this built-in into React's class model. You can still explicitly prebind methods in your constructor if you want.

class Counter extends React.Component {
  constructor() {
    super();
    this.tick = this.tick.bind(this);
  }
  tick() {
    ...
  }
  ...
}

However, when we have the future property initializers, there is a neat trick that you can use to accomplish this syntactically:

class Counter extends React.Component {
  tick = () => {
    ...
  }
  ...
}

Mixins #

Unfortunately, we will not launch any mixin support for ES6 classes in React. That would defeat the purpose of only using idiomatic JavaScript concepts.

There is no standard and universal way to define mixins in JavaScript. In fact, several features to support mixins were dropped from ES6 today. There are a lot of libraries with different semantics. We think that there should be one way of defining mixins that you can use for any JavaScript class. React just making another doesn't help that effort.

Therefore, we will keep working with the larger JS community to create a standard for mixins. We will also start designing a new compositional API that will help make common tasks easier to do without mixins. E.g. first-class subscriptions to any kind of Flux store.

Luckily, if you want to keep using mixins, you can just keep using React.createClass.

Note:

The classic React.createClass style of creating classes will continue to work just fine.

Other Languages! #

Since these classes are just plain old JavaScript classes, you can use other languages that compile to JavaScript classes, such as TypeScript.

You can also use CoffeeScript classes:

div = React.createFactory 'div'

class Counter extends React.Component
  @propTypes =
    initialCount: React.PropTypes.number
  @defaultProps =
    initialCount: 0
  constructor: ->
    @state =
      count: @props.initialCount
  tick: =>
    @setState count: @state.count + 1
  render: ->
    div(onClick: @tick, 'Clicks: ', @state.count)

You can even use the old ES3 module pattern if you want:

function MyComponent(initialProps) {
  return {
    state: { value: initialProps.initialValue },
    render: function() {
      return <span className={this.state.value} />
    }
  };
}