After a couple weeks of having more people use v0.14, we're ready to ship a patch release addressing a few issues. Thanks to everybody who has reported issues and written patches!

The release is now available for download:

• React
  Dev build with warnings: https://fb.me/react-0.14.1.js
  Minified build for production: https://fb.me/react-0.14.1.min.js
  
• React with Add-Ons
  Dev build with warnings: https://fb.me/react-with-addons-0.14.1.js
  Minified build for production: https://fb.me/react-with-addons-0.14.1.min.js
  
• React DOM (include React in the page before React DOM)
  Dev build with warnings: https://fb.me/react-dom-0.14.1.js
  Minified build for production: https://fb.me/react-dom-0.14.1.min.js
  

We've also published version 0.14.1 of the react, react-dom, and addons packages on npm and the react package on bower.

Changelog #

React DOM #

• Fixed bug where events wouldn't fire in old browsers when using React in development mode
• Fixed bug preventing use of dangerouslySetInnerHTML with Closure Compiler Advanced mode
• Added support for srcLang, default, and kind attributes for <track> elements
• Added support for color attribute
• Ensured legacy .props access on DOM nodes is updated on re-renders

React TestUtils Add-on #

• Fixed scryRenderedDOMComponentsWithClass so it works with SVG

React CSSTransitionGroup Add-on #

• Fix bug preventing 0 to be used as a timeout value

React on Bower #

• Added react-dom.js to main to improve compatibility with tooling

TL;DR: Slack decided that Reactiflux had too many members and disabled new invites. Reactiflux is moving to Discord. Join us: http://join.reactiflux.com

What happened with Slack? #

A few weeks ago, Reactiflux reached 7,500 members on Slack. Shortly after, Slack decided we were too big and disabled invites. There was no way for new users to join. Many of us were sad and upset. We loved Slack. Our community was built around it.

We reached out to Slack several times, but their decision was firm. Our large community caused performance issues. Slack wants to focus on building a great product for teams, not necessarily large open communities. Losing focus and building for too many use cases always leads to product bloat, and eventually a decrease in quality.

So… why Discord? #

After a long and thorough debate, Discord quickly emerged as the most promising service. After just a few days, 400 members had joined the Discord server, and many already loved it.

Easiest to join #

Discord is the easiest platform to join. New users can immediately join our conversations without having to create an account. All they need to do is provide a name. No permission granting, no password, no email confirmation.

This is critically useful for us, and will make Reactiflux even more open and accessible.

Great apps #

Out of all of the services we’ve tried, Discord’s apps are by far the most polished. They are well designed, easy to use, and surprisingly fast. In addition to the web app, they have mobile apps on both iOS and Android as well as desktop apps for OS X and Windows, with Linux support coming soon.

Their desktop apps are built with React and Electron, and their iOS app is built with React Native.

Moderation tools #

So far, we’ve been fortunate not to have to deal with spammers and trolls. As our community continues to grow, that might change. Unsurprisingly, Discord is the only app we’ve seen with legitimate moderation tools. It was built for gaming communities, after all.

Great multiple Server support #

Your Discord account works with every Discord server, which is the equivalent of a Slack team. You don’t need to create a new account every time you join a new team. You can join new servers in one click, and it’s very easy to switch between them. Discord messages also work across servers, so your personal conversations are not scoped to a single server.

Instead of having one huge, crowded Reactiflux server, we can branch off closely related channels into sub-servers. Communities will start overlapping, and it will be easy to interact with non-Reactiflux channels.

It’s hosted #

Self-hosted apps require maintenance. We’re all busy, and we can barely find the time to keep our landing page up to date and running smoothly. More than anything, we need a stable platform, and we don’t have the resources to guarantee that right now.

It’s a much safer bet to offload the hosting to Discord, who is already keeping the lights on for all their users.

We like the team #

And they seem to like us back. They are excited for us to join them, and they’ve been very responsive to our feedback and suggestions.

They implemented code syntax highlighting just a few days after we told them we needed it.

Discord’s team has already built a solid suite of apps, and they have shown us how much they care about their users. We’re excited to see how they will continue to improve their product.

And what’s the catch? #

Choosing the best chat service is subjective. There are a million reasons why Discord might be a terrible idea. Here are the ones that we’re most worried about:

Difficult channel management #

