React v0.13.2

April 18, 2015 by Paul O’Shannessy

Yesterday the React Native team shipped v0.4. Those of us working on the web team just a few feet away couldn't just be shown up like that so we're shipping v0.13.2 today as well! This is a bug fix release to address a few things while we continue to work towards v0.14.

The release is now available for download:

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

Changelog #

React Core #

New Features #

  • Added strokeDashoffset, flexPositive, flexNegative to the list of unitless CSS properties
  • Added support for more DOM properties:
    • scoped - for <style> elements
    • high, low, optimum - for <meter> elements
    • unselectable - IE-specific property to prevent user selection

Bug Fixes #

  • Fixed a case where re-rendering after rendering null didn't properly pass context
  • Fixed a case where re-rendering after rendering with style={null} didn't properly update style
  • Update uglify dependency to prevent a bug in IE8
  • Improved warnings

React with Add-Ons #

Bug Fixes #

  • Immutabilty Helpers: Ensure it supports hasOwnProperty as an object key

React Tools #

  • Improve documentation for new options

React Native v0.4

April 17, 2015 by Vjeux

It's been three weeks since we open sourced React Native and there's been some insane amount of activity already: over 12.5k stars, 1000 commits, 500 issues, 380 pull requests, and 100 contributors, plus 35 plugins and 1 app in the app store! We were expecting some buzz around the project but this is way beyond anything we imagined. Thank you!

I'd especially like to thank community members Brent Vatne and James Ide who have both already contributed meaningfully to the project and have been extremely helpful on IRC and with issues and pull requests

Changelog #

The main focus of the past few weeks has been to make React Native the best possible experience for people outside of Facebook. Here's a high level summary of what's happened since we open sourced:

  • Error messages and documentation: We want React Native to be the absolute best developer experience for building mobile apps. We've added a lot of warnings, improved the documentation, and fixed many bugs. If you encounter anything, and I really mean anything, that is not expected or clear, please create an issue - we want to hear about it and fix it.
  • NPM modules compatibility: There are a lot of libraries on NPM that do not depend on node/browser internals that would be really useful in React Native, such as superagent, underscore, parse, and many others. The packager is now a lot more faithful to node/browserify/webpack dependency resolution. If your favorite library doesn't work out of the box, please open up an issue.
  • Infrastructure: We are refactoring the internals of React Native to make it easier to plug in to existing iOS codebases, as well as improve performance by removing redundant views and shadow views, supporting multiple root views and manually registering classes to reduce startup time.
  • Components: The API for a lot of UI components and APIs, especially the ones we're not using heavily inside of Facebook, has dramatically improved thanks to many of your pull requests.
  • Tests: We ported JavaScript tests, iOS Snapshot tests, and End to End tests to Travis CI. We have broken GitHub master a couple of times (whoops!) when syncing and we hope that with this growing suite of tests it's going to become harder and harder to do so.
  • Patent Grant: Many of you had concerns and questions around the PATENTS file. We pushed a new version of the grant.
  • Per commit history: In order to synchronize from Facebook to GitHub, we used to do one giant commit every few days. We improved our tooling and now have per commit history that maintains author information (both internal and external from pull requests), and we retroactively applied this to historical diffs to provide proper attribution.

Where are we going? #

In addition to supporting pull requests, issues, and general improvements, we're also working hard on our internal React Native integrations and on React Native for Android.

Community Round-up #26

March 30, 2015 by Vjeux

We open sourced React Native last week and the community reception blew away all our expectations! So many of you tried it, made cool stuff with it, raised many issues and even submitted pull requests to fix them! The entire team wants to say thank you!

When is React Native Android coming? #

Give us 6 months. At Facebook, we strive to only open-source projects that we are using in production. While the Android backend for React Native is starting to work (see video below at 37min), it hasn't been shipped to any users yet. There's a lot of work that goes into open-sourcing a project, and we want to do it right so that you have a great experience when using it.

Ray Wenderlich - Property Finder #

If you are getting started with React Native, you should absolutely use this tutorial from Colin Eberhardt. It goes through all the steps to make a reasonably complete app.

Colin also blogged about his experience using React Native for a few weeks and gives his thoughts on why you would or wouldn't use it.

The Changelog #

Spencer Ahrens and I had the great pleasure to talk about React Native on The Changelog podcast. It was really fun to chat for an hour, I hope that you'll enjoy listening to it. :)

Hacker News #

