React v15.6.0

June 13, 2017 by Flarnie Marchan


Today we are releasing React 15.6.0. As we prepare for React 16.0, we have been fixing and cleaning up many things. This release continues to pave the way.

Improving Inputs

In React 15.6.0 the onChange event for inputs is a little bit more reliable and handles more edge cases, including the following:

  • not firing when radio button is clicked but not changed (issue 1471)
  • changing an input of type range with the arrow keys (issue 554)
  • pasting text into a text area in IE11 (issue 7211)
  • auto-fill in IE11 (issue 6614)
  • clearing input with 'x' button or right-click 'delete' in IE11 (issue 6822)
  • not firing when characters are present in the input on render in IE11 (issue 2185)

Thanks to Jason Quense and everyone who helped out on those issues and PRs.

Less Noisy Deprecation Warnings

We are also including a couple of new warnings for upcoming deprecations. These should not affect most users, and for more details see the changelog below.

After the last release, we got valuable community feedback that deprecation warnings were causing noise and failing tests. In React 15.6, we have downgraded deprecation warnings to use console.warn instead of console.error. Our other warnings will still use console.error because they surface urgent issues which could lead to bugs. Unlike our other warnings, deprecation warnings can be fixed over time and won't cause problems in your app if shipped. We believe that downgrading the urgency of deprecation warnings will make your next update easier. Thanks to everyone who was involved in the discussion of this change.


Installation

We recommend using Yarn or npm for managing front-end dependencies. If you're new to package managers, the Yarn documentation is a good place to get started.

To install React with Yarn, run:

yarn add react@^15.6.0 react-dom@^15.6.0

To install React with npm, run:

npm install --save react@^15.6.0 react-dom@^15.6.0

We recommend using a bundler like webpack or Browserify so you can write modular code and bundle it together into small packages to optimize load time.

Remember that by default, React runs extra checks and provides helpful warnings in development mode. When deploying your app, make sure to use the production build.

In case you don't use a bundler, we also provide pre-built bundles in the npm packages which you can include as script tags on your page:

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


Changelog

15.6.0 (June 13, 2017)