Channel management seems to be the biggest issue. There is no way to opt out of channels; you can only mute them. And you can only mute channels one by one. There is no way to star channels, and channels can only be sorted on the server level. Each user will see the list of channels in the same order.

As the number of channels grow, it will be challenging to keep things in order. Branching off sub-servers will help, and we will keep an easily accessible directory of channels across our main server and all of the sub-servers.

We can build simple tools to make channel lookup easier, and the Discord team is working on improvements that should make this more manageable.

No Search #

Lack of search is clearly a bummer, but Discord is working on it. Search is coming!

Firewall #

A couple of users aren’t able to access Discord at work since other corporate filters classify it as a gaming application. This sucks, but it seems to be a rare case. So far, it seems only to affect 0.6% of our current community (3/500).

We hope that these users can get Discord's domains whitelisted, and we’ll try to find a solution if this is a widespread issue. The Discord team is aware of the issue as well.

Is Discord going to disappear tomorrow? #

Probably not tomorrow. They have 14 people full time, and they’ve raised money from some of the best investors in Silicon Valley, including Benchmark and Accel.

By focusing on gaming communities, Discord has differentiated itself from the many other communication apps. Discord is well received and has a rapidly growing user base. They plan to keep their basic offerings free for unlimited users and hope to make money with premium offerings (themes, add-ons, content, and more).

Join us! #

More than 500 of us have already migrated to the new Reactiflux. Join us, we're one click away: http://join.reactiflux.com

Note: Jordan Hawker’s thorough research made our decision a lot easier.

We’re happy to announce the release of React 0.14 today! This release has a few major changes, primarily designed to simplify the code you write every day and to better support environments like React Native.

If you tried the release candidate, thank you – your support is invaluable and we've fixed a few bugs that you reported.

As with all of our releases, we consider this version to be stable enough to use in production and recommend that you upgrade in order to take advantage of our latest improvements.

Upgrade Guide #

Like always, we have a few breaking changes in this release. We know changes can be painful (the Facebook codebase has over 15,000 React components), so we always try to make changes gradually in order to minimize the pain.

If your code is free of warnings when running under React 0.13, upgrading should be easy. We have two new small breaking changes that didn't give a warning in 0.13 (see below). Every new change in 0.14, including the major changes below, is introduced with a runtime warning and will work as before until 0.15, so you don't have to worry about your app breaking with this upgrade.

For the two major changes which require significant code changes, we've included codemod scripts to help you upgrade your code automatically.

See the changelog below for more details.

Installation #

We recommend using React from npm and using a tool like browserify or webpack to build your code into a single bundle. To install the two packages:

• npm install --save react react-dom

Remember that by default, React runs extra checks and provides helpful warnings in development mode. When deploying your app, set the NODE_ENV environment variable to production to use the production build of React which does not include the development warnings and runs significantly faster.

If you can’t use npm yet, we provide pre-built browser builds for your convenience, which are also available in the react package on bower.

• React
  Dev build with warnings: https://fb.me/react-0.14.0.js
  Minified build for production: https://fb.me/react-0.14.0.min.js
  
• React with Add-Ons
  Dev build with warnings: https://fb.me/react-with-addons-0.14.0.js
  Minified build for production: https://fb.me/react-with-addons-0.14.0.min.js
  
• React DOM (include React in the page before React DOM)
  Dev build with warnings: https://fb.me/react-dom-0.14.0.js
  Minified build for production: https://fb.me/react-dom-0.14.0.min.js
  

Changelog #

Major changes #

