We recently spoke at one of f8's breakout session about Flux, a data flow architecture that works well with React. Check out the video here:

To summarize, Flux works well for us because the single directional data flow makes it easy to understand and modify an application as it becomes more complicated. We found that two-way data bindings lead to cascading updates, where changing one data model led to another data model updating, making it very difficult to predict what would change as the result of a single user interaction.

In Flux, the Dispatcher is a singleton that directs the flow of data and ensures that updates do not cascade. As an application grows, the Dispatcher becomes more vital, as it can also manage dependencies between stores by invoking the registered callbacks in a specific order.

When a user interacts with a React view, the view sends an action (usually represented as a JavaScript object with some fields) through the dispatcher, which notifies the various stores that hold the application's data and business logic. When the stores change state, they notify the views that something has updated. This works especially well with React's declarative model, which allows the stores to send updates without specifying how to transition views between states.

Flux is more of a pattern than a formal framework, so you can start using Flux immediately without a lot of new code. An example of this architecture is available, along with more detailed documentation and a tutorial. Look for more examples to come in the future.

Today we're happy to announce the initial release of ReactJS.NET, which makes it easier to use React and JSX in .NET applications, focusing specifically on ASP.NET MVC web applications. It has several purposes:

• On-the-fly JSX to JavaScript compilation. Simply reference JSX files and they will be compiled and cached server-side.

   <script src="@Url.Content("/Scripts/HelloWorld.jsx")"></script>

• JSX to JavaScript compilation via popular minification/combination libraries (Cassette and ASP.NET Bundling and Minification). This is suggested for production websites.
• Server-side component rendering to make your initial render super fast.

Even though we are focusing on ASP.NET MVC, ReactJS.NET can also be used in Web Forms applications as well as non-web applications (for example, in build scripts). ReactJS.NET currently only works on Microsoft .NET but we are working on support for Linux and Mac OS X via Mono as well.

Installation #

ReactJS.NET is packaged in NuGet. Simply run Install-Package React.Mvc4 in the package manager console or search NuGet for "React" to install it. See the documentation for more information. The GitHub project contains a sample website demonstrating all of the features.

Let us know what you think, and feel free to send through any feedback and report bugs on GitHub.

When we launched React last spring, we purposefully decided not to call it 1.0. It was production ready, but we had plans to evolve APIs and behavior as we saw how people were using React, both internally and externally. We've learned a lot over the past 9 months and we've thought a lot about what 1.0 will mean for React. A couple weeks ago, I outlined several projects that we have planned to take us to 1.0 and beyond. Today I'm writing a bit more about them to give our users a better insight into our plans.

Our primary goal with 1.0 is to clarify our messaging and converge on an API that is aligned with our goals. In order to do that, we want to clean up bad patterns we've seen in use and really help enable developers write good code.

Descriptors #

The first part of this is what we're calling "descriptors". I talked about this briefly in our v0.10 announcements. The goal here is to separate our virtual DOM representation from our use of it. Simply, this means the return value of a component (e.g. React.DOM.div(), MyComponent()) will be a simple object containing the information React needs to render. Currently the object returned is actually linked to React's internal representation of the component and even directly to the DOM element. This has enabled some bad patterns that are quite contrary to how we want people to use React. That's our failure.

We added some warnings in v0.9 to start migrating some of these bad patterns. With v0.10 we'll catch more. You'll see more on this soon as we expect to ship v0.11 with descriptors.

API Cleanup #

This is really connected to everything. We want to keep the API as simple as possible and help developers fall into the pit of success. Enabling bad patterns with bad APIs is not success.

ES6 #

Before we even launched React publicly, members of the team were talking about how we could leverage ES6, namely classes, to improve the experience of creating React components. Calling React.createClass(...) isn't great. We don't quite have the right answer here yet, but we're close. We want to make sure we make this as simple as possible. It could look like this:

class MyComponent extends React.Component {
  render() {
    ...
  }
}

