{"componentChunkName":"component---src-templates-blog-js","path":"/blog/2015/03/19/building-the-facebook-news-feed-with-relay.html","result":{"data":{"markdownRemark":{"html":"

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.

\n

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.

\n
\n

The Relay Architecture

\n

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

\n\n \n \n \n \n \"Relay\n \n \n \n \n \n

The main pieces are as follows:

\n\n

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.

\n
\n

A Relay Application

\n

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:

\n\n \n \n \n \n \"Sample\n \n \n \n \n \n
\n

The <Story> Begins

\n

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.

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

What’s the <Story>?

\n

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

\n
// Story.react.js\nclass Story extends React.Component { ... }\n\nexport default Relay.createContainer(Story, {\n  fragments: {\n    story: /* TODO */\n  }\n});
\n

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

\n\n \n \n \n \n \"React\n \n \n \n \n \n

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:

\n
// Story.react.js\nclass Story extends React.Component { ... }\n\nexport default Relay.createContainer(Story, {\n  fragments: {\n    story: () => Relay.QL`\n      fragment on Story {\n        author {\n          name\n          profilePicture {\n            uri\n          }\n        }\n        text\n      }\n    `,\n  },\n});
\n

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.

\n
\n

<Story>s on Demand

\n

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:

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

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.

\n

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

\n\n \n \n \n \n \"Relay\n \n \n \n \n \n
\n

<NewsFeed> Worthy

\n

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

\n
// NewsFeed.react.js\nclass NewsFeed extends React.Component {\n  render() {\n    var stories = this.props.viewer.stories; // `viewer` is the active user\n    return (\n      <View>\n        {stories.map(story => <Story story={story} />)}\n        <Button onClick={() => this.loadMore()}>Load More</Button>\n      </View>\n    );\n  }\n\n  loadMore() {\n    // TODO: fetch more stories\n  }\n}\n\nmodule.exports = NewsFeed;
\n
\n

All the News Fit to be Relayed

\n

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

\n

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)):

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

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.

\n

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:

\n
// NewsFeed.react.js\nclass NewsFeed extends React.Component {\n  render() { ... }\n\n  loadMore() {\n    // read current params\n    var count = this.props.relay.variables.count;\n    // update params\n    this.props.relay.setVariables({\n      count: count + 5,\n    });\n  }\n}
\n

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.

\n
\n

In Conclusion

\n

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:

\n\n

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.

","excerpt":"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…","frontmatter":{"title":"Building The Facebook News Feed With Relay","next":null,"prev":null,"author":[{"frontmatter":{"name":"Joseph Savona","url":"https://twitter.com/en_JS"}}]},"fields":{"date":"March 19, 2015","path":"content/blog/2015-03-19-building-the-facebook-news-feed-with-relay.md","slug":"/blog/2015/03/19/building-the-facebook-news-feed-with-relay.html"}},"allMarkdownRemark":{"edges":[{"node":{"frontmatter":{"title":"Introducing the New JSX Transform"},"fields":{"slug":"/blog/2020/09/22/introducing-the-new-jsx-transform.html"}}},{"node":{"frontmatter":{"title":"React v17.0 Release Candidate: No New Features"},"fields":{"slug":"/blog/2020/08/10/react-v17-rc.html"}}},{"node":{"frontmatter":{"title":"React v16.13.0"},"fields":{"slug":"/blog/2020/02/26/react-v16.13.0.html"}}},{"node":{"frontmatter":{"title":"Building Great User Experiences with Concurrent Mode and Suspense"},"fields":{"slug":"/blog/2019/11/06/building-great-user-experiences-with-concurrent-mode-and-suspense.html"}}},{"node":{"frontmatter":{"title":"Preparing for the Future with React Prereleases"},"fields":{"slug":"/blog/2019/10/22/react-release-channels.html"}}},{"node":{"frontmatter":{"title":"Introducing the New React DevTools"},"fields":{"slug":"/blog/2019/08/15/new-react-devtools.html"}}},{"node":{"frontmatter":{"title":"React v16.9.0 and the Roadmap Update"},"fields":{"slug":"/blog/2019/08/08/react-v16.9.0.html"}}},{"node":{"frontmatter":{"title":"Is React Translated Yet? ¡Sí! Sim! はい！"},"fields":{"slug":"/blog/2019/02/23/is-react-translated-yet.html"}}},{"node":{"frontmatter":{"title":"React v16.8: The One With Hooks"},"fields":{"slug":"/blog/2019/02/06/react-v16.8.0.html"}}},{"node":{"frontmatter":{"title":"React v16.7: No, This Is Not the One With Hooks"},"fields":{"slug":"/blog/2018/12/19/react-v-16-7.html"}}}]}},"pageContext":{"slug":"/blog/2015/03/19/building-the-facebook-news-feed-with-relay.html"}},"staticQueryHashes":[]}