• Two Packages: React and React DOM #

  As we look at packages like react-native, react-art, react-canvas, and react-three, it has become clear that the beauty and essence of React has nothing to do with browsers or the DOM.

  To make this more clear and to make it easier to build more environments that React can render to, we’re splitting the main react package into two: react and react-dom. This paves the way to writing components that can be shared between the web version of React and React Native. We don’t expect all the code in an app to be shared, but we want to be able to share the components that do behave the same across platforms.

  The react package contains React.createElement, .createClass, .Component, .PropTypes, .Children, and the other helpers related to elements and component classes. We think of these as the isomorphic or universal helpers that you need to build components.

  The react-dom package has ReactDOM.render, .unmountComponentAtNode, and .findDOMNode. In react-dom/server we have server-side rendering support with ReactDOMServer.renderToString and .renderToStaticMarkup.

  var React = require('react');
  var ReactDOM = require('react-dom');
  
  var MyComponent = React.createClass({
    render: function() {
      return <div>Hello World</div>;
    }
  });
  
  ReactDOM.render(<MyComponent />, node);
  

  The old names will continue to work with a warning until 0.15 is released, and we’ve published the automated codemod script we used at Facebook to help you with this transition.

  The add-ons have moved to separate packages as well:

  • react-addons-clone-with-props
  • react-addons-create-fragment
  • react-addons-css-transition-group
  • react-addons-linked-state-mixin
  • react-addons-perf
  • react-addons-pure-render-mixin
  • react-addons-shallow-compare
  • react-addons-test-utils
  • react-addons-transition-group
  • react-addons-update
  • ReactDOM.unstable_batchedUpdates in react-dom.

  For now, please use matching versions of react and react-dom (and the add-ons, if you use them) in your apps to avoid versioning problems.

• DOM node refs #

  The other big change we’re making in this release is exposing refs to DOM components as the DOM node itself. That means: we looked at what you can do with a ref to a React DOM component and realized that the only useful thing you can do with it is call this.refs.giraffe.getDOMNode() to get the underlying DOM node. Starting with this release, this.refs.giraffe is the actual DOM node. Note that refs to custom (user-defined) components work exactly as before; only the built-in DOM components are affected by this change.

  var Zoo = React.createClass({
    render: function() {
      return <div>Giraffe name: <input ref="giraffe" /></div>;
    },
    showName: function() {
      // Previously: var input = this.refs.giraffe.getDOMNode();
      var input = this.refs.giraffe;
      alert(input.value);
    }
  });
  

  This change also applies to the return result of ReactDOM.render when passing a DOM node as the top component. As with refs, this change does not affect custom components.

  With this change, we’re deprecating .getDOMNode() and replacing it with ReactDOM.findDOMNode (see below). If your components are currently using .getDOMNode(), they will continue to work with a warning until 0.15.

• Stateless functional components #

  In idiomatic React code, most of the components you write will be stateless, simply composing other components. We’re introducing a new, simpler syntax for these components where you can take props as an argument and return the element you want to render:

  // A functional component using an ES2015 (ES6) arrow function:
  var Aquarium = (props) => {
    var fish = getFish(props.species);
    return <Tank>{fish}</Tank>;
  };
  
  // Or with destructuring and an implicit return, simply:
  var Aquarium = ({species}) => (
    <Tank>
      {getFish(species)}
    </Tank>
  );
  
  // Then use: <Aquarium species="rainbowfish" />
  

  These components behave just like a React class with only a render method defined. Since no component instance is created for a functional component, any ref added to one will evaluate to null. Functional components do not have lifecycle methods, but you can set .propTypes and .defaultProps as properties on the function.

  This pattern is designed to encourage the creation of these simple components that should comprise large portions of your apps. In the future, we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations.

• Deprecation of react-tools #

  The react-tools package and JSXTransformer.js browser file have been deprecated. You can continue using version 0.13.3 of both, but we no longer support them and recommend migrating to Babel, which has built-in support for React and JSX.

• Compiler optimizations #

  React now supports two compiler optimizations that can be enabled in Babel 5.8.24 and newer. Both of these transforms should be enabled only in production (e.g., just before minifying your code) because although they improve runtime performance, they make warning messages more cryptic and skip important checks that happen in development mode, including propTypes.

  Inlining React elements: The optimisation.react.inlineElements transform converts JSX elements to object literals like {type: 'div', props: ...} instead of calls to React.createElement.

  Constant hoisting for React elements: The optimisation.react.constantElements transform hoists element creation to the top level for subtrees that are fully static, which reduces calls to React.createElement and the resulting allocations. More importantly, it tells React that the subtree hasn’t changed so React can completely skip it when reconciling.

Breaking changes #

In almost all cases, we change our APIs gradually and warn for at least one release to give you time to clean up your code. These two breaking changes did not have a warning in 0.13 but should be easy to find and clean up:

• React.initializeTouchEvents is no longer necessary and has been removed completely. Touch events now work automatically.
• Add-Ons: Due to the DOM node refs change mentioned above, TestUtils.findAllInRenderedTree and related helpers are no longer able to take a DOM component, only a custom component.

These three breaking changes had a warning in 0.13, so you shouldn’t have to do anything if your code is already free of warnings:

