Many of the questions we got following the public launch of React revolved around props, specifically that people wanted to do validation and to make sure their components had sensible defaults.

Validation #

Oftentimes you want to validate your props before you use them. Perhaps you want to ensure they are a specific type. Or maybe you want to restrict your prop to specific values. Or maybe you want to make a specific prop required. This was always possible — you could have written validations in your render or componentWillReceiveProps functions, but that gets clunky fast.

React v0.4 will provide a nice easy way for you to use built-in validators, or to even write your own.

React.createClass({
  propTypes: {
    // An optional string prop named "description".
    description: React.PropTypes.string,

    // A required enum prop named "category".
    category: React.PropTypes.oneOf(['News','Photos']).isRequired,

    // A prop named "dialog" that requires an instance of Dialog.
    dialog: React.PropTypes.instanceOf(Dialog).isRequired
  },
  ...
});

Default Values #

One common pattern we've seen with our React code is to do something like this:

React.createClass({
  render: function() {
    var value = this.props.value || 'default value';
    return <div>{value}</div>;
  }
});

Do this for a few props across a few components and now you have a lot of redundant code. Starting with React v0.4, you can provide default values in a declarative way:

React.createClass({
  getDefaultProps: function() {
    return {
      value: 'default value'
    };
  }
  ...
});

We will use the cached result of this function before each render. We also perform all validations before each render to ensure that you have all of the data you need in the right form before you try to use it.

Both of these features are entirely optional. We've found them to be increasingly valuable at Facebook as our applications grow and evolve, and we hope others find them useful as well.

React reconciliation process appears to be very well suited to implement a text editor with a live preview as people at Khan Academy show us.

Khan Academy #

Ben Kamens explains how Ben Alpert and Joel Burget are promoting React inside of Khan Academy. They now have three projects in the works using React.

Recently two Khan Academy devs dropped into our team chat and said they were gonna use React to write a new feature. They even hinted that we may want to adopt it product-wide.

"The library is only a week old. It's a brand new way of thinking about things. We're the first to use it outside of Facebook. Heck, even the React devs were surprised to hear we're using this in production!!!"

Read the full post...

The best part is the demo of how React reconciliation process makes live editing more user-friendly.

Our renderer, post-React, is on the left. A typical math editor's preview is on the right.

React Snippets #

Over the past several weeks, members of our team, Pete Hunt and Paul O'Shannessy, answered many questions that were asked in the React group. They give a good overview of how to integrate React with other libraries and APIs through the use of Mixins and Lifecycle Methods.

Listening Scroll Event

• JSFiddle: Basically I've given you two mixins. The first lets you react to global scroll events. The second is, IMO, much more useful: it gives you scroll start and scroll end events, which you can use with setState() to create components that react based on whether the user is scrolling or not.

Fade-in Transition

• JSFiddle: Creating a new <FadeInWhenAdded> component and using jQuery .fadeIn() function on the DOM node.
• JSFiddle: Using CSS transition instead.

Socket.IO Integration

• Gist: The big thing to notice is that my component is pretty dumb (it doesn't have to be but that's how I chose to model it). All it does is render itself based on the props that are passed in. renderOrUpdate is where the "magic" happens.
• Gist: This example is doing everything -- including the IO -- inside of a single React component.
• Gist: One pattern that we use at Instagram a lot is to employ separation of concerns and consolidate I/O and state into components higher in the hierarchy to keep the rest of the components mostly stateless and purely display.

Sortable jQuery Plugin Integration

• JSFiddle: Your React component simply render empty divs, and then in componentDidMount() you call React.renderComponent() on each of those divs to set up a new root React tree. Be sure to explicitly unmountAndReleaseReactRootNode() for each component in componentWillUnmount().

Introduction to React Screencast #

Pete Hunt recorded himself implementing a simple <Blink> tag in React.

Snake in React #

Tom Occhino implemented Snake in 150 lines with React.

Check the source on Github

React v0.4 is very close to completion. As we finish it off, we'd like to share with you some of the major changes we've made since v0.3. This is the first of several posts we'll be making over the next week.

What is React.autoBind? #

If you take a look at most of our current examples, you'll see us using React.autoBind for event handlers. This is used in place of Function.prototype.bind. Remember that in JS, function calls are late-bound. That means that if you simply pass a function around, the this used inside won't necessarily be the this you expect. Function.prototype.bind creates a new, properly bound, function so that when called, this is exactly what you expect it to be.

Before we launched React, we would write this:

React.createClass({
  onClick: function(event) {/* do something with this */},
  render: function() {
    return <button onClick={this.onClick.bind(this)} />;
  }
});

We wrote React.autoBind as a way to cache the function creation and save on memory usage. Since render can get called multiple times, if you used this.onClick.bind(this) you would actually create a new function on each pass. With React v0.3 you were able to write this instead:

React.createClass({
  onClick: React.autoBind(function(event) {/* do something with this */}),
  render: function() {
    return <button onClick={this.onClick} />;
  }
});

What's Changing in v0.4? #

After using React.autoBind for a few weeks, we realized that there were very few times that we didn't want that behavior. So we made it the default! Now all methods defined within React.createClass will already be bound to the correct instance.