There are other features of ES6 we're already using in core. I'm sure we'll see more of that. The jsx executable we ship with react-tools already supports transforming many parts of ES6 into code that will run on older browsers.

Context #

While we haven't documented context, it exists in some form in React already. It exists as a way to pass values through a tree without having to use props at every single point. We've seen this need crop up time and time again, so we want to make this as easy as possible. Its use has performance tradeoffs, and there are known weaknesses in our implementation, so we want to make sure this is a solid feature.

Addons #

As you may know, we ship a separate build of React with some extra features we called "addons". While this has served us fine, it's not great for our users. It's made testing harder, but also results in more cache misses for people using a CDN. The problem we face is that many of these "addons" need access to parts of React that we don't expose publicly. Our goal is to ship each addon on its own and let each hook into React as needed. This would also allow others to write and distribute "addons".

Browser Support #

As much as we'd all like to stop supporting older browsers, it's not always possible. Facebook still supports IE8. While React won't support IE8 forever, our goal is to have 1.0 support IE8. Hopefully we can continue to abstract some of these rough parts.

Animations #

Finding a way to define animations in a declarative way is a hard problem. We've been exploring the space for a long time. We've introduced some half-measures to alleviate some use cases, but the larger problem remains. While we'd like to make this a part of 1.0, realistically we don't think we'll have a good solution in place.

Miscellaneous #

There are several other things I listed on our projects page that we're tracking. Some of them are internals and have no obvious outward effect (improve tests, repo separation, updated test runner). I encourage you to take a look.

Hot on the heels of the release candidate earlier this week, we're ready to call v0.10 done. The only major issue we discovered had to do with the react-tools package, which has been updated. We've copied over the changelog from the RC with some small clarifying changes.

The release is available for download from the CDN:

• React
  Dev build with warnings: https://fb.me/react-0.10.0.js
  Minified build for production: https://fb.me/react-0.10.0.min.js
  
• React with Add-Ons
  Dev build with warnings: https://fb.me/react-with-addons-0.10.0.js
  Minified build for production: https://fb.me/react-with-addons-0.10.0.min.js
  
• In-Browser JSX transformer
  https://fb.me/JSXTransformer-0.10.0.js

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

Please try these builds out and file an issue on GitHub if you see anything awry.

Clone On Mount #

The main purpose of this release is to provide a smooth upgrade path as we evolve some of the implementation of core. In v0.9 we started warning in cases where you called methods on unmounted components. This is part of an effort to enforce the idea that the return value of a component (React.DOM.div(), MyComponent()) is in fact not a reference to the component instance React uses in the virtual DOM. The return value is instead a light-weight object that React knows how to use. Since the return value currently is a reference to the same object React uses internally, we need to make this transition in stages as many people have come to depend on this implementation detail.

In 0.10, we’re adding more warnings to catch a similar set of patterns. When a component is mounted we clone it and use that object for our internal representation. This allows us to capture calls you think you’re making to a mounted component. We’ll forward them on to the right object, but also warn you that this is breaking. See “Access to the Mounted Instance” on this page. Most of the time you can solve your pattern by using refs.

Storing a reference to your top level component is a pattern touched upon on that page, but another examples that demonstrates what we see a lot of:

// This is a common pattern. However instance here really refers to a
// "descriptor", not necessarily the mounted instance.
var instance = <MyComponent/>;
React.renderComponent(instance);
// ...
instance.setProps(...);

// The change here is very simple. The return value of renderComponent will be
// the mounted instance.
var instance = React.renderComponent(<MyComponent/>)
// ...
instance.setProps(...);

These warnings and method forwarding are only enabled in the development build. The production builds continue to work as they did in v0.9. We strongly encourage you to use the development builds to catch these warnings and fix the call sites.

The plan for v0.11 is that we will go fully to "descriptors". Method calls on the return value of MyComponent() will fail hard.