• The props object is now frozen, so mutating props after creating a component element is no longer supported. In most cases, React.cloneElement should be used instead. This change makes your components easier to reason about and enables the compiler optimizations mentioned above.
• Plain objects are no longer supported as React children; arrays should be used instead. You can use the createFragment helper to migrate, which now returns an array.
• Add-Ons: classSet has been removed. Use classnames instead.

New deprecations, introduced with a warning #

Each of these changes will continue to work as before with a new warning until the release of 0.15 so you can upgrade your code gradually.

• Due to the DOM node refs change mentioned above, this.getDOMNode() is now deprecated and ReactDOM.findDOMNode(this) can be used instead. Note that in most cases, calling findDOMNode is now unnecessary – see the example above in the “DOM node refs” section.

  With each returned DOM node, we've added a getDOMNode method for backwards compatibility that will work with a warning until 0.15. If you have a large codebase, you can use our automated codemod script to change your code automatically.

• setProps and replaceProps are now deprecated. Instead, call ReactDOM.render again at the top level with the new props.

• ES6 component classes must now extend React.Component in order to enable stateless function components. The ES3 module pattern will continue to work.

• Reusing and mutating a style object between renders has been deprecated. This mirrors our change to freeze the props object.

• Add-Ons: cloneWithProps is now deprecated. Use React.cloneElement instead (unlike cloneWithProps, cloneElement does not merge className or style automatically; you can merge them manually if needed).

• Add-Ons: To improve reliability, CSSTransitionGroup will no longer listen to transition events. Instead, you should specify transition durations manually using props such as transitionEnterTimeout={500}.

Notable enhancements #

• Added React.Children.toArray which takes a nested children object and returns a flat array with keys assigned to each child. This helper makes it easier to manipulate collections of children in your render methods, especially if you want to reorder or slice this.props.children before passing it down. In addition, React.Children.map now returns plain arrays too.
• React uses console.error instead of console.warn for warnings so that browsers show a full stack trace in the console. (Our warnings appear when you use patterns that will break in future releases and for code that is likely to behave unexpectedly, so we do consider our warnings to be “must-fix” errors.)
• Previously, including untrusted objects as React children could result in an XSS security vulnerability. This problem should be avoided by properly validating input at the application layer and by never passing untrusted objects around your application code. As an additional layer of protection, React now tags elements with a specific ES2015 (ES6) Symbol in browsers that support it, in order to ensure that React never considers untrusted JSON to be a valid element. If this extra security protection is important to you, you should add a Symbol polyfill for older browsers, such as the one included by Babel’s polyfill.
• When possible, React DOM now generates XHTML-compatible markup.
• React DOM now supports these standard HTML attributes: capture, challenge, inputMode, is, keyParams, keyType, minLength, summary, wrap. It also now supports these non-standard attributes: autoSave, results, security.
• React DOM now supports these SVG attributes, which render into namespaced attributes: xlinkActuate, xlinkArcrole, xlinkHref, xlinkRole, xlinkShow, xlinkTitle, xlinkType, xmlBase, xmlLang, xmlSpace.
• The image SVG tag is now supported by React DOM.
• In React DOM, arbitrary attributes are supported on custom elements (those with a hyphen in the tag name or an is="..." attribute).
• React DOM now supports these media events on audio and video tags: onAbort, onCanPlay, onCanPlayThrough, onDurationChange, onEmptied, onEncrypted, onEnded, onError, onLoadedData, onLoadedMetadata, onLoadStart, onPause, onPlay, onPlaying, onProgress, onRateChange, onSeeked, onSeeking, onStalled, onSuspend, onTimeUpdate, onVolumeChange, onWaiting.
• Many small performance improvements have been made.
• Many warnings show more context than before.
• Add-Ons: A shallowCompare add-on has been added as a migration path for PureRenderMixin in ES6 classes.
• Add-Ons: CSSTransitionGroup can now use custom class names instead of appending -enter-active or similar to the transition name.

New helpful warnings #

• React DOM now warns you when nesting HTML elements invalidly, which helps you avoid surprising errors during updates.
• Passing document.body directly as the container to ReactDOM.render now gives a warning as doing so can cause problems with browser extensions that modify the DOM.
• Using multiple instances of React together is not supported, so we now warn when we detect this case to help you avoid running into the resulting problems.