Starting with v0.4 you can just write this:

React.createClass({
  onClick: function(event) {/* do something with this */},
  render: function() {
    return <button onClick={this.onClick} />;
  }
});

For v0.4 we will simply be making React.autoBind a no-op — it will just return the function you pass to it. Most likely you won't have to change your code to account for this change, though we encourage you to update. We'll publish a migration guide documenting this and other changes that come along with React v0.4.

The highlight of this week is that an interaction-heavy app has been ported to React. React components are solving issues they had with nested views.

Moving From Backbone To React #

Clay Allsopp successfully ported Propeller, a fairly big, interaction-heavy JavaScript app, to React.

Subviews involve a lot of easy-to-forget boilerplate that Backbone (by design) doesn't automate. Libraries like Backbone.Marionette offer more abstractions to make view nesting easier, but they're all limited by the fact that Backbone delegates how and went view-document attachment occurs to the application code.

React, on the other hand, manages the DOM and only exposes real nodes at select points in its API. The "elements" you code in React are actually objects which wrap DOM nodes, not the actual objects which get inserted into the DOM. Internally, React converts those abstractions into actual DOMElements and fills out the document accordingly. [...]

We moved about 20 different Backbone view classes to React over the past few weeks, including the live-preview pane that you see in our little iOS demo. Most importantly, it's allowed us to put energy into making each component work great on its own, instead of spending extra cycles to ensure they function in unison. For that reason, we think React is a more scalable way to build view-intensive apps than Backbone alone, and it doesn't require you to drop-everything-and-refactor like a move to Ember or Angular would demand.

Read the full post...

Grunt Task for JSX #

Eric Clemmons wrote a task for Grunt that applies the JSX transformation to your Javascript files. It also works with Browserify if you want all your files to be concatenated and minified together.

Grunt task for compiling Facebook React's .jsx templates into .js

grunt.initConfig({
  react: {
    app: {
      options: { extension: 'js' },
      files: { 'path/to/output/dir': 'path/to/jsx/templates/dir' }

It also works great with grunt-browserify!

browserify: {
  options: {
    transform: [ require('grunt-react').browserify ]
  },
  app: {
    src: 'path/to/source/main.js',
    dest: 'path/to/target/output.js'

Check out the project ...

Backbone/Handlebars Nested Views #

Joel Burget wrote a blog post talking about the way we would write React-like components in Backbone and Handlebars.

The problem here is that we're trying to maniplate a tree, but there's a textual layer we have to go through. Our views are represented as a tree - the subviews are children of CommentCollectionView - and they end up as part of a tree in the DOM. But there's a Handlebars layer in the middle (which deals in flat strings), so the hierarchy must be destructed and rebuilt when we render.

What does it take to render a collection view? In the Backbone/Handlebars view of the world you have to render the template (with stubs), render each subview which replaces a stub, and keep a reference to each subview (or anything within the view that could change in the future).

So while our view is conceptually hierarchical, due to the fact that it has to go through a flat textual representation, we need to do a lot of extra work to reassemble that structure after rendering.

Read the full post...

JSRomandie Meetup #

Renault John Lecoultre from BugBuster did a React introduction talk at a JS meetup called JS Romandie last week.

CoffeeScript integration #

Vjeux used the fact that JSX is just a syntactic sugar on-top of regular JS to rewrite the React front-page examples in CoffeeScript.

Multiple people asked what's the story about JSX and CoffeeScript. There is no JSX pre-processor for CoffeeScript and I'm not aware of anyone working on it. Fortunately, CoffeeScript is pretty expressive and we can play around the syntax to come up with something that is usable.

{div, h3, textarea} = React.DOM
(div {className: 'MarkdownEditor'}, [
  (h3 {}, 'Input'),
  (textarea {onKeyUp: @handleKeyUp, ref: 'textarea'},
    @state.value
  )
])

Read the full post...

Tutorial in Plain Javascript #

We've seen a lot of people comparing React with various frameworks. Ricardo Tomasi decided to re-implement the tutorial without any framework, just plain Javascript.

Facebook & Instagram launched the React framework and an accompanying tutorial. Developer Vlad Yazhbin decided to rewrite that using AngularJS. The end result is pretty neat, but if you're like me you will not actually appreciate the HTML speaking for itself and doing all the hard work. So let's see what that looks like in plain javascript.

Read the full post...

We have a ton of great stuff coming in v0.4, but in the meantime we're releasing v0.3.3. This release addresses some small issues people were having and simplifies our tools to make them easier to use.

react-tools #

• Upgrade Commoner so require statements are no longer relativized when passing through the transformer. This was a feature needed when building React, but doesn't translate well for other consumers of bin/jsx.
• Upgraded our dependencies on Commoner and Recast so they use a different directory for their cache.
• Freeze our esprima dependency.

React #

• Allow reusing the same DOM node to render different components. e.g. React.renderComponent(<div/>, domNode); React.renderComponent(<span/>, domNode); will work now.

JSXTransformer #

• Improved the in-browser transformer so that transformed scripts will execute in the expected scope. The allows components to be defined and used from separate files.