It looks like Ben Alpert is the first person outside of Facebook and Instagram to push React code to production. We are very grateful for his contributions in form of pull requests, bug reports and presence on IRC (#reactjs on Freenode). Ben wrote about his experience using React:
I just rewrote a 2000-line project in React and have now made a handful of pull requests to React. Everything about React I've seen so far seems really well thought-out and I'm proud to be the first non-FB/IG production user of React.
The project that I rewrote in React (and am continuing to improve) is the Khan Academy question editor which content creators can use to enter questions and hints that will be presented to students:
Pimp my Backbone.View (by replacing it with React) #
Paul Seiffert wrote a blog post that explains how to integrate React into Backbone applications.
React has some interesting concepts for JavaScript view objects that can be used to eliminate this one big problem I have with Backbone.js.
As in most MVC implementations (although React is probably just a VC implementation), a view is one portion of the screen that is managed by a controlling object. This object is responsible for deciding when to re-render the view and how to react to user input. With React, these view-controllers objects are called components. A component knows how to render its view and how to handle to the user's interaction with it.
The interesting thing is that React is figuring out by itself when to re-render a view and how to do this in the most efficient way.
Mario Mueller wrote a menu component in React and was able to easily integrate it with require.js, EventEmitter2 and bower.
I recently stumbled upon facebook's React library, which is a Javascript library for building reusable frontend components. Even if this lib is only at version 0.3.x it behaves very stable, it is fast and is fun to code. I'm a big fan of require.js, so I tried to use React within the require.js eco system. It was not as hard as expected and here are some examples and some thoughts about it.
React isn't quite like any other popular Javascript libraries, and it solves a very specific problem: complex UI rendering. It's also intended to be used along side many other popular libraries. For example, React works well with Backbone.js, amongst many others.
React was born out of frustrations with the common pattern of writing two-way data bindings in complex MVC apps. React is an implementation of one-way data bindings.
React is a library for building composable user interfaces. It encourages
the creation of reusable UI components which present data that changes over
time.
Traditionally, web application UIs are built using templates or HTML directives.
These templates dictate the full set of abstractions that you are allowed to use
to build your UI.
React approaches building user interfaces differently by breaking them into
components. This means React uses a real, full featured programming language
to render views, which we see as an advantage over templates for a few reasons:
JavaScript is a flexible, powerful programming language with the ability
to build abstractions. This is incredibly important in large applications.
By unifying your markup with its corresponding view logic, React can actually
make views easier to extend and maintain.
By baking an understanding of markup and content into JavaScript, there's
no manual string concatenation and therefore less surface area for XSS
vulnerabilities.
We've also created JSX, an optional syntax
extension, in case you prefer the readability of HTML to raw JavaScript.
React really shines when your data changes over time.
In a traditional JavaScript application, you need to look at what data changed
and imperatively make changes to the DOM to keep it up-to-date. Even AngularJS,
which provides a declarative interface via directives and data binding requires
a linking function to manually update DOM nodes.
React takes a different approach.
When your component is first initialized, the render method is called,
generating a lightweight representation of your view. From that representation,
a string of markup is produced, and injected into the document. When your data
changes, the render method is called again. In order to perform updates as
efficiently as possible, we diff the return value from the previous call to
render with the new one, and generate a minimal set of changes to be applied
to the DOM.
The data returned from render is neither a string nor a DOM node -- it's a
lightweight description of what the DOM should look like.
We call this process reconciliation. Check out
this jsFiddle to see an example of
reconciliation in action.
Because this re-render is so fast (around 1ms for TodoMVC), the developer
doesn't need to explicitly specify data bindings. We've found this approach
makes it easier to build apps.
Because React has its own lightweight representation of the document, we can do
some pretty cool things with it:
Facebook has dynamic charts that render to <canvas> instead of HTML.
Instagram is a "single page" web app built entirely with React and
Backbone.Router. Designers regularly contribute React code with JSX.
We've built internal prototypes that run React apps in a web worker and use
React to drive native iOS views via an Objective-C bridge.
You can run React
on the server
for SEO, performance, code sharing and overall flexibility.
Events behave in a consistent, standards-compliant way in all browsers
(including IE8) and automatically use
event delegation.
Head on over to facebook.github.io/react to check out what we have
built. Our documentation is geared towards building apps with the framework,
but if you are interested in the nuts and bolts
get in touch with us!
JSFiddle just announced support for React. This is an exciting news as it makes collaboration on snippets of code a lot easier. You can play around this base React JSFiddle, fork it and share it! A fiddle without JSX is also available.
React