Notable bug fixes #

• Click events are handled by React DOM more reliably in mobile browsers, particularly in Mobile Safari.
• SVG elements are created with the correct namespace in more cases.
• React DOM now renders <option> elements with multiple text children properly and renders <select> elements on the server with the correct option selected.
• When two separate copies of React add nodes to the same document (including when a browser extension uses React), React DOM tries harder not to throw exceptions during event handling.
• Using non-lowercase HTML tag names in React DOM (e.g., React.createElement('DIV')) no longer causes problems, though we continue to recommend lowercase for consistency with the JSX tag name convention (lowercase names refer to built-in components, capitalized names refer to custom components).
• React DOM understands that these CSS properties are unitless and does not append “px” to their values: animationIterationCount, boxOrdinalGroup, flexOrder, tabSize, stopOpacity.
• Add-Ons: When using the test utils, Simulate.mouseEnter and Simulate.mouseLeave now work.
• Add-Ons: ReactTransitionGroup now correctly handles multiple nodes being removed simultaneously.

When you're in React's world you are just building components that fit into other components. Everything is a component. Unfortunately not everything around you is built using React. At the root of your tree you still have to write some plumbing code to connect the outer world into React.

The primary API for rendering into the DOM looks like this:

ReactDOM.render(reactElement, domContainerNode)

To update the properties of an existing component, you call render again with a new element.

If you are rendering React components within a single-page app, you may need to plug into the app's view lifecycle to ensure your app will invoke unmountComponentAtNode at the appropriate time. React will not automatically clean up a tree. You need to manually call:

ReactDOM.unmountComponentAtNode(domContainerNode)

This is important and often forgotten. Forgetting to call unmountComponentAtNode will cause your app to leak memory. There is no way for us to automatically detect when it is appropriate to do this work. Every system is different.

It is not unique to the DOM. If you want to insert a React Native view in the middle of an existing iOS app you will hit similar issues.

Helpers #

If you have multiple React roots, or a single root that gets deleted over time, we recommend that you always create your own wrapper API. These will all look slightly different depending on what your outer system looks like. For example, at Facebook we have a system that automatically ties into our page transition router to automatically call unmountComponentAtNode.

Rather than calling ReactDOM.render() directly everywhere, consider writing/using a library that will manage mounting and unmounting within your application.

In your environment you may want to always configure internationalization, routers, user data etc. If you have many different React roots it can be a pain to set up configuration nodes all over the place. By creating your own wrapper you can unify that configuration into one place.

Object Oriented Updates #

If you call ReactDOM.render a second time to update properties, all your props are completely replaced.

ReactDOM.render(<App locale="en-US" userID={1} />, container);
// props.userID == 1
// props.locale == "en-US"
ReactDOM.render(<App userID={2} />, container);
// props.userID == 2
// props.locale == undefined ??!?

In object-oriented programming, all state lives on each object instance and you apply changes incrementally by mutating that state, one piece at a time. If you are using React within an app that expects an object oriented API (for instance, if you are building a custom web component using React), it might be surprising/confusing to a user that setting a single property would wipe out all the other properties on your component.

We used to have a helper function called setProps which allowed you to update only a few properties at a time. Unfortunately this API lived on a component instance, required React to keep this state internally and wasn't very natural anyway. Therefore, we're deprecating it and suggest that you build it into your own wrapper instead.

Here's some boilerplate to get you started. It is a 0.14 migration path for codebases using setProps and replaceProps.

class ReactComponentRenderer {
  constructor(klass, container) {
    this.klass = klass;
    this.container = container;
    this.props = {};
    this.component = null;
  }

  replaceProps(props, callback) {
    this.props = {};
    this.setProps(props, callback);
  }

  setProps(partialProps, callback) {
    if (this.klass == null) {
      console.warn(
        'setProps(...): Can only update a mounted or ' +
        'mounting component. This usually means you called setProps() on ' +
        'an unmounted component. This is a no-op.'
      );
      return;
    }
    Object.assign(this.props, partialProps);
    var element = React.createElement(this.klass, this.props);
    this.component = ReactDOM.render(element, this.container, callback);
  }

  unmount() {
    ReactDOM.unmountComponentAtNode(this.container);
    this.klass = null;
  }
}

Object-oriented APIs don't look like that though. They use setters and methods. I think we can do better. If you know more about the component API that you're rendering, you can create a more natural object-oriented API around your React component.

