Today we're announcing the deprecation of react-tools and JSTransform.
+
+
As many people have noticed already, React and React Native have both switched their respective build systems to make use of Babel. This replaced JSTransform, the source transformation tool that we wrote at Facebook. JSTransform has been really good for us over the past several years, however as the JavaScript language continues to evolve, the architecture we used has begun to show its age. We've faced maintenance issues and lagged behind implementing new language features. Last year, Babel (previously 6to5) exploded onto the scene, implementing new features at an amazing pace. Since then it has evolved a solid plugin API, and implemented some of our non-standard language features (JSX and Flow type annotations).
+
+
react-tools has always been a very thin wrapper around JSTransform. It has served as a great tool for the community to get up and running, but at this point we're ready to let it go. We won't ship a new version for v0.14.
Many people in the React and broader JavaScript community have already adopted Babel. It has integrations with a number of tools. Depending on your tool, you'll want to read up on the instructions.
+
+
We've been working with the Babel team as we started making use of it and we're confident that it will be the right tool to use with React.
As a result of no longer maintaining JSTransform, we no longer have a need to maintain our Esprima fork (esprima-fb). The upstream Esprima and other esprima-based forks, like Espree, have been doing an excellent job of supporting new language features recently. If you have a need of an esprima-based parse, we encourage you to look into using one of those.
JSXTransformer is another tool we built specifically for consuming JSX in the browser. It was always intended as a quick way to prototype code before setting up a build process. It would look for <script> tags with type="text/jsx" and then transform and run. This ran the same code that react-tools ran on the server. Babel ships with a nearly identical tool, which has already been integrated into JS Bin.
+
+
We'll be deprecating JSXTransformer, however the current version will still be available from various CDNs and Bower.
Today we're announcing the deprecation of react-tools and JSTransform.
+
+
As many people have noticed already, React and React Native have both switched their respective build systems to make use of Babel. This replaced JSTransform, the source transformation tool that we wrote at Facebook. JSTransform has been really good for us over the past several years, however as the JavaScript language continues to evolve, the architecture we used has begun to show its age. We've faced maintenance issues and lagged behind implementing new language features. Last year, Babel (previously 6to5) exploded onto the scene, implementing new features at an amazing pace. Since then it has evolved a solid plugin API, and implemented some of our non-standard language features (JSX and Flow type annotations).
+
+
react-tools has always been a very thin wrapper around JSTransform. It has served as a great tool for the community to get up and running, but at this point we're ready to let it go. We won't ship a new version for v0.14.
Many people in the React and broader JavaScript community have already adopted Babel. It has integrations with a number of tools. Depending on your tool, you'll want to read up on the instructions.
+
+
We've been working with the Babel team as we started making use of it and we're confident that it will be the right tool to use with React.
As a result of no longer maintaining JSTransform, we no longer have a need to maintain our Esprima fork (esprima-fb). The upstream Esprima and other esprima-based forks, like Espree, have been doing an excellent job of supporting new language features recently. If you have a need of an esprima-based parse, we encourage you to look into using one of those.
JSXTransformer is another tool we built specifically for consuming JSX in the browser. It was always intended as a quick way to prototype code before setting up a build process. It would look for <script> tags with type="text/jsx" and then transform and run. This ran the same code that react-tools ran on the server. Babel ships with a nearly identical tool, which has already been integrated into JS Bin.
+
+
We'll be deprecating JSXTransformer, however the current version will still be available from various CDNs and Bower.
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
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.
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.
It's exciting to see the number of real-world React applications and components skyrocket over the past months! This community round-up features a few examples of inspiring React applications and components.
Large parts of Facebook's web frontend are already powered by React. The recently released Facebook Lookback video and its corresponding editor are great examples of a complex, real-world React app.
Relato by Ben Ripkens shows Open Source Statistics based on npm data. It features a filterable and sortable table built in React. Check it out – it's super fast!
John Lynch (@johnrlynch) created Makona, a block-style document editor for the web. Blocks of different content types comprise documents, authored using plain markup. At the switch of a toggle, block contents are then rendered on the page. While not quite a WYSIWYG editor, Makona uses plain textareas for input. This makes it compatible with a wider range of platforms than traditional rich text editors.
+
Sproutsheet is a gardening calendar. You can use it to track certain events that happen in the life of your plants. It's currently in beta and supports localStorage, and data/image import and export.
Emanuele Rampichini's ReactJS Gallery is a cool demo app that shows fullscreen images from a folder on the server. If the folder content changes, the gallery app updates via websockets.
react-input=placeholder by enigma-io is a small wrapper around React.DOM.input that shims in placeholder functionality for browsers that don't natively support it.
Recent changes: web ui is being upgraded to [#reactjs](https://twitter.com/search?q=%23reactjs&src=hash), HEAD~4 at [https://camlistore.googlesource.com/camlistore/](https://camlistore.googlesource.com/camlistore/)
The theme of this first round-up of 2014 is integration. I've tried to assemble a list of articles and projects that use React in various environments.
React is only one-piece of your web application stack. Mark Lussier shared his baseline stack that uses React along with Grunt, Browserify, Bower, Zepto, Director and Sass. This should help you get started using React for a new project.
-
-
-
As I do more projects with ReactJS I started to extract a baseline to use when starting new projects. This is very opinionated and I change my opinion from time to time. This is by no ways perfect and in your opinion most likely wrong :).. which is why I love github
-
-
I encourage you to fork, and make it right and submit a pull request!
-
-
My current opinion is using tools like Grunt, Browserify, Bower and mutiple grunt plugins to get the job done. I also opted for Zepto over jQuery and the Flatiron Project's Director when I need a router. Oh and for the last little bit of tech that makes you mad, I am in the SASS camp when it comes to stylesheets
Guillaume Rivals implemented an InfiniteScroll component. This is a good example of a React component that has a simple yet powerful API.
-
<InfiniteScroll
- pageStart={0}
- loadMore={loadFunc}
- hasMore={true||false}
- loader={<divclassName="loader">Loading...</div>}>
- {items}// <-- This is the "stuff" you want to load
-</InfiniteScroll>
-
React is often compared with Angular. Pete Hunt wrote an opinionated post on the subject.
-
-
-
First of all I think it’s important to evaluate technologies on objective rather than subjective features. “It feels nicer” or “it’s cleaner” aren’t valid reasons: performance, modularity, community size and ease of testing / integration with other tools are.
-
-
I’ve done a lot of work benchmarking, building apps, and reading the code of Angular to try to come up with a reasonable comparison between their ways of doing things.
The theme of this first round-up of 2014 is integration. I've tried to assemble a list of articles and projects that use React in various environments.
React is only one-piece of your web application stack. Mark Lussier shared his baseline stack that uses React along with Grunt, Browserify, Bower, Zepto, Director and Sass. This should help you get started using React for a new project.
+
+
+
As I do more projects with ReactJS I started to extract a baseline to use when starting new projects. This is very opinionated and I change my opinion from time to time. This is by no ways perfect and in your opinion most likely wrong :).. which is why I love github
+
+
I encourage you to fork, and make it right and submit a pull request!
+
+
My current opinion is using tools like Grunt, Browserify, Bower and mutiple grunt plugins to get the job done. I also opted for Zepto over jQuery and the Flatiron Project's Director when I need a router. Oh and for the last little bit of tech that makes you mad, I am in the SASS camp when it comes to stylesheets
Guillaume Rivals implemented an InfiniteScroll component. This is a good example of a React component that has a simple yet powerful API.
+
<InfiniteScroll
+ pageStart={0}
+ loadMore={loadFunc}
+ hasMore={true||false}
+ loader={<divclassName="loader">Loading...</div>}>
+ {items}// <-- This is the "stuff" you want to load
+</InfiniteScroll>
+
React is often compared with Angular. Pete Hunt wrote an opinionated post on the subject.
+
+
+
First of all I think it’s important to evaluate technologies on objective rather than subjective features. “It feels nicer” or “it’s cleaner” aren’t valid reasons: performance, modularity, community size and ease of testing / integration with other tools are.
+
+
I’ve done a lot of work benchmarking, building apps, and reading the code of Angular to try to come up with a reasonable comparison between their ways of doing things.
Today we're releasing an update to address a potential XSS vulnerability that can arise when using user data as a key. Typically "safe" data is used for a key, for example, an id from your database, or a unique hash. However there are cases where it may be reasonable to use user generated content. A carefully crafted piece of content could result in arbitrary JS execution. While we make a very concerted effort to ensure all text is escaped before inserting it into the DOM, we missed one case. Immediately following the discovery of this vulnerability, we performed an audit to ensure we this was the only such vulnerability.
-
-
This only affects v0.5.x and v0.4.x. Versions in the 0.3.x family are unaffected.
-
-
Updated versions are available for immediate download via npm, bower, and on our download page.
-
-
We take security very seriously at Facebook. For most of our products, users don't need to know that a security issue has been fixed. But with libraries like React, we need to make sure developers using React have access to fixes to keep their users safe.
-
-
While we've encouraged responsible disclosure as part of Facebook's whitehat bounty program since we launched, we don't have a good process for notifying our users. Hopefully we don't need to use it, but moving forward we'll set up a little bit more process to ensure the safety of our users. Ember.js has an excellent policy which we may use as our model.
-
-
You can learn more about the vulnerability discussed here: CVE-2013-7035.
Today we're releasing an update to address a potential XSS vulnerability that can arise when using user data as a key. Typically "safe" data is used for a key, for example, an id from your database, or a unique hash. However there are cases where it may be reasonable to use user generated content. A carefully crafted piece of content could result in arbitrary JS execution. While we make a very concerted effort to ensure all text is escaped before inserting it into the DOM, we missed one case. Immediately following the discovery of this vulnerability, we performed an audit to ensure we this was the only such vulnerability.
+
+
This only affects v0.5.x and v0.4.x. Versions in the 0.3.x family are unaffected.
+
+
Updated versions are available for immediate download via npm, bower, and on our download page.
+
+
We take security very seriously at Facebook. For most of our products, users don't need to know that a security issue has been fixed. But with libraries like React, we need to make sure developers using React have access to fixes to keep their users safe.
+
+
While we've encouraged responsible disclosure as part of Facebook's whitehat bounty program since we launched, we don't have a good process for notifying our users. Hopefully we don't need to use it, but moving forward we'll set up a little bit more process to ensure the safety of our users. Ember.js has an excellent policy which we may use as our model.
+
+
You can learn more about the vulnerability discussed here: CVE-2013-7035.
+
+
+
+
+
+
+
+
+
+
+
Community Round-up #11
@@ -433,111 +472,6 @@ Is this some sort of template language? Specifically no. This might have been th
-
We organized a React hackathon last week-end in the Facebook Seattle office. 50 people, grouped into 15 teams, came to hack for a day on React. It was a lot of fun and we'll probably organize more in the future.
Alex Swan implemented Qu.izti.me, a multi-player quiz game. It is real-time via Web Socket and mobile friendly.
-
-
-
The game itself is pretty simple. People join the "room" by going to http://qu.izti.me on their device. Large displays will show a leaderboard along with the game, and small displays (such as phones) will act as personal gamepads. Users will see questions and a choice of answers. The faster you answer, the more points you earn.
-
-
In my opinion, Socket.io and React go together like chocolate and peanut butter. The page was always an accurate representation of the game object.
-
Alexander Solovyov has been working on React bindings for ClojureScript. This is really exciting as it is using "native" ClojureScript data structures.
A wrapper around JSHint to allow linting of files containg JSX syntax. Accepts glob patterns. Respects your local .jshintrc file and .gitignore to filter your glob patterns.
Ross Allen working at Mesosphere combined Turbolinks, a library used by Ruby on Rails to speed up page transition, and React.
-
-
-
"Re-request this page" is just a link to the current page. When you click it, Turbolinks intercepts the GET request and fetchs the full page via XHR.
-
-
The panel is rendered with a random panel- class on each request, and the progress bar gets a random widthX class.
-
-
With Turbolinks alone, the entire
would be replaced, and transitions would not happen. In this little demo though, React adds and removes classes and text, and the attribute changes are animated with CSS transitions. The DOM is otherwise left intact.
-
-
-
You see that React components are defined using a regular JS object. Some properties and methods of the object such as render() have special meanings, the rest is upforgrabs.
We organized a React hackathon last week-end in the Facebook Seattle office. 50 people, grouped into 15 teams, came to hack for a day on React. It was a lot of fun and we'll probably organize more in the future.
Alex Swan implemented Qu.izti.me, a multi-player quiz game. It is real-time via Web Socket and mobile friendly.
+
+
+
The game itself is pretty simple. People join the "room" by going to http://qu.izti.me on their device. Large displays will show a leaderboard along with the game, and small displays (such as phones) will act as personal gamepads. Users will see questions and a choice of answers. The faster you answer, the more points you earn.
+
+
In my opinion, Socket.io and React go together like chocolate and peanut butter. The page was always an accurate representation of the game object.
+
Alexander Solovyov has been working on React bindings for ClojureScript. This is really exciting as it is using "native" ClojureScript data structures.
A wrapper around JSHint to allow linting of files containg JSX syntax. Accepts glob patterns. Respects your local .jshintrc file and .gitignore to filter your glob patterns.
Ross Allen working at Mesosphere combined Turbolinks, a library used by Ruby on Rails to speed up page transition, and React.
+
+
+
"Re-request this page" is just a link to the current page. When you click it, Turbolinks intercepts the GET request and fetchs the full page via XHR.
+
+
The panel is rendered with a random panel- class on each request, and the progress bar gets a random widthX class.
+
+
With Turbolinks alone, the entire
would be replaced, and transitions would not happen. In this little demo though, React adds and removes classes and text, and the attribute changes are animated with CSS transitions. The DOM is otherwise left intact.
+
+
+
You see that React components are defined using a regular JS object. Some properties and methods of the object such as render() have special meanings, the rest is upforgrabs.
To make react.js available for use client-side, simply add react to your manifest, and declare the variant you'd like to use in your environment. When you use :production, the minified and optimized react.min.js will be used instead of the development version. For example:
-
# config/environments/development.rb
-
-MyApp::Application.configuredo
- config.react.variant=:development
- # use :production in production.rb
-end
-
When you name your file with myfile.js.jsx, react-rails will automatically try to transform that file. For the time being, we still require that you include the docblock at the beginning of the file. For example, this file will get transformed on request.
react-rails takes advantage of the asset pipeline that was introduced in Rails 3.1. A very important part of that pipeline is the assets:precompile Rake task. react-rails will ensure that your JSX files will be transformed into regular JS before all of your assets are minified and packaged.
Installation follows the same process you're familiar with. You can install it globally with gem install react-rails, though we suggest you add the dependency to your Gemfile directly.
To make react.js available for use client-side, simply add react to your manifest, and declare the variant you'd like to use in your environment. When you use :production, the minified and optimized react.min.js will be used instead of the development version. For example:
+
# config/environments/development.rb
+
+MyApp::Application.configuredo
+ config.react.variant=:development
+ # use :production in production.rb
+end
+
When you name your file with myfile.js.jsx, react-rails will automatically try to transform that file. For the time being, we still require that you include the docblock at the beginning of the file. For example, this file will get transformed on request.
react-rails takes advantage of the asset pipeline that was introduced in Rails 3.1. A very important part of that pipeline is the assets:precompile Rake task. react-rails will ensure that your JSX files will be transformed into regular JS before all of your assets are minified and packaged.
Installation follows the same process you're familiar with. You can install it globally with gem install react-rails, though we suggest you add the dependency to your Gemfile directly.
+
+
+
+
+
+
+
+
+
+
+
React v0.4.1
@@ -382,94 +437,6 @@ If you were using React without JSX previously, your code should still work.
-
-
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!!!"
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.
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.
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.
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().
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!!!"
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.
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.
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.
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().
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.
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.
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
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.
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.
The most notable new feature is support for ES6 classes, which allows developers to have more flexibility when writing components. Our eventual goal is for ES6 classes to replace React.createClass completely, but until we have a replacement for current mixin use cases and support for class property initializers in the language, we don't plan to deprecate React.createClass.
-
-
At EmberConf and ng-conf last week, we were excited to see that Ember and Angular have been working on speed improvements and now both have performance comparable to React. We've always thought that performance isn't the most important reason to choose React, but we're still planning more optimizations to make React even faster.
-
-
Our planned optimizations require that ReactElement objects are immutable, which has always been a best practice when writing idiomatic React code. In this release, we've added runtime warnings that fire when props are changed or added between the time an element is created and when it's rendered. When migrating your code, you may want to use new React.cloneElement API (which is similar to React.addons.cloneWithProps but preserves key and ref and does not merge style or className automatically). For more information about our planned optimizations, see GitHub issues
-#3226,
-#3227,
-#3228.
Deprecated patterns that warned in 0.12 no longer work: most prominently, calling component classes without using JSX or React.createElement and using non-component functions with JSX or createElement
-
Mutating props after an element is created is deprecated and will cause warnings in development mode; future versions of React will incorporate performance optimizations assuming that props aren't mutated
-
Static methods (defined in statics) are no longer autobound to the component class
-
ref resolution order has changed slightly such that a ref to a component is available immediately after its componentDidMount method is called; this change should be observable only if your component calls a parent component's callback within your componentDidMount, which is an anti-pattern and should be avoided regardless
-
Calls to setState in life-cycle methods are now always batched and therefore asynchronous. Previously the first call on the first mount was synchronous.
-
setState and forceUpdate on an unmounted component now warns instead of throwing. That avoids a possible race condition with Promises.
-
Access to most internal properties has been completely removed, including this._pendingState and this._rootNodeID.
Support for using ES6 classes to build React components; see the v0.13.0 beta 1 notes for details.
-
Added new top-level API React.findDOMNode(component), which should be used in place of component.getDOMNode(). The base class for ES6-based components will not have getDOMNode. This change will enable some more patterns moving forward.
-
Added a new top-level API React.cloneElement(el, props) for making copies of React elements – see the v0.13 RC2 notes for more details.
-
New ref style, allowing a callback to be used in place of a name: <Photo ref={(c) => this._photo = c} /> allows you to reference the component with this._photo (as opposed to ref="photo" which gives this.refs.photo).
-
this.setState() can now take a function as the first argument for transactional state updates, such as this.setState((state, props) => ({count: state.count + 1})); – this means that you no longer need to use this._pendingState, which is now gone.
-
Support for iterators and immutable-js sequences as children.
ComponentClass.type is deprecated. Just use ComponentClass (usually as element.type === ComponentClass).
-
Some methods that are available on createClass-based components are removed or deprecated from ES6 classes (getDOMNode, replaceState, isMounted, setProps, replaceProps).
When transforming ES6 syntax, class methods are no longer enumerable by default, which requires Object.defineProperty; if you support browsers such as IE8, you can pass --target es3 to mirror the old behavior
--target option is available on the jsx command, allowing users to specify and ECMAScript version to target.
-
-
-
es5 is the default.
-
es3 restores the previous default behavior. An additional transform is added here to ensure the use of reserved words as properties is safe (eg this.static will become this['static'] for IE8 compatibility).
-
-
The transform for the call spread operator has also been enabled.
A change was made to how some JSX was parsed, specifically around the use of > or } when inside an element. Previously it would be treated as a string but now it will be treated as a parse error. The jsx_orphaned_brackets_transformer package on npm can be used to find and fix potential issues in your JSX code.
The most notable new feature is support for ES6 classes, which allows developers to have more flexibility when writing components. Our eventual goal is for ES6 classes to replace React.createClass completely, but until we have a replacement for current mixin use cases and support for class property initializers in the language, we don't plan to deprecate React.createClass.
+
+
At EmberConf and ng-conf last week, we were excited to see that Ember and Angular have been working on speed improvements and now both have performance comparable to React. We've always thought that performance isn't the most important reason to choose React, but we're still planning more optimizations to make React even faster.
+
+
Our planned optimizations require that ReactElement objects are immutable, which has always been a best practice when writing idiomatic React code. In this release, we've added runtime warnings that fire when props are changed or added between the time an element is created and when it's rendered. When migrating your code, you may want to use new React.cloneElement API (which is similar to React.addons.cloneWithProps but preserves key and ref and does not merge style or className automatically). For more information about our planned optimizations, see GitHub issues
+#3226,
+#3227,
+#3228.
Deprecated patterns that warned in 0.12 no longer work: most prominently, calling component classes without using JSX or React.createElement and using non-component functions with JSX or createElement
+
Mutating props after an element is created is deprecated and will cause warnings in development mode; future versions of React will incorporate performance optimizations assuming that props aren't mutated
+
Static methods (defined in statics) are no longer autobound to the component class
+
ref resolution order has changed slightly such that a ref to a component is available immediately after its componentDidMount method is called; this change should be observable only if your component calls a parent component's callback within your componentDidMount, which is an anti-pattern and should be avoided regardless
+
Calls to setState in life-cycle methods are now always batched and therefore asynchronous. Previously the first call on the first mount was synchronous.
+
setState and forceUpdate on an unmounted component now warns instead of throwing. That avoids a possible race condition with Promises.
+
Access to most internal properties has been completely removed, including this._pendingState and this._rootNodeID.
Support for using ES6 classes to build React components; see the v0.13.0 beta 1 notes for details.
+
Added new top-level API React.findDOMNode(component), which should be used in place of component.getDOMNode(). The base class for ES6-based components will not have getDOMNode. This change will enable some more patterns moving forward.
+
Added a new top-level API React.cloneElement(el, props) for making copies of React elements – see the v0.13 RC2 notes for more details.
+
New ref style, allowing a callback to be used in place of a name: <Photo ref={(c) => this._photo = c} /> allows you to reference the component with this._photo (as opposed to ref="photo" which gives this.refs.photo).
+
this.setState() can now take a function as the first argument for transactional state updates, such as this.setState((state, props) => ({count: state.count + 1})); – this means that you no longer need to use this._pendingState, which is now gone.
+
Support for iterators and immutable-js sequences as children.
ComponentClass.type is deprecated. Just use ComponentClass (usually as element.type === ComponentClass).
+
Some methods that are available on createClass-based components are removed or deprecated from ES6 classes (getDOMNode, replaceState, isMounted, setProps, replaceProps).
When transforming ES6 syntax, class methods are no longer enumerable by default, which requires Object.defineProperty; if you support browsers such as IE8, you can pass --target es3 to mirror the old behavior
--target option is available on the jsx command, allowing users to specify and ECMAScript version to target.
+
+
+
es5 is the default.
+
es3 restores the previous default behavior. An additional transform is added here to ensure the use of reserved words as properties is safe (eg this.static will become this['static'] for IE8 compatibility).
+
+
The transform for the call spread operator has also been enabled.
A change was made to how some JSX was parsed, specifically around the use of > or } when inside an element. Previously it would be treated as a string but now it will be treated as a parse error. The jsx_orphaned_brackets_transformer package on npm can be used to find and fix potential issues in your JSX code.
There's more to building an application than creating a user interface. Data fetching is still a tricky problem, especially as applications become more complicated. At React.js Conf we announced two projects we've created at Facebook to make data fetching simple for developers, even as a product grows to include dozens of contributors and the application becomes as complex as Facebook itself.
-
-
-
-
The two projects — Relay and GraphQL — have been in use in production at Facebook for some time, and we're excited to be bringing them to the world as open source in the future. In the meantime, we wanted to share some additional information about the projects here.
Relay is a new framework from Facebook that provides data-fetching functionality for React applications. It was announced at React.js Conf (January 2015).
-
-
Each component specifies its own data dependencies declaratively using a query language called GraphQL. The data is made available to the component via properties on this.props.
-
-
Developers compose these React components naturally, and Relay takes care of composing the data queries into efficient batches, providing each component with exactly the data that it requested (and no more), updating those components when the data changes, and maintaining a client-side store (cache) of all data.
GraphQL is a data querying language designed to describe the complex, nested data dependencies of modern applications. It's been in production use in Facebook's native apps for several years.
-
-
On the server, we configure the GraphQL system to map queries to underlying data-fetching code. This configuration layer allows GraphQL to work with arbitrary underlying storage mechanisms. Relay uses GraphQL as its query language, but it is not tied to a specific implementation of GraphQL.
Relay was born out of our experiences building large applications at Facebook. Our overarching goal is to enable developers to create correct, high-performance applications in a straightforward and obvious way. The design enables even large teams to make changes with a high degree of isolation and confidence. Fetching data is hard, dealing with ever-changing data is hard, and performance is hard. Relay aims to reduce these problems to simple ones, moving the tricky bits into the framework and freeing you to concentrate on building your application.
-
-
By co-locating the queries with the view code, the developer can reason about what a component is doing by looking at it in isolation; it's not necessary to consider the context where the component was rendered in order to understand it. Components can be moved anywhere in a render hierarchy without having to apply a cascade of modifications to parent components or to the server code which prepares the data payload.
-
-
Co-location leads developers to fall into the "pit of success", because they get exactly the data they asked for and the data they asked for is explicitly defined right next to where it is used. This means that performance becomes the default (it becomes much harder to accidentally over-fetch), and components are more robust (under-fetching is also less likely for the same reason, so components won't try to render missing data and blow up at runtime).
-
-
Relay provides a predictable environment for developers by maintaining an invariant: a component won't be rendered until all the data it requested is available. Additionally, queries are defined statically (ie. we can extract queries from a component tree before rendering) and the GraphQL schema provides an authoritative description of what queries are valid, so we can validate queries early and fail fast when the developer makes a mistake.
-
-
Only the fields of an object that a component explicitly asks for will be accessible to that component, even if other fields are known and cached in the store (because another component requested them). This makes it impossible for implicit data dependency bugs to exist latently in the system.
-
-
By handling all data-fetching via a single abstraction, we're able to handle a bunch of things that would otherwise have to be dealt with repeatedly and pervasively across the application:
-
-
-
Performance: All queries flow through the framework code, where things that would otherwise be inefficient, repeated query patterns get automatically collapsed and batched into efficient, minimal queries. Likewise, the framework knows which data have been previously requested, or for which requests are currently "in flight", so queries can be automatically de-duplicated and the minimal queries can be produced.
-
Subscriptions: All data flows into a single store, and all reads from the store are via the framework. This means the framework knows which components care about which data and which should be re-rendered when data changes; components never have to set up individual subscriptions.
-
Common patterns: We can make common patterns easy. Pagination is the example that Jing gave at the conference: if you have 10 records initially, getting the next page just means declaring you want 15 records in total, and the framework automatically constructs the minimal query to grab the delta between what you have and what you need, requests it, and re-renders your view when the data become available.
-
Simplified server implementation: Rather than having a proliferation of end-points (per action, per route), a single GraphQL endpoint can serve as a facade for any number of underlying resources.
-
Uniform mutations: There is one consistent pattern for performing mutations (writes), and it is conceptually baked into the data querying model itself. You can think of a mutation as a query with side-effects: you provide some parameters that describe the change to be made (eg. attaching a comment to a record) and a query that specifies the data you'll need to update your view of the world after the mutation completes (eg. the comment count on the record), and the data flows through the system using the normal flow. We can do an immediate "optimistic" update on the client (ie. update the view under the assumption that the write will succeed), and finally commit it, retry it or roll it back in the event of an error when the server payload comes back.
In some ways Relay is inspired by Flux, but the mental model is much simpler. Instead of multiple stores, there is one central store that caches all GraphQL data. Instead of explicit subscriptions, the framework itself can track which data each component requests, and which components should be updated whenever the data change. Instead of actions, modifications take the form of mutations.
-
-
At Facebook, we have apps built entirely using Flux, entirely using Relay, or with both. One pattern we see emerging is letting Relay manage the bulk of the data flow for an application, but using Flux stores on the side to handle a subset of application state.
We're working very hard right now on getting both GraphQL (a spec, and a reference implementation) and Relay ready for public release (no specific dates yet, but we are super excited about getting these out there).
-
-
In the meantime, we'll be providing more and more information in the form of blog posts (and in other channels). As we get closer to the open source release, you can expect more concrete details, syntax and API descriptions and more.
There's more to building an application than creating a user interface. Data fetching is still a tricky problem, especially as applications become more complicated. At React.js Conf we announced two projects we've created at Facebook to make data fetching simple for developers, even as a product grows to include dozens of contributors and the application becomes as complex as Facebook itself.
+
+
+
+
The two projects — Relay and GraphQL — have been in use in production at Facebook for some time, and we're excited to be bringing them to the world as open source in the future. In the meantime, we wanted to share some additional information about the projects here.
Relay is a new framework from Facebook that provides data-fetching functionality for React applications. It was announced at React.js Conf (January 2015).
+
+
Each component specifies its own data dependencies declaratively using a query language called GraphQL. The data is made available to the component via properties on this.props.
+
+
Developers compose these React components naturally, and Relay takes care of composing the data queries into efficient batches, providing each component with exactly the data that it requested (and no more), updating those components when the data changes, and maintaining a client-side store (cache) of all data.
GraphQL is a data querying language designed to describe the complex, nested data dependencies of modern applications. It's been in production use in Facebook's native apps for several years.
+
+
On the server, we configure the GraphQL system to map queries to underlying data-fetching code. This configuration layer allows GraphQL to work with arbitrary underlying storage mechanisms. Relay uses GraphQL as its query language, but it is not tied to a specific implementation of GraphQL.
Relay was born out of our experiences building large applications at Facebook. Our overarching goal is to enable developers to create correct, high-performance applications in a straightforward and obvious way. The design enables even large teams to make changes with a high degree of isolation and confidence. Fetching data is hard, dealing with ever-changing data is hard, and performance is hard. Relay aims to reduce these problems to simple ones, moving the tricky bits into the framework and freeing you to concentrate on building your application.
+
+
By co-locating the queries with the view code, the developer can reason about what a component is doing by looking at it in isolation; it's not necessary to consider the context where the component was rendered in order to understand it. Components can be moved anywhere in a render hierarchy without having to apply a cascade of modifications to parent components or to the server code which prepares the data payload.
+
+
Co-location leads developers to fall into the "pit of success", because they get exactly the data they asked for and the data they asked for is explicitly defined right next to where it is used. This means that performance becomes the default (it becomes much harder to accidentally over-fetch), and components are more robust (under-fetching is also less likely for the same reason, so components won't try to render missing data and blow up at runtime).
+
+
Relay provides a predictable environment for developers by maintaining an invariant: a component won't be rendered until all the data it requested is available. Additionally, queries are defined statically (ie. we can extract queries from a component tree before rendering) and the GraphQL schema provides an authoritative description of what queries are valid, so we can validate queries early and fail fast when the developer makes a mistake.
+
+
Only the fields of an object that a component explicitly asks for will be accessible to that component, even if other fields are known and cached in the store (because another component requested them). This makes it impossible for implicit data dependency bugs to exist latently in the system.
+
+
By handling all data-fetching via a single abstraction, we're able to handle a bunch of things that would otherwise have to be dealt with repeatedly and pervasively across the application:
+
+
+
Performance: All queries flow through the framework code, where things that would otherwise be inefficient, repeated query patterns get automatically collapsed and batched into efficient, minimal queries. Likewise, the framework knows which data have been previously requested, or for which requests are currently "in flight", so queries can be automatically de-duplicated and the minimal queries can be produced.
+
Subscriptions: All data flows into a single store, and all reads from the store are via the framework. This means the framework knows which components care about which data and which should be re-rendered when data changes; components never have to set up individual subscriptions.
+
Common patterns: We can make common patterns easy. Pagination is the example that Jing gave at the conference: if you have 10 records initially, getting the next page just means declaring you want 15 records in total, and the framework automatically constructs the minimal query to grab the delta between what you have and what you need, requests it, and re-renders your view when the data become available.
+
Simplified server implementation: Rather than having a proliferation of end-points (per action, per route), a single GraphQL endpoint can serve as a facade for any number of underlying resources.
+
Uniform mutations: There is one consistent pattern for performing mutations (writes), and it is conceptually baked into the data querying model itself. You can think of a mutation as a query with side-effects: you provide some parameters that describe the change to be made (eg. attaching a comment to a record) and a query that specifies the data you'll need to update your view of the world after the mutation completes (eg. the comment count on the record), and the data flows through the system using the normal flow. We can do an immediate "optimistic" update on the client (ie. update the view under the assumption that the write will succeed), and finally commit it, retry it or roll it back in the event of an error when the server payload comes back.
In some ways Relay is inspired by Flux, but the mental model is much simpler. Instead of multiple stores, there is one central store that caches all GraphQL data. Instead of explicit subscriptions, the framework itself can track which data each component requests, and which components should be updated whenever the data change. Instead of actions, modifications take the form of mutations.
+
+
At Facebook, we have apps built entirely using Flux, entirely using Relay, or with both. One pattern we see emerging is letting Relay manage the bulk of the data flow for an application, but using Flux stores on the side to handle a subset of application state.
We're working very hard right now on getting both GraphQL (a spec, and a reference implementation) and Relay ready for public release (no specific dates yet, but we are super excited about getting these out there).
+
+
In the meantime, we'll be providing more and more information in the form of blog posts (and in other channels). As we get closer to the open source release, you can expect more concrete details, syntax and API descriptions and more.
Pedro Nauck (pedronauck) delivered an impeccably illustrated deck at Brazil's Front in Floripa conference. Watch him talk about how to keep delivering value as your app scales, by keeping your development process simple.
-
-
-
-
Murilo Pereira (mpereira) tussles with the topic of complexity in this blog post about coping with scaling up, where he describes how his team used React to make possible the “nearly impossible.”
-
-
I (steveluscher) spoke at Manning Publications' “Powered By JavaScript” Strangeloop pre-conf in St. Louis. There, I proposed a new notation to talk about development complexity – Big-Coffee Notation ☕(n) – and spoke about the features of React that help keep our Big-Coffee from going quadratic, as our user interfaces get more complex.
-
-
-
-
James Pearce (jamesgpearce) carried Big-Coffee all the way to Raleigh, NC. At the All Things Open conference, he spoke about some of the design decisions that went into React, particularly those that lend themselves to simpler, more reliable code.
Michael Ridgway (mridgway) shows us how Yahoo! (who recently moved Yahoo! Mail to React) renders their React+Flux application, server-side.
-
-
-
-
Péter Márton (hekike) helps us brew a cold one (literally) using an application that's server-client isomorphic and indexable. Demo and sample code included – cold ones sold separately.
Ryan Florence (rpflorence) and Michael Jackson (mjackson) unveiled a new API for React Router that solves some of its user's problems by eliminating the problems themselves. Read all about what React Router learned from its community of users, and how they've rolled your ideas into their latest release.
Jonathan Beebe (somethingkindawierd) spoke about how he uses React to build tools that deliver hope to those trying to make the best of a bad situation. Watch his talk from this year's Nodevember conference in Nashville
-
-
-
-
If you take a peek under the covers, you'll find that React powers Carousel, Dropbox's new photo and video gallery app.
-
-
We enjoyed a cinematic/narrative experience with this React-powered, interactive story by British author William Boyd. Dive into “The Vanishing Game” and see for yourself.
Spend the next 60 seconds watching Daniel Woelfel (dwwoelfel) serialize a React app's state as a string, then deserialize it to produce a working UI. Read about how he uses this technique to reproduce bugs reported to him by his users.
Tom Chen (tomchentw) brings us a react-google-maps component, and a way to syntax highlight source code using Prism and the react-prism component, for good measure.
-
-
Jed Watson (jedwatson) helps you manage touch, tap, and press events using the react-tappable component.
-
-
To find these, and more community-built components, consult the React Components and React Rocks component directories. React Rocks recently exceeded one-hundred listed components and counting. See one missing? Add the keyword react-component to your package.json to get listed on React Components, and submit a link to React Rocks.
The internet is abuzz with talk of styling React components using JavaScript instead of CSS. Christopher Chedeau (vjeux) talks about some of the fundamental style management challenges we grapple with, at Facebook scale. A number of implementations of JavaScript centric style management solutions have appeared in the wild, including the React-focused react-style.
Facebook Open Source released Flow this month – a static type checker for JavaScript. Naturally, Flow supports JSX, and you can use it to type check React applications. There's never been a better reason to start making use of propTypes in your component specifications!
We're counting down the days until React.js Conf at Facebook's headquarters in Menlo Park, California, on January 28th & 29th, 2015. Thank you, to everyone who responded to the Call for Presenters. Mark the dates; tickets go on sale in three waves: at noon PST on November 28th, December 5th, and December 12th, 2014.
Pedro Nauck (pedronauck) delivered an impeccably illustrated deck at Brazil's Front in Floripa conference. Watch him talk about how to keep delivering value as your app scales, by keeping your development process simple.
+
+
+
+
Murilo Pereira (mpereira) tussles with the topic of complexity in this blog post about coping with scaling up, where he describes how his team used React to make possible the “nearly impossible.”
+
+
I (steveluscher) spoke at Manning Publications' “Powered By JavaScript” Strangeloop pre-conf in St. Louis. There, I proposed a new notation to talk about development complexity – Big-Coffee Notation ☕(n) – and spoke about the features of React that help keep our Big-Coffee from going quadratic, as our user interfaces get more complex.
+
+
+
+
James Pearce (jamesgpearce) carried Big-Coffee all the way to Raleigh, NC. At the All Things Open conference, he spoke about some of the design decisions that went into React, particularly those that lend themselves to simpler, more reliable code.
Michael Ridgway (mridgway) shows us how Yahoo! (who recently moved Yahoo! Mail to React) renders their React+Flux application, server-side.
+
+
+
+
Péter Márton (hekike) helps us brew a cold one (literally) using an application that's server-client isomorphic and indexable. Demo and sample code included – cold ones sold separately.
Ryan Florence (rpflorence) and Michael Jackson (mjackson) unveiled a new API for React Router that solves some of its user's problems by eliminating the problems themselves. Read all about what React Router learned from its community of users, and how they've rolled your ideas into their latest release.
Jonathan Beebe (somethingkindawierd) spoke about how he uses React to build tools that deliver hope to those trying to make the best of a bad situation. Watch his talk from this year's Nodevember conference in Nashville
+
+
+
+
If you take a peek under the covers, you'll find that React powers Carousel, Dropbox's new photo and video gallery app.
+
+
We enjoyed a cinematic/narrative experience with this React-powered, interactive story by British author William Boyd. Dive into “The Vanishing Game” and see for yourself.
Spend the next 60 seconds watching Daniel Woelfel (dwwoelfel) serialize a React app's state as a string, then deserialize it to produce a working UI. Read about how he uses this technique to reproduce bugs reported to him by his users.
Tom Chen (tomchentw) brings us a react-google-maps component, and a way to syntax highlight source code using Prism and the react-prism component, for good measure.
+
+
Jed Watson (jedwatson) helps you manage touch, tap, and press events using the react-tappable component.
+
+
To find these, and more community-built components, consult the React Components and React Rocks component directories. React Rocks recently exceeded one-hundred listed components and counting. See one missing? Add the keyword react-component to your package.json to get listed on React Components, and submit a link to React Rocks.
The internet is abuzz with talk of styling React components using JavaScript instead of CSS. Christopher Chedeau (vjeux) talks about some of the fundamental style management challenges we grapple with, at Facebook scale. A number of implementations of JavaScript centric style management solutions have appeared in the wild, including the React-focused react-style.
Facebook Open Source released Flow this month – a static type checker for JavaScript. Naturally, Flow supports JSX, and you can use it to type check React applications. There's never been a better reason to start making use of propTypes in your component specifications!
We're counting down the days until React.js Conf at Facebook's headquarters in Menlo Park, California, on January 28th & 29th, 2015. Thank you, to everyone who responded to the Call for Presenters. Mark the dates; tickets go on sale in three waves: at noon PST on November 28th, December 5th, and December 12th, 2014.
We are finally ready to share the work we've been doing over the past couple months. A lot has gone into this and we want to make sure we iron out any potential issues before we make this final. So, we're shipping a Release Candidate for React v0.12 today. If you get a chance, please give it a try and report any issues you find! A full changelog will accompany the final release but we've highlighted the interesting and breaking changes below.
Earlier this year we decided to write a specification for JSX. This has allowed us to make some changes focused on the React specific JSX and still allow others to innovate in the same space.
We have wanted to do this since before we even open sourced React. No more /** @jsx React.DOM */!. The React specific JSX transform assumes you have React in scope (which had to be true before anyway).
-
-
JSXTransformer and react-tools have both been updated to account for this.
The React specific JSX transform no longer transforms to function calls. Instead we use React.createElement and pass it arguments. This allows us to make optimizations and better support React as a compile target for things like Om. Read more in the React Elements introduction.
-
-
The result of this change is that we will no longer support arbitrary function calls. We understand that the ability to do was was a convenient shortcut for many people but we believe the gains will be worth it.
We used to have a whitelist of HTML tags that got special treatment in JSX. However as new HTML tags got added to the spec, or we added support for more SVG tags, we had to go update our whitelist. Additionally, there was ambiguity about the behavior. There was always the chance that something new added to the tag list would result in breaking your code. For example:
-
return<component/>;
-
-
Is component an existing HTML tag? What if it becomes one?
-
-
To address this, we decided on a convention: All JSX tags that start with a lower-case letter or contain a dash are treated as HTML.
-
-
This means that you no longer have to wait for us to upgrade JSX to use new tags. This also introduces the possibility to consume custom elements (Web Components) - although custom attributes are not yet fully supported.
-
-
Currently we still use the whitelist as a sanity check. The transform will fail when it encounters an unknown tag. This allows you to update your code without hitting errors in production.
-
-
In addition, the HTML tags are converted to strings instead of using React.DOM directly. <div/> becomes React.createElement('div') instead of React.DOM.div().
Previously there wasn't a way to for you to pass a dynamic or unknown set of properties through JSX. This is now possible using the spread ... operator.
If you used to use plain function calls to pass arbitrary props objects...
-
returnMyComponent(myProps);
-
-
You can now switch to using Spread Attributes instead:
-
return<MyComponent{...myProps}/>;
-
Breaking Change: key and ref Removed From this.props#
-
The props key and ref were already reserved property names. This turned out to be difficult to explicitly statically type since any object can accept these extra props. It also screws up JIT optimizations of React internals in modern VMs.
-
-
These are concepts that React manages from outside the Component before it even gets created so it shouldn't be part of the props.
-
-
We made this distinction clearer by moving them off the props object and onto the ReactElement itself. This means that you need to rename:
-
-
someElement.props.key -> someElement.key
-
-
You can no longer access this.props.ref and this.props.key from inside the Component instance itself. So you need to use a different name for those props.
-
-
You do NOT need to change the way to define key and ref, only if you need to read it. E.g. <div key="my-key" /> and div({ key: 'my-key' }) still works.
This is a subtle difference but defaultProps are now resolved at ReactElement creation time instead of when it's mounted. This is means that we can avoid allocating an extra object for the resolved props.
-
-
You will primarily see this breaking if you're also using transferPropsTo.
transferPropsTo is deprecated in v0.12 and will be removed in v0.13. This helper function was a bit magical. It auto-merged a certain whitelist of properties and excluded others. It was also transferring too many properties. This meant that we have to keep a whitelist of valid HTML attributes in the React runtime. It also means that we can't catch typos on props.
-
-
Our suggested solution is to use the Spread Attributes.
It used to be possible to return false from event handlers to preventDefault. We did this because this works in most browsers. This is a confusing API and we might want to use the return value for something else. Therefore, this is deprecated. Use event.preventDefault() instead.
We are finally ready to share the work we've been doing over the past couple months. A lot has gone into this and we want to make sure we iron out any potential issues before we make this final. So, we're shipping a Release Candidate for React v0.12 today. If you get a chance, please give it a try and report any issues you find! A full changelog will accompany the final release but we've highlighted the interesting and breaking changes below.
Earlier this year we decided to write a specification for JSX. This has allowed us to make some changes focused on the React specific JSX and still allow others to innovate in the same space.
We have wanted to do this since before we even open sourced React. No more /** @jsx React.DOM */!. The React specific JSX transform assumes you have React in scope (which had to be true before anyway).
+
+
JSXTransformer and react-tools have both been updated to account for this.
The React specific JSX transform no longer transforms to function calls. Instead we use React.createElement and pass it arguments. This allows us to make optimizations and better support React as a compile target for things like Om. Read more in the React Elements introduction.
+
+
The result of this change is that we will no longer support arbitrary function calls. We understand that the ability to do was was a convenient shortcut for many people but we believe the gains will be worth it.
We used to have a whitelist of HTML tags that got special treatment in JSX. However as new HTML tags got added to the spec, or we added support for more SVG tags, we had to go update our whitelist. Additionally, there was ambiguity about the behavior. There was always the chance that something new added to the tag list would result in breaking your code. For example:
+
return<component/>;
+
+
Is component an existing HTML tag? What if it becomes one?
+
+
To address this, we decided on a convention: All JSX tags that start with a lower-case letter or contain a dash are treated as HTML.
+
+
This means that you no longer have to wait for us to upgrade JSX to use new tags. This also introduces the possibility to consume custom elements (Web Components) - although custom attributes are not yet fully supported.
+
+
Currently we still use the whitelist as a sanity check. The transform will fail when it encounters an unknown tag. This allows you to update your code without hitting errors in production.
+
+
In addition, the HTML tags are converted to strings instead of using React.DOM directly. <div/> becomes React.createElement('div') instead of React.DOM.div().
Previously there wasn't a way to for you to pass a dynamic or unknown set of properties through JSX. This is now possible using the spread ... operator.
If you used to use plain function calls to pass arbitrary props objects...
+
returnMyComponent(myProps);
+
+
You can now switch to using Spread Attributes instead:
+
return<MyComponent{...myProps}/>;
+
Breaking Change: key and ref Removed From this.props#
+
The props key and ref were already reserved property names. This turned out to be difficult to explicitly statically type since any object can accept these extra props. It also screws up JIT optimizations of React internals in modern VMs.
+
+
These are concepts that React manages from outside the Component before it even gets created so it shouldn't be part of the props.
+
+
We made this distinction clearer by moving them off the props object and onto the ReactElement itself. This means that you need to rename:
+
+
someElement.props.key -> someElement.key
+
+
You can no longer access this.props.ref and this.props.key from inside the Component instance itself. So you need to use a different name for those props.
+
+
You do NOT need to change the way to define key and ref, only if you need to read it. E.g. <div key="my-key" /> and div({ key: 'my-key' }) still works.
This is a subtle difference but defaultProps are now resolved at ReactElement creation time instead of when it's mounted. This is means that we can avoid allocating an extra object for the resolved props.
+
+
You will primarily see this breaking if you're also using transferPropsTo.
transferPropsTo is deprecated in v0.12 and will be removed in v0.13. This helper function was a bit magical. It auto-merged a certain whitelist of properties and excluded others. It was also transferring too many properties. This meant that we have to keep a whitelist of valid HTML attributes in the React runtime. It also means that we can't catch typos on props.
+
+
Our suggested solution is to use the Spread Attributes.
It used to be possible to return false from event handlers to preventDefault. We did this because this works in most browsers. This is a confusing API and we might want to use the return value for something else. Therefore, this is deprecated. Use event.preventDefault() instead.
At Facebook we've been using JSX for a long time. We originally introduced it to the world last year alongside React, but we actually used it in another form before that to create native DOM nodes. We've also seen some similar efforts grow out of our work in order to be used with other libraries and in interesting ways. At this point React JSX is just one of many implementations.
-
-
In order to make it easier to implement new versions and to make sure that the syntax remains compatible, we're now formalizing the syntax of JSX in a stand-alone spec without any semantic meaning. It's completely stand-alone from React itself.
This is not a proposal to be standardized in ECMAScript. It's just a reference document that transpiler writers and syntax highlighters can agree on. It's currently in a draft stage and will probably continue to be a living document.
-
-
Feel free to open an Issue or Pull Request if you find something wrong.
At Facebook we've been using JSX for a long time. We originally introduced it to the world last year alongside React, but we actually used it in another form before that to create native DOM nodes. We've also seen some similar efforts grow out of our work in order to be used with other libraries and in interesting ways. At this point React JSX is just one of many implementations.
+
+
In order to make it easier to implement new versions and to make sure that the syntax remains compatible, we're now formalizing the syntax of JSX in a stand-alone spec without any semantic meaning. It's completely stand-alone from React itself.
This is not a proposal to be standardized in ECMAScript. It's just a reference document that transpiler writers and syntax highlighters can agree on. It's currently in a draft stage and will probably continue to be a living document.
+
+
Feel free to open an Issue or Pull Request if you find something wrong.
Update: We missed a few important changes in our initial post and changelog. We've updated this post with details about Descriptors and Prop Type Validation.
-
-
-
-
We're really happy to announce the availability of React v0.11. There seems to be a lot of excitement already and we appreciate everybody who gave the release candidate a try over the weekend. We made a couple small changes in response to the feedback and issues filed. We enabled the destructuring assignment transform when using jsx --harmony, fixed a small regression with statics, and made sure we actually exposed the new API we said we were shipping: React.Children.count.
-
-
This version has been cooking for a couple months now and includes a wide array of bug fixes and features. We highlighted some of the most important changes below, along with the full changelog.
-
-
The release is available for download from the CDN:
Starting in React 0.11, getDefaultProps() is called only once when React.createClass() is called, instead of each time a component is rendered. This means that getDefaultProps() can no longer vary its return value based on this.props and any objects will be shared across all instances. This change improves performance and will make it possible in the future to do PropTypes checks earlier in the rendering process, allowing us to give better error messages.
Since React's release, people have been using work arounds to "render nothing". Usually this means returning an empty <div/> or <span/>. Some people even got clever and started returning <noscript/> to avoid extraneous DOM nodes. We finally provided a "blessed" solution that allows developers to write meaningful code. Returning null is an explicit indication to React that you do not want anything rendered. Behind the scenes we make this work with a <noscript> element, though in the future we hope to not put anything in the document. In the mean time, <noscript> elements do not affect layout in any way, so you can feel safe using null today!
Another feature request we've been hearing for a long time is the ability to have namespaces in JSX. Given that JSX is just JavaScript, we didn't want to use XML namespacing. Instead we opted for a standard JS approach: object property access. Instead of assigning variables to access components stored in an object (such as a component library), you can now use the component directly as <Namespace.Component/>.
Keyboard events now contain a normalized e.key value according to the DOM Level 3 Events spec, allowing you to write simpler key handling code that works in all browsers, such as:
In our v0.10 release notes, we called out that we were deprecating the existing behavior of the component function call (eg component = MyComponent(props, ...children) or component = <MyComponent prop={...}/>). Previously that would create an instance and React would modify that internally. You could store that reference and then call functions on it (eg component.setProps(...)). This no longer works. component in the above examples will be a descriptor and not an instance that can be operated on. The v0.10 release notes provide a complete example along with a migration path. The development builds also provided warnings if you called functions on descriptors.
-
-
Along with this change to descriptors, React.isValidComponent and React.PropTypes.component now actually validate that the value is a descriptor. Overwhelmingly, these functions are used to validate the value of MyComponent(), which as mentioned is now a descriptor, not a component instance. We opted to reduce code churn and make the migration to 0.11 as easy as possible. However, we realize this is has caused some confusion and we're working to make sure we are consistent with our terminology.
Previously React.PropTypes validation worked by simply logging to the console. Internally, each validator was responsible for doing this itself. Additionally, you could write a custom validator and the expectation was that you would also simply console.log your error message. Very shortly into the 0.11 cycle we changed this so that our validators return (not throw) an Error object. We then log the error.message property in a central place in ReactCompositeComponent. Overall the result is the same, but this provides a clearer intent in validation. In addition, to better transition into our descriptor factory changes, we also currently run prop type validation twice in development builds. As a result, custom validators doing their own logging result in duplicate messages. To update, simply return an Error with your message instead.
Update: We missed a few important changes in our initial post and changelog. We've updated this post with details about Descriptors and Prop Type Validation.
+
+
+
+
We're really happy to announce the availability of React v0.11. There seems to be a lot of excitement already and we appreciate everybody who gave the release candidate a try over the weekend. We made a couple small changes in response to the feedback and issues filed. We enabled the destructuring assignment transform when using jsx --harmony, fixed a small regression with statics, and made sure we actually exposed the new API we said we were shipping: React.Children.count.
+
+
This version has been cooking for a couple months now and includes a wide array of bug fixes and features. We highlighted some of the most important changes below, along with the full changelog.
+
+
The release is available for download from the CDN:
Starting in React 0.11, getDefaultProps() is called only once when React.createClass() is called, instead of each time a component is rendered. This means that getDefaultProps() can no longer vary its return value based on this.props and any objects will be shared across all instances. This change improves performance and will make it possible in the future to do PropTypes checks earlier in the rendering process, allowing us to give better error messages.
Since React's release, people have been using work arounds to "render nothing". Usually this means returning an empty <div/> or <span/>. Some people even got clever and started returning <noscript/> to avoid extraneous DOM nodes. We finally provided a "blessed" solution that allows developers to write meaningful code. Returning null is an explicit indication to React that you do not want anything rendered. Behind the scenes we make this work with a <noscript> element, though in the future we hope to not put anything in the document. In the mean time, <noscript> elements do not affect layout in any way, so you can feel safe using null today!
Another feature request we've been hearing for a long time is the ability to have namespaces in JSX. Given that JSX is just JavaScript, we didn't want to use XML namespacing. Instead we opted for a standard JS approach: object property access. Instead of assigning variables to access components stored in an object (such as a component library), you can now use the component directly as <Namespace.Component/>.
Keyboard events now contain a normalized e.key value according to the DOM Level 3 Events spec, allowing you to write simpler key handling code that works in all browsers, such as:
In our v0.10 release notes, we called out that we were deprecating the existing behavior of the component function call (eg component = MyComponent(props, ...children) or component = <MyComponent prop={...}/>). Previously that would create an instance and React would modify that internally. You could store that reference and then call functions on it (eg component.setProps(...)). This no longer works. component in the above examples will be a descriptor and not an instance that can be operated on. The v0.10 release notes provide a complete example along with a migration path. The development builds also provided warnings if you called functions on descriptors.
+
+
Along with this change to descriptors, React.isValidComponent and React.PropTypes.component now actually validate that the value is a descriptor. Overwhelmingly, these functions are used to validate the value of MyComponent(), which as mentioned is now a descriptor, not a component instance. We opted to reduce code churn and make the migration to 0.11 as easy as possible. However, we realize this is has caused some confusion and we're working to make sure we are consistent with our terminology.
Previously React.PropTypes validation worked by simply logging to the console. Internally, each validator was responsible for doing this itself. Additionally, you could write a custom validator and the expectation was that you would also simply console.log your error message. Very shortly into the 0.11 cycle we changed this so that our validators return (not throw) an Error object. We then log the error.message property in a central place in ReactCompositeComponent. Overall the result is the same, but this provides a clearer intent in validation. In addition, to better transition into our descriptor factory changes, we also currently run prop type validation twice in development builds. As a result, custom validators doing their own logging result in duplicate messages. To update, simply return an Error with your message instead.
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.
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.
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.
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.
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.
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.
It's exciting to see the number of real-world React applications and components skyrocket over the past months! This community round-up features a few examples of inspiring React applications and components.
Large parts of Facebook's web frontend are already powered by React. The recently released Facebook Lookback video and its corresponding editor are great examples of a complex, real-world React app.
Relato by Ben Ripkens shows Open Source Statistics based on npm data. It features a filterable and sortable table built in React. Check it out – it's super fast!
John Lynch (@johnrlynch) created Makona, a block-style document editor for the web. Blocks of different content types comprise documents, authored using plain markup. At the switch of a toggle, block contents are then rendered on the page. While not quite a WYSIWYG editor, Makona uses plain textareas for input. This makes it compatible with a wider range of platforms than traditional rich text editors.
-
Sproutsheet is a gardening calendar. You can use it to track certain events that happen in the life of your plants. It's currently in beta and supports localStorage, and data/image import and export.
Emanuele Rampichini's ReactJS Gallery is a cool demo app that shows fullscreen images from a folder on the server. If the folder content changes, the gallery app updates via websockets.
react-input=placeholder by enigma-io is a small wrapper around React.DOM.input that shims in placeholder functionality for browsers that don't natively support it.
Recent changes: web ui is being upgraded to [#reactjs](https://twitter.com/search?q=%23reactjs&src=hash), HEAD~4 at [https://camlistore.googlesource.com/camlistore/](https://camlistore.googlesource.com/camlistore/)
diff --git a/feed.xml b/feed.xml
index 44cb553955..9c12356898 100644
--- a/feed.xml
+++ b/feed.xml
@@ -6,6 +6,29 @@
https://facebook.github.io/react
+
+ Deprecating JSTransform and react-tools
+ <p>Today we're announcing the deprecation of react-tools and JSTransform.</p>
+
+<p>As many people have noticed already, React and React Native have both switched their respective build systems to make use of <a href="http://babeljs.io/">Babel</a>. This replaced <a href="https://github.com/facebook/jstransform">JSTransform</a>, the source transformation tool that we wrote at Facebook. JSTransform has been really good for us over the past several years, however as the JavaScript language continues to evolve, the architecture we used has begun to show its age. We've faced maintenance issues and lagged behind implementing new language features. Last year, Babel (previously 6to5) exploded onto the scene, implementing new features at an amazing pace. Since then it has evolved a solid plugin API, and implemented some of our non-standard language features (JSX and Flow type annotations).</p>
+
+<p>react-tools has always been a very thin wrapper around JSTransform. It has served as a great tool for the community to get up and running, but at this point we're ready to <a href="https://www.youtube.com/watch?v=moSFlvxnbgk">let it go</a>. We won't ship a new version for v0.14.</p>
+<h2><a class="anchor" name="migrating-to-babel"></a>Migrating to Babel <a class="hash-link" href="#migrating-to-babel">#</a></h2>
+<p>Many people in the React and broader JavaScript community have already adopted Babel. It has <a href="http://babeljs.io/docs/setup/">integrations with a number of tools</a>. Depending on your tool, you'll want to read up on the instructions.</p>
+
+<p>We've been working with the Babel team as we started making use of it and we're confident that it will be the right tool to use with React.</p>
+<h2><a class="anchor" name="other-deprecations"></a>Other Deprecations <a class="hash-link" href="#other-deprecations">#</a></h2><h3><a class="anchor" name="esprima-fb"></a>esprima-fb <a class="hash-link" href="#esprima-fb">#</a></h3>
+<p>As a result of no longer maintaining JSTransform, we no longer have a need to maintain our Esprima fork (<a href="https://github.com/facebook/esprima/">esprima-fb</a>). The upstream Esprima and other esprima-based forks, like Espree, have been doing an excellent job of supporting new language features recently. If you have a need of an esprima-based parse, we encourage you to look into using one of those.</p>
+<h3><a class="anchor" name="jsxtransformer"></a>JSXTransformer <a class="hash-link" href="#jsxtransformer">#</a></h3>
+<p>JSXTransformer is another tool we built specifically for consuming JSX in the browser. It was always intended as a quick way to prototype code before setting up a build process. It would look for <code><script></code> tags with <code>type="text/jsx"</code> and then transform and run. This ran the same code that react-tools ran on the server. Babel ships with <a href="https://babeljs.io/docs/usage/browser/">a nearly identical tool</a>, which has already been integrated into <a href="https://jsbin.com/">JS Bin</a>.</p>
+
+<p>We'll be deprecating JSXTransformer, however the current version will still be available from various CDNs and Bower.</p>
+
+ 2015-06-12T00:00:00-07:00
+ https://facebook.github.io/react/blog/2015/06/12/deprecating-jstransform-and-react-tools.html
+ https://facebook.github.io/react/blog/2015/06/12/deprecating-jstransform-and-react-tools.html
+
+
React Native Release Process<p>The React Native release process have been a bit chaotic since we open sourced. It was unclear when new code was released, there was no changelog, we bumped the minor and patch version inconsistently and we often had to submit updates right after a release to fix a bad bug. In order to <em>move fast with stable infra</em>, we are introducing a real release process with a two-week release schedule.</p>
@@ -564,91 +587,5 @@ Minified build for production: <a href="https://fb.me/react-with-addons-
https://facebook.github.io/react/blog/2015/03/16/react-v0.13.1.html
-
- React v0.13
- <p>Today, we're happy to release React v0.13!</p>
-
-<p>The most notable new feature is <a href="/react/blog/2015/01/27/react-v0.13.0-beta-1.html">support for ES6 classes</a>, which allows developers to have more flexibility when writing components. Our eventual goal is for ES6 classes to replace <code>React.createClass</code> completely, but until we have a replacement for current mixin use cases and support for class property initializers in the language, we don't plan to deprecate <code>React.createClass</code>.</p>
-
-<p>At EmberConf and ng-conf last week, we were excited to see that Ember and Angular have been working on speed improvements and now both have performance comparable to React. We've always thought that performance isn't the most important reason to choose React, but we're still planning more optimizations to <strong>make React even faster</strong>.</p>
-
-<p>Our planned optimizations require that ReactElement objects are immutable, which has always been a best practice when writing idiomatic React code. In this release, we've added runtime warnings that fire when props are changed or added between the time an element is created and when it's rendered. When migrating your code, you may want to use new <code>React.cloneElement</code> API (which is similar to <code>React.addons.cloneWithProps</code> but preserves <code>key</code> and <code>ref</code> and does not merge <code>style</code> or <code>className</code> automatically). For more information about our planned optimizations, see GitHub issues
-<a href="https://github.com/facebook/react/issues/3226">#3226</a>,
-<a href="https://github.com/facebook/react/issues/3227">#3227</a>,
-<a href="https://github.com/facebook/react/issues/3228">#3228</a>.</p>
-
-<p>The release is now available for download:</p>
-
-<ul>
-<li><strong>React</strong><br>
-Dev build with warnings: <a href="https://fb.me/react-0.13.0.js">https://fb.me/react-0.13.0.js</a><br>
-Minified build for production: <a href="https://fb.me/react-0.13.0.min.js">https://fb.me/react-0.13.0.min.js</a><br></li>
-<li><strong>React with Add-Ons</strong><br>
-Dev build with warnings: <a href="https://fb.me/react-with-addons-0.13.0.js">https://fb.me/react-with-addons-0.13.0.js</a><br>
-Minified build for production: <a href="https://fb.me/react-with-addons-0.13.0.min.js">https://fb.me/react-with-addons-0.13.0.min.js</a><br></li>
-<li><strong>In-Browser JSX transformer</strong><br>
-<a href="https://fb.me/JSXTransformer-0.13.0.js">https://fb.me/JSXTransformer-0.13.0.js</a></li>
-</ul>
-
-<p>We've also published version <code>0.13.0</code> of the <code>react</code> and <code>react-tools</code> packages on npm and the <code>react</code> package on bower.</p>
-
-<hr>
-<h2><a class="anchor" name="changelog"></a>Changelog <a class="hash-link" href="#changelog">#</a></h2><h3><a class="anchor" name="react-core"></a>React Core <a class="hash-link" href="#react-core">#</a></h3><h4><a class="anchor" name="breaking-changes"></a>Breaking Changes <a class="hash-link" href="#breaking-changes">#</a></h4>
-<ul>
-<li>Deprecated patterns that warned in 0.12 no longer work: most prominently, calling component classes without using JSX or React.createElement and using non-component functions with JSX or createElement</li>
-<li>Mutating <code>props</code> after an element is created is deprecated and will cause warnings in development mode; future versions of React will incorporate performance optimizations assuming that props aren't mutated</li>
-<li>Static methods (defined in <code>statics</code>) are no longer autobound to the component class</li>
-<li><code>ref</code> resolution order has changed slightly such that a ref to a component is available immediately after its <code>componentDidMount</code> method is called; this change should be observable only if your component calls a parent component's callback within your <code>componentDidMount</code>, which is an anti-pattern and should be avoided regardless</li>
-<li>Calls to <code>setState</code> in life-cycle methods are now always batched and therefore asynchronous. Previously the first call on the first mount was synchronous.</li>
-<li><code>setState</code> and <code>forceUpdate</code> on an unmounted component now warns instead of throwing. That avoids a possible race condition with Promises.</li>
-<li>Access to most internal properties has been completely removed, including <code>this._pendingState</code> and <code>this._rootNodeID</code>.</li>
-</ul>
-<h4><a class="anchor" name="new-features"></a>New Features <a class="hash-link" href="#new-features">#</a></h4>
-<ul>
-<li>Support for using ES6 classes to build React components; see the <a href="/react/blog/2015/01/27/react-v0.13.0-beta-1.html">v0.13.0 beta 1 notes</a> for details.</li>
-<li>Added new top-level API <code>React.findDOMNode(component)</code>, which should be used in place of <code>component.getDOMNode()</code>. The base class for ES6-based components will not have <code>getDOMNode</code>. This change will enable some more patterns moving forward.</li>
-<li>Added a new top-level API <code>React.cloneElement(el, props)</code> for making copies of React elements – see the <a href="/react/blog/2015/03/03/react-v0.13-rc2.html#react.cloneelement">v0.13 RC2 notes</a> for more details.</li>
-<li>New <code>ref</code> style, allowing a callback to be used in place of a name: <code><Photo ref={(c) => this._photo = c} /></code> allows you to reference the component with <code>this._photo</code> (as opposed to <code>ref="photo"</code> which gives <code>this.refs.photo</code>).</li>
-<li><code>this.setState()</code> can now take a function as the first argument for transactional state updates, such as <code>this.setState((state, props) => ({count: state.count + 1}));</code> – this means that you no longer need to use <code>this._pendingState</code>, which is now gone.</li>
-<li>Support for iterators and immutable-js sequences as children.</li>
-</ul>
-<h4><a class="anchor" name="deprecations"></a>Deprecations <a class="hash-link" href="#deprecations">#</a></h4>
-<ul>
-<li><code>ComponentClass.type</code> is deprecated. Just use <code>ComponentClass</code> (usually as <code>element.type === ComponentClass</code>).</li>
-<li>Some methods that are available on <code>createClass</code>-based components are removed or deprecated from ES6 classes (<code>getDOMNode</code>, <code>replaceState</code>, <code>isMounted</code>, <code>setProps</code>, <code>replaceProps</code>).</li>
-</ul>
-<h3><a class="anchor" name="react-with-add-ons"></a>React with Add-Ons <a class="hash-link" href="#react-with-add-ons">#</a></h3><h4><a class="anchor" name="new-features"></a>New Features <a class="hash-link" href="#new-features">#</a></h4>
-<ul>
-<li><a href="/react/docs/create-fragment.html"><code>React.addons.createFragment</code> was added</a> for adding keys to entire sets of children.</li>
-</ul>
-<h4><a class="anchor" name="deprecations"></a>Deprecations <a class="hash-link" href="#deprecations">#</a></h4>
-<ul>
-<li><code>React.addons.classSet</code> is now deprecated. This functionality can be replaced with several freely available modules. <a href="https://www.npmjs.com/package/classnames">classnames</a> is one such module.</li>
-<li>Calls to <code>React.addons.cloneWithProps</code> can be migrated to use <code>React.cloneElement</code> instead – make sure to merge <code>style</code> and <code>className</code> manually if desired.</li>
-</ul>
-<h3><a class="anchor" name="react-tools"></a>React Tools <a class="hash-link" href="#react-tools">#</a></h3><h4><a class="anchor" name="breaking-changes"></a>Breaking Changes <a class="hash-link" href="#breaking-changes">#</a></h4>
-<ul>
-<li>When transforming ES6 syntax, <code>class</code> methods are no longer enumerable by default, which requires <code>Object.defineProperty</code>; if you support browsers such as IE8, you can pass <code>--target es3</code> to mirror the old behavior</li>
-</ul>
-<h4><a class="anchor" name="new-features"></a>New Features <a class="hash-link" href="#new-features">#</a></h4>
-<ul>
-<li><code>--target</code> option is available on the jsx command, allowing users to specify and ECMAScript version to target.
-
-<ul>
-<li><code>es5</code> is the default.</li>
-<li><code>es3</code> restores the previous default behavior. An additional transform is added here to ensure the use of reserved words as properties is safe (eg <code>this.static</code> will become <code>this['static']</code> for IE8 compatibility).</li>
-</ul></li>
-<li>The transform for the call spread operator has also been enabled.</li>
-</ul>
-<h3><a class="anchor" name="jsx"></a>JSX <a class="hash-link" href="#jsx">#</a></h3><h4><a class="anchor" name="breaking-changes"></a>Breaking Changes <a class="hash-link" href="#breaking-changes">#</a></h4>
-<ul>
-<li>A change was made to how some JSX was parsed, specifically around the use of <code>></code> or <code>}</code> when inside an element. Previously it would be treated as a string but now it will be treated as a parse error. The <a href="https://www.npmjs.com/package/jsx_orphaned_brackets_transformer"><code>jsx_orphaned_brackets_transformer</code></a> package on npm can be used to find and fix potential issues in your JSX code.</li>
-</ul>
-
- 2015-03-10T00:00:00-07:00
- https://facebook.github.io/react/blog/2015/03/10/react-v0.13.html
- https://facebook.github.io/react/blog/2015/03/10/react-v0.13.html
-
-
+ React
+ 
