Building The Facebook News Feed With Relay

March 19, 2015 by Joseph Savona


At React.js Conf in January we gave a preview of Relay, a new framework for building data-driven applications in React. In this post, we'll describe the process of creating a Relay application. This post assumes some familiarity with the concepts of Relay and GraphQL, so if you haven't already we recommend reading our introductory blog post or watching the conference talk.

We're working hard to prepare GraphQL and Relay for public release. In the meantime, we'll continue to provide information about what you can expect.


The Relay Architecture #

The diagram below shows the main parts of the Relay architecture on the client and the server:

Relay Architecture

The main pieces are as follows:

  • Relay Components: React components annotated with declarative data descriptions.
  • Actions: Descriptions of how data should change in response to user actions.
  • Relay Store: A client-side data store that is fully managed by the framework.
  • Server: An HTTP server with GraphQL endpoints (one for reads, one for writes) that respond to GraphQL queries.

This post will focus on Relay components that describe encapsulated units of UI and their data dependencies. These components form the majority of a Relay application.


A Relay Application #

To see how components work and can be composed, let's implement a basic version of the Facebook News Feed in Relay. Our application will have two components: a <NewsFeed> that renders a list of <Story> items. We'll introduce the plain React version of each component first and then convert it to a Relay component. The goal is something like the following:

Sample News Feed


The <Story> Begins #

The first step is a React <Story> component that accepts a story prop with the story's text and author information. Note that all examples uses ES6 syntax and elide presentation details to focus on the pattern of data access.

// Story.react.js
export default class Story extends React.Component {
  render() {
    var story = this.props.story;
    return (
      <View>
        <Image uri={story.author.profilePicture.uri} />
        <Text>{story.author.name}</Text>
        <Text>{story.text}</Text>
      </View>
    );
  }
}


What's the <Story>? #

Relay automates the process of fetching data for components by wrapping existing React components in Relay containers (themselves React components):

// Story.react.js
class Story extends React.Component { ... }

export default Relay.createContainer(Story, {
  fragments: {
    story: /* TODO */
  }
});

Before adding the GraphQL fragment, let's look at the component hierarchy this creates:

React Container Data Flow

Most props will be passed through from the container to the original component. However, Relay will return the query results for a prop whenever a fragment is defined. In this case we'll add a GraphQL fragment for story:

// Story.react.js
class Story extends React.Component { ... }

export default Relay.createContainer(Story, {
  fragments: {
    story: () => Relay.QL`
      fragment on Story {
        author {
          name
          profilePicture {
            uri
          }
        }
        text
      }
    `,
  },
});

Queries use ES6 template literals tagged with the Relay.QL function. Similar to how JSX transpiles to plain JavaScript objects and function calls, these template literals transpile to plain objects that describe fragments. Note that the fragment's structure closely matches the object structure that we expected in <Story>'s render function.


<Story>s on Demand #

We can render a Relay component by providing Relay with the component (<Story>) and the ID of the data (a story ID). Given this information, Relay will first fetch the results of the query and then render() the component. The value of props.story will be a plain JavaScript object such as the following:

{
  author: {
    name: "Greg",
    profilePicture: {
      uri: "https://…"
    }
  },
  text: "The first Relay blog post is up…"
}

Relay guarantees that all data required to render a component will be available before it is rendered. This means that <Story> does not need to handle a loading state; the story is guaranteed to be available before render() is called. We have found that this invariant simplifies our application code and improves the user experience. Of course, Relay also has options to delay the fetching of some parts of our queries.

The diagram below shows how Relay containers make data available to our React components:

Relay Container Data Flow


<NewsFeed> Worthy #

Now that the <Story> is over we can continue with the <NewsFeed> component. Again, we'll start with a React version:

// NewsFeed.react.js
class NewsFeed extends React.Component {
  render() {
    var stories = this.props.viewer.stories; // `viewer` is the active user
    return (
      <View>
        {stories.map(story => <Story story={story} />)}
        <Button onClick={() => this.loadMore()}>Load More</Button>
      </View>
    );
  }

  loadMore() {
    // TODO: fetch more stories
  }
}

module.exports = NewsFeed;


All the News Fit to be Relayed #

<NewsFeed> has two new requirements: it composes <Story> and requests more data at runtime.

Just as React views can be nested, Relay components can compose query fragments from child components. Composition in GraphQL uses ES6 template literal substitution: ${Component.getFragment('prop')}. Pagination can be accomplished with a variable, specified with $variable (as in stories(first: $count)):

// NewsFeed.react.js
class NewsFeed extends React.Component { ... }

export default Relay.createContainer(NewsFeed, {
  initialVariables: {
    count: 3                                /* default to 3 stories */
  },
  fragments: {
    viewer: () => Relay.QL`
      fragment on Viewer {
        stories(first: $count) {            /* fetch viewer's stories */
          edges {                           /* traverse the graph */
            node {
              ${Story.getFragment('story')} /* compose child fragment */
            }
          }
        }
      }
    `,
  },
});

Whenever <NewsFeed> is rendered, Relay will recursively expand all the composed fragments and fetch the queries in a single trip to the server. In this case, the text and author data will be fetched for each of the 3 story nodes.

Query variables are available to components as props.relay.variables and can be modified with props.relay.setVariables(nextVariables). We can use these to implement pagination:

// NewsFeed.react.js
class NewsFeed extends React.Component {
  render() { ... }

  loadMore() {
    // read current params
    var count = this.props.relay.variables.count;
    // update params
    this.props.relay.setVariables({
      count: count + 5,
    });
  }
}

Now when loadMore() is called, Relay will send a GraphQL request for the additional five stories. When these stories are fetched, the component will re-render with the new stories available in props.viewer.stories and the updated count reflected in props.relay.variables.count.


In Conclusion #

These two components form a solid core for our application. With the use of Relay containers and GraphQL queries, we've enabled the following benefits:

  • Automatic and efficient pre-fetching of data for an entire view hierarchy in a single network request.
  • Trivial pagination with automatic optimizations to fetch only the additional items.
  • View composition and reusability, so that <Story> can be used on its own or within <NewsFeed>, without any changes to either component.
  • Automatic subscriptions, so that components will re-render if their data changes. Unaffected components will not re-render unnecessarily.
  • Exactly zero lines of imperative data fetching logic. Relay takes full advantage of React's declarative component model.

But Relay has many more tricks up its sleeve. For example, it's built from the start to handle reads and writes, allowing for features like optimistic client updates with transactional rollback. Relay can also defer fetching select parts of queries, and it uses a local data store to avoid fetching the same data twice. These are all powerful features that we hope to explore in future posts.

React v0.13.1

March 16, 2015 by Paul O’Shannessy


It's been less than a week since we shipped v0.13.0 but it's time to do another quick release. We just released v0.13.1 which contains bugfixes for a number of small issues.

Thanks all of you who have been upgrading your applications and taking the time to report issues. And a huge thank you to those of you who submitted pull requests for the issues you found! 2 of the 6 fixes that went out today came from people who aren't on the core team!

The release is now available for download:

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


Changelog #

React Core #

Bug Fixes #

  • Don't throw when rendering empty <select> elements
  • Ensure updating style works when transitioning from null

React with Add-Ons #

Bug Fixes #

  • TestUtils: Don't warn about getDOMNode for ES6 classes
  • TestUtils: Ensure wrapped full page components (<html>, <head>, <body>) are treated as DOM components
  • Perf: Stop double-counting DOM components

React Tools #

Bug Fixes #

  • Fix option parsing for --non-strict-es6module

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.