class ReactVideoPlayer {
  constructor(url, container) {
    this._container = container;
    this._url = url;
    this._isPlaying = false;
    this._render();
  }

  _render() {
    ReactDOM.render(
      <VideoPlayer url={this._url} playing={this._isPlaying} />,
      this._container
    );
  }

  get url() {
    return this._url;
  }

  set url(value) {
    this._url = value;
    this._render();
  }

  play() {
    this._isPlaying = true;
    this._render();
  }

  pause() {
    this._isPlaying = false;
    this._render();
  }

  destroy() {
    ReactDOM.unmountComponentAtNode(this._container);
  }
}

This example shows how to provide an imperative API on top of a declarative one. Similarly, the reverse can be done, and a declarative wrapper can be used when exposing a Web Component as a React component.

In the weeks following the open-source release of the Relay technical preview, the community has been abuzz with activity. We are honored to have been able to enjoy a steady stream of ideas and contributions from such a talented group of individuals. Let's take a look at some of the things we've achieved, together!

Teaching servers to speak GraphQL #

Every great Relay app starts by finding a GraphQL server to talk to. The community has spent the past few weeks teaching GraphQL to a few backend systems.

Bryan Goldstein (brysgo) has built a tool to help you define a GraphQL schema that wraps a set of Bookshelf.JS models. Check out graphql-bookshelf.

RisingStack (risingstack) created a GraphQL ORM called graffiti that you can plug into mongoose and serve using Express, Hapi, or Koa.

David Mongeau-Petitpas (dmongeau) is working on a way to vend your Laravel models through a GraphQL endpoint, laravel-graphql.

Gerald Monaco (devknoll) created graphql-schema to allow the creation of JavaScript GraphQL schemas using a fluent/chainable interface.

Jason Dusek (solidsnack) dove deep into PostgreSQL to teach it how to respond to GraphQL query strings as though they were SQL queries. Check out GraphpostgresQL.

Espen Hovlandsdal (rexxars) built a sql-to-graphql tool that can perform introspection on the tables of a MySQL or PostgreSQL database, and produce a queryable HTTP GraphQL endpoint out of it.

Mick Hansen (mickhansen) offers a set of schema-building helpers for use with the Sequelize ORM for MySQL, PostgreSQL, SQLite, and MSSQL.

GraphQL beyond JavaScript #

Robert Mosolgo (rmosolgo) brought the full set of schema-building and query execution tools to Ruby, in the form of graphql-ruby and graphql-relay-ruby. Check out his Rails-based demo.

Andreas Marek (andimarek) has brewed up a Java implementation of GraphQL, graphql-java.

vladar is hard at work on a PHP port of the GraphQL reference implementation, graphql-php.

Taeho Kim (dittos) is bringing GraphQL to Python, with graphql-py.

Oleg Ilyenko (OlegIlyenko) made a beautiful and delicious-looking website for a Scala implementation of GraphQL, sangria.

Joe McBride (joemcbride) has an up-and-running example of GraphQL for .NET, graphql-dotnet.

Show me, don't tell me #

Interact with this visual tour of Relay's architecture by Sam Gwilym (sgwilym).

Sam has already launched a product that leverages Relay's data-fetching, optimistic responses, pagination, and mutations – all atop a Ruby GraphQL server: new.comique.co

Prototyping in the browser #

I (steveluscher) whipped up a prototyping tool that you can use to hack on a schema and a React/Relay app, from the comfort of your browser. Thanks to Jimmy Jia (taion) for supplying the local-only network layer, relay-local-schema.

Skeletons in the closet #

Joseph Rollins (fortruce) created a hot-reloading, auto schema-regenerating, Relay skeleton that you can use to get up and running quickly.

Michael Hart (mhart) built a simple-relay-starter kit using Browserify.

Routing around #

Jimmy Jia (taion) and Gerald Monaco (devknoll) have been helping lost URLs find their way to Relay apps through their work on react-router-relay. Check out Christoph Pojer's (cpojer) blog post on the topic. Jimmy completed the Relay TodoMVC example with routing, which you can check out at taion/relay-todomvc.

Chen Hung-Tu (transedward) built a chat app atop the above mentioned router, with threaded conversations and pagination. Check it out at transedward/relay-chat.

In your words #