Changelog #

React Core #

New Features #

• Added warnings to help migrate towards descriptors
• Made it possible to server render without React-related markup (data-reactid, data-react-checksum). This DOM will not be mountable by React. Read the docs for React.renderComponentToStaticMarkup
• Added support for more attributes:
  • srcSet for <img> to specify images at different pixel ratios
  • textAnchor for SVG

Bug Fixes #

• Ensure all void elements don’t insert a closing tag into the markup.
• Ensure className={false} behaves consistently
• Ensure this.refs is defined, even if no refs are specified.

Addons #

• update function to deal with immutable data. Read the docs

react-tools #

• Added an option argument to transform function. The only option supported is harmony, which behaves the same as jsx --harmony on the command line. This uses the ES6 transforms from jstransform.

v0.9 has only been out for a month, but we’re getting ready to push out v0.10 already. Unlike v0.9 which took a long time, we don't have a long list of changes to talk about.

The release candidate is available for download from the CDN:

• React
  Dev build with warnings: https://fb.me/react-0.10.0-rc1.js
  Minified build for production: https://fb.me/react-0.10.0-rc1.min.js
  
• React with Add-Ons
  Dev build with warnings: https://fb.me/react-with-addons-0.10.0-rc1.js
  Minified build for production: https://fb.me/react-with-addons-0.10.0-rc1.min.js
  
• In-Browser JSX transformer
  https://fb.me/JSXTransformer-0.10.0-rc1.js

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

Please try these builds out and file an issue on GitHub if you see anything awry.

Clone On Mount #

The main purpose of this release is to provide a smooth upgrade path as we evolve some of the implementation of core. In v0.9 we started warning in cases where you called methods on unmounted components. This is part of an effort to enforce the idea that the return value of a component (React.DOM.div(), MyComponent()) is in fact not a reference to the component instance React uses in the virtual DOM. The return value is instead a light-weight object that React knows how to use. Since the return value currently is a reference to the same object React uses internally, we need to make this transition in stages as many people have come to depend on this implementation detail.

In 0.10, we’re adding more warnings to catch a similar set of patterns. When a component is mounted we clone it and use that object for our internal representation. This allows us to capture calls you think you’re making to a mounted component. We’ll forward them on to the right object, but also warn you that this is breaking. See “Access to the Mounted Instance” on this page. Most of the time you can solve your pattern by using refs.

Storing a reference to your top level component is a pattern touched upon on that page, but another examples that demonstrates what we see a lot of:

// This is a common pattern. However instance here really refers to a
// "descriptor", not necessarily the mounted instance.
var instance = <MyComponent/>;
React.renderComponent(instance);
// ...
instance.setProps(...);

// The change here is very simple. The return value of renderComponent will be
// the mounted instance.
var instance = React.renderComponent(<MyComponent/>)
// ...
instance.setProps(...);

These warnings and method forwarding are only enabled in the development build. The production builds continue to work as they did in v0.9. We strongly encourage you to use the development builds to catch these warnings and fix the call sites.

The plan for v0.11 is that we will go fully to "descriptors". Method calls on the return value of MyComponent() will fail hard.

Changelog #

React Core #

New Features #

• Added warnings to help migrate towards descriptors
• Made it possible to server render without React-related markup (data-reactid, data-react-checksum). This DOM will not be mountable by React. Read the docs for React.renderComponentToStaticMarkup
• Added support for more attributes:
  • srcSet for <img> to specify images at different pixel ratios
  • textAnchor for SVG

Bug Fixes #

• Ensure all void elements don’t insert a closing tag into the markup.
• Ensure className={false} behaves consistently
• Ensure this.refs is defined, even if no refs are specified.

Addons #

• update function to deal with immutable data. Read the docs

react-tools #

• Added an option argument to transform function. The only option supported is harmony, which behaves the same as jsx --harmony on the command line. This uses the ES6 transforms from jstransform.