React

  • Downgrade deprecation warnings to use console.warn instead of console.error. (@flarnie in #9753)
  • Add a deprecation warning for React.createClass. Points users to create-react-class instead. (@flarnie in #9771)
  • Add deprecation warnings and separate module for React.DOM factory helpers. (@nhunzaker in #8356)
  • Warn for deprecation of React.createMixin helper, which was never used. (@aweary in #8853)

React DOM

  • Add support for CSS variables in style attribute. (@aweary in #9302)
  • Add support for CSS Grid style properties. (@ericsakmar in #9185)
  • Fix bug where inputs mutated value on type conversion. (@nhunzaker in #9806)
  • Fix issues with onChange not firing properly for some inputs. (@jquense in #8575)
  • Fix bug where controlled number input mistakenly allowed period. (@nhunzaker in #9584)
  • Fix bug where performance entries were being cleared. (@chrisui in #9451)

React Addons

  • Fix AMD support for addons depending on react. (@flarnie in #9919)
  • Fix isMounted() to return true in componentWillUnmount. (@mridgway in #9638)
  • Fix react-addons-update to not depend on native Object.assign. (@gaearon in #9937)
  • Remove broken Google Closure Compiler annotation from create-react-class. (@gaearon in #9933)
  • Remove unnecessary dependency from react-linked-input. (@gaearon in #9766)
  • Point react-addons-(css-)transition-group to the new package. (@gaearon in #9937)

What's New in Create React App

May 18, 2017 by Dan Abramov


Less than a year ago, we introduced Create React App as an officially supported way to create apps with zero configuration. The project has since enjoyed tremendous growth, with over 950 commits by more than 250 contributors.

Today, we are excited to announce that many features that have been in the pipeline for the last few months are finally released.

As usual with Create React App, you can enjoy these improvements in your existing non-ejected apps by updating a single dependency and following our migration instructions.

Newly created apps will get these improvements automatically.

webpack 2

This change was contributed by @Timer in #1291.

We have upgraded to webpack 2 which has been officially released a few months ago. It is a big upgrade with many bugfixes and general improvements. We have been testing it for a while, and now consider it stable enough to recommend it to everyone.

While the Webpack configuration format has changed, Create React App users who didn't eject don't need to worry about it as we have updated the configuration on our side.

If you had to eject your app for one reason or another, Webpack provides a configuration migration guide that you can follow to update your apps. Note that with each release of Create React App, we are working to support more use cases out of the box so that you don't have to eject in the future.

The biggest notable webpack 2 feature is the ability to write and import ES6 modules directly without compiling them to CommonJS. This shouldn’t affect how you write code since you likely already use import and export statements, but it will help catch more mistakes like missing named exports at compile time:

Export validation

In the future, as the ecosystem around ES6 modules matures, you can expect more improvements to your app's bundle size thanks to tree shaking.

 Runtime Error Overlay

This change was contributed by @Timer and @nicinabox in #1101, @bvaughn in #2201.

Have you ever made a mistake in code and only realized it after the console is flooded with cryptic errors? Or worse, have you ever shipped an app with crashes in production because you accidentally missed an error in development?

To address these issues, we are introducing an overlay that pops up whenever there is an uncaught error in your application. It only appears in development, and you can dismiss it by pressing Escape.

A GIF is worth a thousand words:

Runtime error overlay

(Yes, it integrates with your editor!)

In the future, we plan to teach the runtime error overlay to understand more about your React app. For example, after React 16 we plan to show React component stacks in addition to the JavaScript stacks when an error is thrown.

Progressive Web Apps by Default

This change was contributed by @jeffposnick in #1728.

Newly created projects are built as Progressive Web Apps by default. This means that they employ service workers with an offline-first caching strategy to minimize the time it takes to serve the app to the users who visit it again. You can opt out of this behavior, but we recommend it both for new and existing apps, especially if you target mobile devices.

Loading assets from service worker

New apps automatically have these features, but you can easily convert an existing project to a Progressive Web App by following our migration guide.

We will be adding more documentation on this topic in the coming weeks. Please feel free to ask any questions on the issue tracker!

Jest 20

This change was contributed by @rogeliog in #1614 and @gaearon in #2171.

We are now using the latest version of Jest that includes numerous bugfixes and improvements. You can read more about the changes in Jest 19 and Jest 20 blog posts.

Highlights include a new immersive watch mode, a better snapshot format, improvements to printing skipped tests, and new testing APIs.

Immersive test watcher

Additionally, Create React App now support configuring a few Jest options related to coverage reporting.

Code Splitting with Dynamic import()

This change was contributed by @Timer in #1538 and @tharakawj in #1801.

It is important to keep the initial JavaScript payload of web apps down to the minimum, and load the rest of the code on demand. Although Create React App supported code splitting using require.ensure() since the first release, it used a webpack-specific syntax that did not work in Jest or other environments.

In this release, we are adding support for the dynamic import() proposal which aligns with the future web standards. Unlike require.ensure(), it doesn't break Jest tests, and should eventually become a part of JavaScript. We encourage you to use import() to delay loading the code for non-critical component subtrees until you need to render them.

Creating chunks with dynamic import

Better Console Output

This change was contributed by @gaearon in #2120, #2125, and #2161.

We have improved the console output across the board.

For example, when you start the development server, we now display the LAN address in additional to the localhost address so that you can quickly access the app from a mobile device on the same network:

Better console output

When lint errors are reported, we no longer show the warnings so that you can concentrate on more critical issues. Errors and warnings in the production build output are better formatted, and the build error overlay font size now matches the browser font size more closely.

But Wait... There's More!

You can only fit so much in a blog post, but there are other long-requested features in this release, such as environment-specific and local .env files, a lint rule against confusingly named globals, support for multiple proxies in development, a customizable browser launch script, and many bugfixes.

You can read the full changelog and the migration guide in the v1.0.0 release notes.

Acknowledgements

This release is a result of months of work from many people in the React community. It is focused on improving both developer and end user experience, as we believe they are complementary and go hand in hand.

We are grateful to everyone who has offered their contributions, whether in code, documentation, or by helping other people. We would like to specifically thank Joe Haddad for his invaluable help maintaining the project.

We are excited to bring these improvements to everybody using Create React App, and we are looking forward to more of your feedback and contributions.

React v15.5.0

April 7, 2017 by Andrew Clark


It's been exactly one year since the last breaking change to React. Our next major release, React 16, will include some exciting improvements, including a complete rewrite of React's internals. We take stability seriously, and are committed to bringing those improvements to all of our users with minimal effort.

To that end, today we're releasing React 15.5.0.

New Deprecation Warnings

The biggest change is that we've extracted React.PropTypes and React.createClass into their own packages. Both are still accessible via the main React object, but using either will log a one-time deprecation warning to the console when in development mode. This will enable future code size optimizations.

These warnings will not affect the behavior of your application. However, we realize they may cause some frustration, particularly if you use a testing framework that treats console.error as a failure.

Adding new warnings is not something we do lightly. Warnings in React are not mere suggestions — they are integral to our strategy of keeping as many people as possible on the latest version of React. We never add warnings without providing an incremental path forward.

So while the warnings may cause frustration in the short-term, we believe prodding developers to migrate their codebases now prevents greater frustration in the future. Proactively fixing warnings ensures you are prepared for the next major release. If your app produces zero warnings in 15.5, it should continue to work in 16 without any changes.

For each of these new deprecations, we've provided a codemod to automatically migrate your code. They are available as part of the react-codemod project.

Migrating from React.PropTypes

Prop types are a feature for runtime validation of props during development. We've extracted the built-in prop types to a separate package to reflect the fact that not everybody uses them.

In 15.5, instead of accessing PropTypes from the main React object, install the prop-types package and import them from there:

// Before (15.4 and below)
import React from 'react';

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

Component.propTypes = {
  text: React.PropTypes.string.isRequired,
}

// After (15.5)
import React from 'react';
import PropTypes from 'prop-types';

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

Component.propTypes = {
  text: PropTypes.string.isRequired,
};

The codemod for this change performs this conversion automatically. Basic usage:

jscodeshift -t react-codemod/transforms/React-PropTypes-to-prop-types.js <path>

The propTypes, contextTypes, and childContextTypes APIs will work exactly as before. The only change is that the built-in validators now live in a separate package.

You may also consider using Flow to statically type check your JavaScript code, including React components.

Migrating from React.createClass

When React was initially released, there was no idiomatic way to create classes in JavaScript, so we provided our own: React.createClass.

Later, classes were added to the language as part of ES2015, so we added the ability to create React components using JavaScript classes. Along with functional components, JavaScript classes are now the preferred way to create components in React.

For your existing createClass components, we recommend that you migrate them to JavaScript classes. However, if you have components that rely on mixins, converting to classes may not be immediately feasible. If so, create-react-class is available on npm as a drop-in replacement:

// Before (15.4 and below)
var React = require('react');

var Component = React.createClass({
  mixins: [MixinA],
  render() {
    return <Child />;
  }
});

// After (15.5)
var React = require('react');
var createReactClass = require('create-react-class');

var Component = createReactClass({
  mixins: [MixinA],
  render() {
    return <Child />;
  }
});

Your components will continue to work the same as they did before.

The codemod for this change attempts to convert a createClass component to a JavaScript class, with a fallback to create-react-class if necessary. It has converted thousands of components internally at Facebook.

Basic usage:

jscodeshift -t react-codemod/transforms/class.js path/to/components

Discontinuing support for React Addons

We're discontinuing active maintenance of React Addons packages. In truth, most of these packages haven't been actively maintained in a long time. They will continue to work indefinitely, but we recommend migrating away as soon as you can to prevent future breakages.

  • react-addons-create-fragment – React 16 will have first-class support for fragments, at which point this package won't be necessary. We recommend using arrays of keyed elements instead.
  • react-addons-css-transition-group - Use react-transition-group/CSSTransitionGroup instead. Version 1.1.1 provides a drop-in replacement.
  • react-addons-linked-state-mixin - Explicitly set the value and onChange handler instead.
  • react-addons-pure-render-mixin - Use React.PureComponent instead.
  • react-addons-shallow-compare - Use React.PureComponent instead.
  • react-addons-transition-group - Use react-transition-group/TransitionGroup instead. Version 1.1.1 provides a drop-in replacement.
  • react-addons-update - Use immutability-helper instead, a drop-in replacement.
  • react-linked-input - Explicitly set the value and onChange handler instead.

We're also discontinuing support for the react-with-addons UMD build. It will be removed in React 16.

React Test Utils

Currently, the React Test Utils live inside react-addons-test-utils. As of 15.5, we're deprecating that package and moving them to react-dom/test-utils instead:

// Before (15.4 and below)
import TestUtils from 'react-addons-test-utils';

// After (15.5)
import TestUtils from 'react-dom/test-utils';

This reflects the fact that what we call the Test Utils are really a set of APIs that wrap the DOM renderer.

The exception is shallow rendering, which is not DOM-specific. The shallow renderer has been moved to react-test-renderer/shallow.

// Before (15.4 and below)
import { createRenderer } from 'react-addons-test-utils';

// After (15.5)
import { createRenderer } from 'react-test-renderer/shallow';

Acknowledgements

A special thank you to these folks for transferring ownership of npm package names:


Installation

We recommend using Yarn or npm for managing front-end dependencies. If you're new to package managers, the Yarn documentation is a good place to get started.

To install React with Yarn, run:

yarn add react@^15.5.0 react-dom@^15.5.0

To install React with npm, run:

npm install --save react@^15.5.0 react-dom@^15.5.0

We recommend using a bundler like webpack or Browserify so you can write modular code and bundle it together into small packages to optimize load time.

Remember that by default, React runs extra checks and provides helpful warnings in development mode. When deploying your app, make sure to compile it in production mode.

In case you don't use a bundler, we also provide pre-built bundles in the npm packages which you can include as script tags on your page:

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


Changelog

15.5.0 (April 7, 2017)

React

  • Added a deprecation warning for React.createClass. Points users to create-react-class instead. (@acdlite in d9a4fa4)
  • Added a deprecation warning for React.PropTypes. Points users to prop-types instead. (@acdlite in 043845c)
  • Fixed an issue when using ReactDOM together with ReactDOMServer. (@wacii in #9005)
  • Fixed issue with Closure Compiler. (@anmonteiro in #8895)
  • Another fix for Closure Compiler. (@Shastel in #8882)
  • Added component stack info to invalid element type warning. (@n3tr in #8495)

React DOM

  • Fixed Chrome bug when backspacing in number inputs. (@nhunzaker in #7359)
  • Added react-dom/test-utils, which exports the React Test Utils. (@bvaughn)

React Test Renderer

  • Fixed bug where componentWillUnmount was not called for children. (@gre in #8512)
  • Added react-test-renderer/shallow, which exports the shallow renderer. (@bvaughn)

React Addons

  • Last release for addons; they will no longer be actively maintained.
  • Removed peerDependencies so that addons continue to work indefinitely. (@acdlite and @bvaughn in 8a06cd7 and 67a8db3)
  • Updated to remove references to React.createClass and React.PropTypes (@acdlite in 12a96b9)
  • react-addons-test-utils is deprecated. Use react-dom/test-utils and react-test-renderer/shallow instead. (@bvaughn)

React v15.4.0

November 16, 2016 by Dan Abramov


Today we are releasing React 15.4.0.

We didn't announce the previous minor releases on the blog because most of the changes were bug fixes. However, 15.4.0 is a special release, and we would like to highlight a few notable changes in it.

Separating React and React DOM

More than a year ago, we started separating React and React DOM into separate packages. We deprecated React.render() in favor of ReactDOM.render() in React 0.14, and removed DOM-specific APIs from React completely in React 15. However, the React DOM implementation still secretly lived inside the React package.

In React 15.4.0, we are finally moving React DOM implementation to the React DOM package. The React package will now contain only the renderer-agnostic code such as React.Component and React.createElement().

This solves a few long-standing issues, such as errors when you import React DOM in the same file as the snapshot testing renderer.

If you only use the official and documented React APIs you won't need to change anything in your application.

However, there is a possibility that you imported private APIs from react/lib/*, or that a package you rely on might use them. We would like to remind you that this was never supported, and that your apps should not rely on internal APIs. The React internals will keep changing as we work to make React better.

Another thing to watch out for is that React DOM Server is now about the same size as React DOM since it contains its own copy of the React reconciler. We don't recommend using React DOM Server on the client in most cases.

Profiling Components with Chrome Timeline

You can now visualize React components in the Chrome Timeline. This lets you see which components exactly get mounted, updated, and unmounted, how much time they take relative to each other.

React components in Chrome timeline

To use it:

  1. Load your app with ?react_perf in the query string (for example, http://localhost:3000/?react_perf).

  2. Open the Chrome DevTools Timeline tab and press Record.

  3. Perform the actions you want to profile. Don't record more than 20 seconds or Chrome might hang.

  4. Stop recording.

  5. React events will be grouped under the User Timing label.

Note that the numbers are relative so components will render faster in production. Still, this should help you realize when unrelated UI gets updated by mistake, and how deep and how often your UI updates occur.

Currently Chrome, Edge, and IE are the only browsers supporting this feature, but we use the standard User Timing API so we expect more browsers to add support for it.

Mocking Refs for Snapshot Testing

If you're using Jest snapshot testing, you might have had issues with components that rely on refs. With React 15.4.0, we introduce a way to provide mock refs to the test renderer. For example, consider this component using a ref in componentDidMount:

import React from 'react';

export default class MyInput extends React.Component {
  componentDidMount() {
    this.input.focus();
  }

  render() {
    return (
      <input
        ref={node => this.input = node}
      />
    );
  }
}

With snapshot renderer, this.input will be null because there is no DOM. React 15.4.0 lets us avoid such crashes by passing a custom createNodeMock function to the snapshot renderer in an options argument:

import React from 'react';
import MyInput from './MyInput';
import renderer from 'react-test-renderer';

function createNodeMock(element) {
  if (element.type === 'input') {
    return {
      focus() {},
    };
  }
  return null;
}

it('renders correctly', () => {
  const options = {createNodeMock};
  const tree = renderer.create(<MyInput />, options);
  expect(tree).toMatchSnapshot();
});

We would like to thank Brandon Dail for implementing this feature.

You can learn more about snapshot testing in this Jest blog post.


Installation

We recommend using Yarn or npm for managing front-end dependencies. If you're new to package managers, the Yarn documentation is a good place to get started.

To install React with Yarn, run:

yarn add react@15.4.0 react-dom@15.4.0

To install React with npm, run:

npm install --save react@15.4.0 react-dom@15.4.0

We recommend using a bundler like webpack or Browserify so you can write modular code and bundle it together into small packages to optimize load time.

Remember that by default, React runs extra checks and provides helpful warnings in development mode. When deploying your app, make sure to compile it in production mode.

In case you don't use a bundler, we also provide pre-built bundles in the npm packages which you can include as script tags on your page:

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


Changelog

React

  • React package and browser build no longer "secretly" includes React DOM.
    (@sebmarkbage in #7164 and #7168)
  • Required PropTypes now fail with specific messages for null and undefined.
    (@chenglou in #7291)
  • Improved development performance by freezing children instead of copying.
    (@keyanzhang in #7455)

React DOM

  • Fixed occasional test failures when React DOM is used together with shallow renderer.
    (@goatslacker in #8097)
  • Added a warning for invalid aria- attributes.
    (@jessebeach in #7744)
  • Added a warning for using autofocus rather than autoFocus.
    (@hkal in #7694)
  • Removed an unnecessary warning about polyfilling String.prototype.split.
    (@nhunzaker in #7629)
  • Clarified the warning about not calling PropTypes manually.
    (@jedwards1211 in #7777)
  • The unstable batchedUpdates API now passes the wrapped function's return value through.
    (@bgnorlov in #7444)
  • Fixed a bug with updating text in IE 8.
    (@mnpenner in #7832)

React Perf

  • When ReactPerf is started, you can now view the relative time spent in components as a chart in Chrome Timeline.
    (@gaearon in #7549)

React Test Utils

  • If you call Simulate.click() on a <input disabled onClick={foo} /> then foo will get called whereas it didn't before.
    (@nhunzaker in #7642)

React Test Renderer

  • Due to packaging changes, it no longer crashes when imported together with React DOM in the same file.
    (@sebmarkbage in #7164 and #7168)
  • ReactTestRenderer.create() now accepts {createNodeMock: element => mock} as an optional argument so you can mock refs with snapshot testing.
    (@Aweary in #7649 and #8261)

Our First 50,000 Stars

September 28, 2016 by Vjeux


Just three and a half years ago we open sourced a little JavaScript library called React. The journey since that day has been incredibly exciting.

Commemorative T-Shirt

In order to celebrate 50,000 GitHub stars, Maggie Appleton from egghead.io has designed us a special T-shirt, which will be available for purchase from Teespring only for a week through Thursday, October 6. Maggie also wrote a blog post showing all the different concepts she came up with before settling on the final design.

React 50k Tshirt

The T-shirts are super soft using American Apparel's tri-blend fabric; we also have kids and toddler T-shirts and baby onesies available.

Proceeds from the shirts will be donated to CODE2040, a nonprofit that creates access, awareness, and opportunities in technology for underrepresented minorities with a specific focus on Black and Latinx talent.

Archeology

We've spent a lot of time trying to explain the concepts behind React and the problems it attempts to solve, but we haven't talked much about how React evolved before being open sourced. This milestone seemed like as good a time as any to dig through the earliest commits and share some of the more important moments and fun facts.

The story begins in our ads org, where we were building incredibly sophisticated client side web apps using an internal MVC framework called BoltJS. Here's a sample of what some Bolt code looked like:

var CarView = require('javelin/core').createClass({
  name: 'CarView',
  extend: require('container').Container,
  properties: {
    wheels: 4,
  },
  declare: function() {
    return {
      childViews: [
        { content: 'I have ' },
        { ref: 'wheelView' },
        { content: ' wheels' }
      ]
    };
  },
  setWheels: function(wheels) {
    this.findRef('wheelView').setContent(wheels);
  },
  getWheels: function() {
    return this.findRef('wheelView').getContent();
  },
});

var car = new CarView();
car.setWheels(3);
car.placeIn(document.body);
//<div>
//  <div>I have </div>
//  <div>3</div>
//  <div> wheels</div>
//</div>

Bolt introduced a number of APIs and features that would eventually make their way into React including render, createClass, and refs. Bolt introduced the concept of refs as a way to create references to nodes that can be used imperatively. This was relevant for legacy interoperability and incremental adoption, and while React would eventually strive to be a lot more functional, refs proved to be a very useful way to break out of the functional paradigm when the need arose.

But as our applications grew more and more sophisticated, our Bolt codebases got pretty complicated. Recognizing some of the framework's shortcomings, Jordan Walke started experimenting with a side-project called FaxJS. His goal was to solve many of the same problems as Bolt, but in a very different way. This is actually where most of React's fundamentals were born, including props, state, re-evaluating large portions of the tree to “diff” the UI, server-side rendering, and a basic concept of components.

TestProject.PersonDisplayer = {
  structure : function() {
    return Div({
      classSet: { personDisplayerContainer: true },
      titleDiv: Div({
        classSet: { personNameTitle: true },
        content: this.props.name
      }),
      nestedAgeDiv: Div({
        content: 'Interests: ' + this.props.interests
      })
    });
  }
};

FBolt is Born

Through his FaxJS experiment, Jordan became convinced that functional APIs — which discouraged mutation — offered a better, more scalable way to build user interfaces. He imported his library into Facebook's codebase in March of 2012 and renamed it “FBolt”, signifying an extension of Bolt where components are written in a functional programming style. Or maybe “FBolt” was a nod to FaxJS – he didn't tell us! ;)

The interoperability between FBolt and Bolt allowed us to experiment with replacing just one component at a time with more functional component APIs. We could test the waters of this new functional paradigm, without having to go all in. We started with the components that were clearly best expressed functionally and then we would later continue to push the boundaries of what we could express as functions.

Realizing that FBolt wouldn't be a great name for the library when used on its own, Jordan Walke and Tom Occhino decided on a new name: “React.” After Tom sent out the diff to rename everything to React, Jordan commented:

Jordan Walke: I might add for the sake of discussion, that many systems advertise some kind of reactivity, but they usually require that you set up some kind of point-to-point listeners and won't work on structured data. This API reacts to any state or property changes, and works with data of any form (as deeply structured as the graph itself) so I think the name is fitting.

Most of Tom's other commits at the time were on the first version of GraphiQL, a project which was recently open sourced.

Adding JSX

Since about 2010 Facebook has been using an extension of PHP called XHP, which enables engineers to create UIs using XML literals right inside their PHP code. It was first introduced to help prevent XSS holes but ended up being an excellent way to structure applications with custom components.

final class :a:post extends :x:element {
  attribute :a;
  protected function render(): XHPRoot {
    $anchor = <a>{$this->getChildren()}</a>;
    $form = (
      <form
        method="post"
        action={$this->:href}
        target={$this->:target}
        class="postLink"
      >{$anchor}</form>
    );
    $this->transferAllAttributes($anchor);
    return $form;
  }
}

Before Jordan's work had even made its way into the Facebook codebase, Adam Hupp implemented an XHP-like concept for JavaScript, written in Haskell. This system enabled you to write the following inside a JavaScript file:

function :example:hello(attrib, children) {
  return (
    <div class="special">
      <h1>Hello, World!</h1>
      {children}
    </div>
  );
}

It would compile the above into the following normal ES3-compatible JavaScript:

function jsx_example_hello(attrib, children) {
  return (
    S.create("div", {"class": "special"}, [
      S.create("h1", {}, ["Hello, World!"]),
      children
    ]
  );
}

In this prototype, S.create would immediately create and return a DOM node. Most of the conversations on this prototype revolved around the performance characteristics of innerHTML versus creating DOM nodes directly. At the time, it would have been less than ideal to push developers universally in the direction of creating DOM nodes directly since it did not perform as well, especially in Firefox and IE. Facebook's then-CTO Bret Taylor chimed in on the discussion at the time in favor of innerHTML over document.createElement:

Bret Taylor: If you are not convinced about innerHTML, here is a small microbenchmark. It is about the same in Chrome. innerHTML is about 30% faster in the latest version of Firefox (much more in previous versions), and about 90% faster in IE8.

This work was eventually abandoned but was revived after React made its way into the codebase. Jordan sidelined the previous performance discussions by introducing the concept of a “Virtual DOM,” though its eventual name didn't exist yet.

Jordan Walke: For the first step, I propose that we do the easiest, yet most general transformation possible. My suggestion is to simply map xml expressions to function call expressions.

  • <x></x> becomes x( )
  • <x height=12></x> becomes x( {height:12} )
  • <x> <y> </y> </x> becomes x({ childList: [y( )] })

At this point, JSX doesn't need to know about React - it's just a convenient way to write function calls. Coincidentally, React's primary abstraction is the function. Okay maybe it's not so coincidental ;)

Adam made a very insightful comment, which is now the default way we write lists in React with JSX.

Adam Hupp: I think we should just treat arrays of elements as a frag. This is useful for constructs like:

<ul>{foo.map(function(i) { return <li>{i.data}</li>; })}</ul>

In this case the ul(..) will get a childList with a single child, which is itself a list.

React didn't end up using Adam's implementation directly. Instead, we created JSX by forking js-xml-literal, a side project by XHP creator Marcel Laverdet. JSX took its name from js-xml-literal, which Jordan modified to just be syntactic sugar for deeply nested function calls.

API Churn

During the first year of React, internal adoption was growing quickly but there was quite a lot of churn in the component APIs and naming conventions:

  • project was renamed to declare then to structure and finally to render.
  • Componentize was renamed to createComponent and finally to createClass.

As the project was about to be open sourced, Lee Byron sat down with Jordan Walke, Tom Occhino and Sebastian Markbåge in order to refactor, reimplement, and rename one of React's most beloved features – the lifecycle API. Lee came up with a well-designed API that is still in place today.

  • Concepts
    • component - a ReactComponent instance
    • state - internal state to a component
    • props - external state to a component
    • markup - the stringy HTML-ish stuff components generate
    • DOM - the document and elements within the document
  • Actions
    • mount - to put a component into a DOM
    • initialize - to prepare a component for rendering
    • update - a transition of state (and props) resulting a render.
    • render - a side-effect-free process to get the representation (markup) of a component.
    • validate - make assertions about something created and provided
    • destroy - opposite of initialize
  • Operands
    • create - make a new thing
    • get - get an existing thing
    • set - merge into existing
    • replace - replace existing
    • receive - respond to new data
    • force - skip checks to do action
  • Notifications
    • shouldObjectAction
    • objectWillAction
    • objectDidAction

Instagram

In 2012, Instagram got acquired by Facebook. Pete Hunt, who was working on Facebook photos and videos at the time, joined their newly formed web team. He wanted to build their website completely in React, which was in stark contrast with the incremental adoption model that had been used at Facebook.

To make this happen, React had to be decoupled from Facebook's infrastructure, since Instagram didn't use any of it. This project acted as a forcing function to do the work needed to open source React. In the process, Pete also discovered and promoted a little project called webpack. He also implemented the renderToString primitive which was needed to do server-side rendering.

As we started to prepare for the open source launch, Maykel Loomans, a designer on Instagram, made a mock of what the website could look like. The header ended up defining the visual identity of React: its logo and the electric blue color!

React website mock

In its earliest days, React benefited tremendously from feedback, ideas, and technical contributions of early adopters and collaborators all over the company. While it might look like an overnight success in hindsight, the story of React is actually a great example of how new ideas often need to go through several rounds of refinement, iteration, and course correction over a long period of time before reaching their full potential.

React's approach to building user interfaces with functional programming principles has changed the way we do things in just a few short years. It goes without saying, but React would be nothing without the amazing open source community that's built up around it!