Less than 24 hours after React Native was open sourced, Simarpreet Singh built an Hacker News reader app from scratch. It's unbelievable how fast he was able to pull it off!

Parse + React #

There's a huge ecosystem of JavaScript modules on npm and React Native was designed to work well with the ones that don't have DOM dependencies. Parse is a great example; you can npm install parse on your React Native project and it'll work as is. :) We still have a few issues to solve; please create an issue if your favorite library doesn't work out of the box.

tcomb-form-native #

Giulio Canti is the author of the tcomb-form library for React. He already ported it to React Native and it looks great!

Facebook Login with React Native #

One of the reason we built React Native is to be able to use all the libraries in the native ecosystem. Brent Vatne leads the way and explains how to use Facebook Login with React Native.

Modus Create #

Jay Garcia spent a lot of time during the beta working on a NES music player with React Native. He wrote a blog post to share his experience and explains some code snippets.

React Native with Babel and Webpack #

React Native ships with a custom packager and custom ES6 transforms instead of using what the open source community settled on such as Webpack and Babel. The main reason for this is performance – we couldn't get those tools to have sub-second reload time on a large codebase.

Roman Liutikov found a way to use Webpack and Babel to run on React Native! In the future, we want to work with those projects to provide cleaner extension mechanisms.

A Dynamic, Crazy, Native Mobile Future—Powered by JavaScript #

Clay Allsopp wrote a post about all the crazy things you could do with a JavaScript engine that renders native views. What about native embeds, seamless native browser, native search engine or even app generation...

Random Tweet #

We've spent a lot of efforts getting the onboarding as easy as possible and we're really happy that people noticed. We still have a lot of work to do on documentation, stay tuned!

Introducing React Native

March 26, 2015 by Ben Alpert

In January at React.js Conf, we announced React Native, a new framework for building native apps using React. We're happy to announce that we're open-sourcing React Native and you can start building your apps with it today.

For more details, see Tom Occhino's post on the Facebook Engineering blog:

What we really want is the user experience of the native mobile platforms, combined with the developer experience we have when building with React on the web.

With a bit of work, we can make it so the exact same React that's on GitHub can power truly native mobile applications. The only difference in the mobile environment is that instead of running React in the browser and rendering to divs and spans, we run it an embedded instance of JavaScriptCore inside our apps and render to higher-level platform-specific components.

It's worth noting that we're not chasing “write once, run anywhere.” Different platforms have different looks, feels, and capabilities, and as such, we should still be developing discrete apps for each platform, but the same set of engineers should be able to build applications for whatever platform they choose, without needing to learn a fundamentally different set of technologies for each. We call this approach “learn once, write anywhere.”

To learn more, visit the React Native website.

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
class Story extends React.Component {
  render() {
    var story = this.props.story;
    return (
        <Image uri={} />

module.exports = Story;

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 { ... }

module.exports = Relay.createContainer(Story, {
  queries: {
    story: /* TODO */

Before adding the GraphQL query, 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 query is defined. In this case we'll add a GraphQL query for story:

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

module.exports = Relay.createContainer(Story, {
  queries: {
    story: graphql`
      Story {
        author {
          profile_picture {

Queries use ES6 template literals tagged with the graphql function. Similar to how JSX transpiles to plain JavaScript objects and function calls, these template literals transpile to plain objects that describe queries. Note that the query'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",
    profile_picture: {
      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 (
        { => <Story story={story} />)}
        <Button onClick={() => this.loadMore()}>Load More</Button>

  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 queries can compose queries from child components. Composition in GraphQL uses ES6 template literal substitution: ${Component.getQuery('prop')}. Pagination can be accomplished with a query parameter, specified with <param> (as in stories(first: <count>)):

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

module.exports = Relay.createContainer(NewsFeed, {
  queryParams: {
    count: 3                             /* default to 3 stories */
  queries: {
    viewer: graphql`
      Viewer {
        stories(first: <count>) {        /* fetch viewer's stories */
          edges {                        /* traverse the graph */
            node {
              ${Story.getQuery('story')} /* compose child query */

Whenever <NewsFeed> is rendered, Relay will recursively expand all the composed queries and fetch them 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 parameters are available to components as props.queryParams and can be modified with props.setQueryParams(nextParams). We can use these to implement pagination:

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

  loadMore() {
    // read current params
    var count = this.props.queryParams.count;
    // update params
      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.queryParams.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.