diff --git a/blog/2013/06/05/why-react.html b/blog/2013/06/05/why-react.html
index eeb1e8866c..fc3f9b1c0b 100644
--- a/blog/2013/06/05/why-react.html
+++ b/blog/2013/06/05/why-react.html
@@ -38,6 +38,7 @@ and why would you want to use it?
+
@@ -65,7 +66,7 @@ and why would you want to use it?
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:
+
It looks like Sophie Alpert is the first person outside of Facebook and Instagram to push React code to production. We are very grateful for her contributions in form of pull requests, bug reports and presence on IRC (#reactjs on Freenode). Sophie wrote about her 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:
-
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.
Ben Alpert from Khan Academy worked on a cross-browser implementation of onChange event that landed in v0.4. He wrote a blog post explaining the various browser quirks he had to deal with.
+
Sophie Alpert from Khan Academy worked on a cross-browser implementation of onChange event that landed in v0.4. She wrote a blog post explaining the various browser quirks she had to deal with.
First off, what is the input event? If you have an <input> element and want to receive events whenever the value changes, the most obvious thing to do is to listen to the change event. Unfortunately, change fires only after the text field is defocused, rather than on each keystroke. The next obvious choice is the keyup event, which is triggered whenever a key is released. Unfortunately, keyup doesn't catch input that doesn't involve the keyboard (e.g., pasting from the clipboard using the mouse) and only fires once if a key is held down, rather than once per inserted character.
Both keydown and keypress do fire repeatedly when a key is held down, but both fire immediately before the value changes, so to read the new value you have to defer the handler to the next event loop using setTimeout(fn, 0) or similar, which slows down your app. Of course, like keyup, neither keydown nor keypress fires for non-keyboard input events, and all three can fire in cases where the value doesn't change at all (such as when pressing the arrow keys).
PETE: Exactly, exactly. In order to implement that, we communicate it as a fake DOM. What we'll do is rather than throw out the actual browser html and event handlers, we have an internal representation of what the page looks like and then we generate a brand new representation of what we want the page to look like. Then we perform this really, really fast diffing algorithm between those two page representations, DOM representations. Then React will compute the minimum set of DOM mutations it needs to make to bring the page up to date.
-
Then to finally get to answer your question, that set of DOM mutations then goes into a queue and we can plug in arbitrary flushing strategies for that. For example, when we originally launched React in open source, every setState would immediately trigger a flush to the DOM. That wasn't part of the contract of setState, but that was just our strategy and it worked pretty well. Then this totally awesome open source contributor Ben Alpert at Khan Academy built a new batching strategy which would basically queue up every single DOM update and state change that happened within an event tick and would execute them in bulk at the end of the event tick.
+
Then to finally get to answer your question, that set of DOM mutations then goes into a queue and we can plug in arbitrary flushing strategies for that. For example, when we originally launched React in open source, every setState would immediately trigger a flush to the DOM. That wasn't part of the contract of setState, but that was just our strategy and it worked pretty well. Then this totally awesome open source contributor Sophie Alpert at Khan Academy built a new batching strategy which would basically queue up every single DOM update and state change that happened within an event tick and would execute them in bulk at the end of the event tick.
Ben Alpert converted marked, a Markdown JavaScript implementation, in React: marked-react. Even without using JSX, the HTML generation is now a lot cleaner. It is also safer as forgetting a call to escape will not introduce an XSS vulnerability.
-
+
Sophie Alpert converted marked, a Markdown JavaScript implementation, in React: marked-react. Even without using JSX, the HTML generation is now a lot cleaner. It is also safer as forgetting a call to escape will not introduce an XSS vulnerability.
+
This release focuses on fixing some small bugs that have been uncovered over the past two weeks. I would like to thank everybody involved, specifically members of the community who fixed half of the issues found. Thanks to Ben Alpert, Andrey Popp, and Laurence Rowe for their contributions!
+
This release focuses on fixing some small bugs that have been uncovered over the past two weeks. I would like to thank everybody involved, specifically members of the community who fixed half of the issues found. Thanks to Sophie Alpert, Andrey Popp, and Laurence Rowe for their contributions!
diff --git a/blog/2014/04/04/reactnet.html b/blog/2014/04/04/reactnet.html
index 3049fff28b..ca28c7880d 100644
--- a/blog/2014/04/04/reactnet.html
+++ b/blog/2014/04/04/reactnet.html
@@ -40,6 +40,7 @@ It has several purposes:
+
@@ -67,7 +68,7 @@ It has several purposes:
diff --git a/blog/2014/06/27/community-roundup-19.html b/blog/2014/06/27/community-roundup-19.html
index 8a855e0ac5..05d11f1a94 100644
--- a/blog/2014/06/27/community-roundup-19.html
+++ b/blog/2014/06/27/community-roundup-19.html
@@ -39,6 +39,7 @@ Ever wanted to find developers who also share the same interest in React than yo
+
@@ -66,7 +67,7 @@ Ever wanted to find developers who also share the same interest in React than yo
diff --git a/blog/2014/08/03/community-roundup-21.html b/blog/2014/08/03/community-roundup-21.html
index 4d5167628d..70a8bee52e 100644
--- a/blog/2014/08/03/community-roundup-21.html
+++ b/blog/2014/08/03/community-roundup-21.html
@@ -39,6 +39,7 @@ Ryan Florence and Michael Jackson ported Ember's router to React in a projec
+
@@ -66,7 +67,7 @@ Ryan Florence and Michael Jackson ported Ember's router to React in a projec
diff --git a/blog/2014/11/24/react-js-conf-updates.html b/blog/2014/11/24/react-js-conf-updates.html
index 2a8a625926..10910eca0b 100644
--- a/blog/2014/11/24/react-js-conf-updates.html
+++ b/blog/2014/11/24/react-js-conf-updates.html
@@ -39,6 +39,7 @@ amazed that 600 people requested to be notified when ticket go on sale. This is
+
@@ -66,7 +67,7 @@ amazed that 600 people requested to be notified when ticket go on sale. This is
- Tom Occhino, Ben Alpert, Lee Byron, Christopher Chedeau, Sebastian Markbåge, Jing Chen, and Dan Schafer closed the conference with a Q&A session.
+ Tom Occhino, Sophie Alpert, Lee Byron, Christopher Chedeau, Sebastian Markbåge, Jing Chen, and Dan Schafer closed the conference with a Q&A session.
Another big change with our DOM interaction is how we render text blocks. Previously you may have noticed that React rendered a lot of extra <span>s. For example, in our most basic example on the home page we render <div>Hello {this.props.name}</div>, resulting in markup that contained 2 <span>s. Now we’ll render plain text nodes interspersed with comment nodes that are used for demarcation. This gives us the same ability to update individual pieces of text, without creating extra nested nodes. Very few people have depended on the actual markup generated here so it’s likely you are not impacted. However if you were targeting these <span>s in your CSS, you will need to adjust accordingly. You can always render them explicitly in your components.
@@ -165,7 +166,7 @@ Minified build for production: h
We added support for defining stateless components as functions in React 0.14. However, React 0.14 still allowed you to define a class component without extending React.Component or using React.createClass(), so we couldn’t reliably tell if your component is a function or a class, and did not allow returning null from it. This issue is solved in React 15, and you can now return null from any component, whether it is a class or a function.
@@ -233,7 +234,7 @@ Minified build for production: h
React DOM: When specifying a unit-less CSS value as a string, a future version will not add px automatically. This version now warns in this case (ex: writing style={{width: '300'}}. Unitless number values like width: 300 are unchanged. @pluma in #5140
Synthetic Events will now warn when setting and accessing properties (which will not get cleared appropriately), as well as warn on access after an event has been returned to the pool.
@@ -266,7 +267,7 @@ Minified build for production: h
Minified exception occurred; use the non-minified dev environment for the full error message and additional helpful warnings.
-
In order to make debugging in production easier, we're introducing an Error Code System in 15.2.0. We developed a gulp script that collects all of our invariant error messages and folds them to a JSON file, and at build-time Babel uses the JSON to rewrite our invariant calls in production to reference the corresponding error IDs. Now when things go wrong in production, the error that React throws will contain a URL with an error ID and relevant information. The URL will point you to a page in our documentation where the original error message gets reassembled.
+
In order to make debugging in production easier, we're introducing an Error Code System in 15.2.0. We developed a gulp script that collects all of our invariant error messages and folds them to a JSON file, and at build-time Babel uses the JSON to rewrite our invariant calls in production to reference the corresponding error IDs. Now when things go wrong in production, the error that React throws will contain a URL with an error ID and relevant information. The URL will point you to a page in our documentation where the original error message gets reassembled.
While we hope you don't see errors often, you can see how it works here. This is what the same error from above will look like:
In March we added support for server-side rendering and for creating multiple instances of Relay on a single page. This was a coordinated effort over the course of several months by community members Denis Nedelyaev and Gerald Monaco (now at Facebook).
-
Also in March we added support for React Native. While we use Relay and React Native together internally, they didn't quite work together in open-source out of the box. We owe a big thanks to Adam Miskiewicz, Tom Burns, Gaëtan Renaudeau, David Aurelio, Martín Bigio, Paul O’Shannessy, Ben Alpert, and many others who helped track down and resolve issues. Finally, thanks to Steven Luscher for coordinating this effort and building the first Relay/ReactNative example app.
+
Also in March we added support for React Native. While we use Relay and React Native together internally, they didn't quite work together in open-source out of the box. We owe a big thanks to Adam Miskiewicz, Tom Burns, Gaëtan Renaudeau, David Aurelio, Martín Bigio, Paul O’Shannessy, Sophie Alpert, and many others who helped track down and resolve issues. Finally, thanks to Steven Luscher for coordinating this effort and building the first Relay/ReactNative example app.
We've also seen some great open-source projects spring up around Relay:
You can now return an array of elements from a component's render method. Like with other arrays, you'll need to add a key to each element to avoid the key warning:
+
render(){
+ // No need to wrap list items in an extra element!
+ return[
+ // Don't forget the keys :)
+ <likey="A">Firstitem</li>,
+ <likey="B">Seconditem</li>,
+ <likey="C">Thirditem</li>,
+ ];
+}
+
+
In the future, we'll likely add a special fragment syntax to JSX that doesn't require keys.
Previously, runtime errors during rendering could put React in a broken state, producing cryptic error messages and requiring a page refresh to recover. To address this problem, React 16 uses a more resilient error-handling strategy. By default, if an error is thrown inside a component's render or lifecycle methods, the whole component tree is unmounted from the root. This prevents the display of corrupted data. However, it's probably not the ideal user experience.
+
+
Instead of unmounting the whole app every time there's an error, you can use error boundaries. Error boundaries are special components that capture errors inside their subtree and display a fallback UI in its place. Think of error boundaries like try-catch statements, but for React components.
Portals provide a first-class way to render children into a DOM node that exists outside the DOM hierarchy of the parent component.
+
render(){
+ // React does *not* create a new div. It renders the children into `domNode`.
+ // `domNode` is any valid DOM node, regardless of its location in the DOM.
+ returnReactDOM.createPortal(
+ this.props.children,
+ domNode,
+ );
+}
+
React 16 includes a completely rewritten server renderer. It's really fast. It supports streaming, so you can start sending bytes to the client faster. And thanks to a new packaging strategy that compiles away process.env checks (Believe it or not, reading process.env in Node is really slow!), you no longer need to bundle React to get good server-rendering performance.
+
+
Core team member Sasha Aickin wrote a great article describing React 16's SSR improvements. According to Sasha's synthetic benchmarks, server rendering in React 16 is roughly three times faster than React 15. "When comparing against React 15 with process.env compiled out, there’s about a 2.4x improvement in Node 4, about a 3x performance improvement in Node 6, and a full 3.8x improvement in the new Node 8.4 release. And if you compare against React 15 without compilation, React 16 has a full order of magnitude gain in SSR in the latest version of Node!" (As Sasha points out, please be aware that these numbers are based on synthetic benchmarks and may not reflect real-world performance.)
+
+
In addition, React 16 is better at hydrating server-rendered HTML once it reaches the client. It no longer requires the initial render to exactly match the result from the server. Instead, it will attempt to reuse as much of the existing DOM as possible. No more checksums! In general, we don't recommend that you render different content on the client versus the server, but it can be useful in some cases (e.g. timestamps).
Instead of ignoring unrecognized HTML and SVG attributes, React will now pass them through to the DOM. This has the added benefit of allowing us to get rid of most of React's attribute whitelist, resulting in reduced file sizes.
+
+
Reduced file size
+
+
Despite all these additions, React 16 is actually smaller compared to 15.6.1!
+
+
+
react is 5.3 kb (2.2 kb gzipped), down from 20.7 kb (6.9 kb gzipped).
+
react-dom is 103.7 kb (32.6 kb gzipped), down from 141 kb (42.9 kb gzipped).
+
react + react-dom is 109 kb (34.8 kb gzipped), down from 161.7 kb (49.8 kb gzipped).
+
+
+
That amounts to a combined 32% size decrease compared to the previous version (30% post-gzip).
+
+
The size difference is partly attributable to a change in packaging. React now uses Rollup to create flat bundles for each of its different target formats, resulting in both size and runtime performance wins. The flat bundle format also means that React's impact on bundle size is roughly consistent regardless of how your ship your app, whether it's with Webpack, Browserify, the pre-built UMD bundles, or any other system.
+
+
MIT licensed
+
+
In case you missed it, React 16 is available under the MIT license. We've also published React 15.6.2 under MIT, for those who are unable to upgrade immediately.
+
+
New core architecture
+
+
React 16 is the first version of React built on top of a new core architecture, codenamed "Fiber." You can read all about this project over on Facebook's engineering blog. (Spoiler: we rewrote React!)
+
+
Fiber is responsible for most of the new features in React 16, like error boundaries and fragments. Over the next few releases, you can expect more new features as we begin to unlock the full potential of React.
+
+
Perhaps the most exciting area we're working on is async rendering—a strategy for cooperatively scheduling rendering work by periodically yielding execution to the browser. The upshot is that, with async rendering, apps are more responsive because React avoids blocking the main thread.
+
+
This demo provides an early peek at the types of problems async rendering can solve:
We think async rendering is a big deal, and represents the future of React. To make migration to v16.0 as smooth as possible, we're not enabling any async features yet, but we're excited to start rolling them out in the coming months. Stay tuned!
Although React 16 includes significant internal changes, in terms of upgrading, you can think of this like any other major React release. We've been serving React 16 to Facebook and Messenger.com users since earlier this year, and we released several beta and release candidate versions to flush out additional issues. With minor exceptions, if your app runs in 15.6 without any warnings, it should work in 16.
+
+
New deprecations
+
+
Hydrating a server-rendered container now has an explicit API. If you're reviving server-rendered HTML, use ReactDOM.hydrate instead of ReactDOM.render. Keep using ReactDOM.render if you're just doing client-side rendering.
+
+
React Addons
+
+
As previously announced, we've discontinued support for React Addons. We expect the latest version of each addon (except react-addons-perf; see below) to work for the foreseeable future, but we won't publish additional updates.
React 16 includes a number of small breaking changes. These only affect uncommon use cases and we don't expect them to break most apps.
+
+
+
React 15 had limited, undocumented support for error boundaries using unstable_handleError. This method has been renamed to componentDidCatch. You can use a codemod to automatically migrate to the new API.
+
ReactDOM.render and ReactDOM.unstable_renderIntoContainer now return null if called from inside a lifecycle method. To work around this, you can use portals or refs.
+
setState:
+
+
+
Calling setState with null no longer triggers an update. This allows you to decide in an updater function if you want to re-render.
+
Calling setState directly in render always causes an update. This was not previously the case. Regardless, you should not be calling setState from render.
+
setState callbacks (second argument) now fire immediately after componentDidMount / componentDidUpdate instead of after all components have rendered.
+
+
When replacing <A /> with <B />, B.componentWillMount now always happens before A.componentWillUnmount. Previously, A.componentWillUnmount could fire first in some cases.
+
Previously, changing the ref to a component would always detach the ref before that component's render is called. Now, we change the ref later, when applying the changes to the DOM.
+
It is not safe to re-render into a container that was modified by something other than React. This worked previously in some cases but was never supported. We now emit a warning in this case. Instead you should clean up your component trees using ReactDOM.unmountComponentAtNode. See this example.
+
componentDidUpdate lifecycle no longer receives prevContext param. (See #8631)
+
Shallow renderer no longer calls componentDidUpdate because DOM refs are not available. This also makes it consistent with componentDidMount (which does not get called in previous versions either).
+
Shallow renderer does not implement unstable_batchedUpdates anymore.
+
+
+
Packaging
+
+
+
There is no react/lib/* and react-dom/lib/* anymore. Even in CommonJS environments, React and ReactDOM are precompiled to single files (“flat bundles”). If you previously relied on undocumented React internals, and they don’t work anymore, let us know about your specific case in a new issue, and we’ll try to figure out a migration strategy for you.
+
There is no react-with-addons.js build anymore. All compatible addons are published separately on npm, and have single-file browser versions if you need them.
+
The deprecations introduced in 15.x have been removed from the core package. React.createClass is now available as create-react-class, React.PropTypes as prop-types, React.DOM as react-dom-factories, react-addons-test-utils as react-dom/test-utils, and shallow renderer as react-test-renderer/shallow. See 15.5.0 and 15.6.0 blog posts for instructions on migrating code and automated codemods.
+
The names and paths to the single-file browser builds have changed to emphasize the difference between development and production builds. For example:
+
+
React 16 depends on the collection types Map and Set. If you support older browsers and devices which may not yet provide these natively (e.g. IE < 11), consider including a global polyfill in your bundled application, such as core-js or babel-polyfill.
+
+
A polyfilled environment for React 16 using core-js to support older browsers might look like:
As always, this release would not have been possible without our open source contributors. Thanks to everyone who filed bugs, opened PRs, responded to issues, wrote documentation, and more!
You can now return an array of elements from a component's render method. Like with other arrays, you'll need to add a key to each element to avoid the key warning:
+
render(){
+ // No need to wrap list items in an extra element!
+ return[
+ // Don't forget the keys :)
+ <likey="A">Firstitem</li>,
+ <likey="B">Seconditem</li>,
+ <likey="C">Thirditem</li>,
+ ];
+}
+
+
In the future, we'll likely add a special fragment syntax to JSX that doesn't require keys.
Previously, runtime errors during rendering could put React in a broken state, producing cryptic error messages and requiring a page refresh to recover. To address this problem, React 16 uses a more resilient error-handling strategy. By default, if an error is thrown inside a component's render or lifecycle methods, the whole component tree is unmounted from the root. This prevents the display of corrupted data. However, it's probably not the ideal user experience.
+
+
Instead of unmounting the whole app every time there's an error, you can use error boundaries. Error boundaries are special components that capture errors inside their subtree and display a fallback UI in its place. Think of error boundaries like try-catch statements, but for React components.
Portals provide a first-class way to render children into a DOM node that exists outside the DOM hierarchy of the parent component.
+
render(){
+ // React does *not* create a new div. It renders the children into `domNode`.
+ // `domNode` is any valid DOM node, regardless of its location in the DOM.
+ returnReactDOM.createPortal(
+ this.props.children,
+ domNode,
+ );
+}
+
React 16 includes a completely rewritten server renderer. It's really fast. It supports streaming, so you can start sending bytes to the client faster. And thanks to a new packaging strategy that compiles away process.env checks (Believe it or not, reading process.env in Node is really slow!), you no longer need to bundle React to get good server-rendering performance.
+
+
Core team member Sasha Aickin wrote a great article describing React 16's SSR improvements. According to Sasha's synthetic benchmarks, server rendering in React 16 is roughly three times faster than React 15. "When comparing against React 15 with process.env compiled out, there’s about a 2.4x improvement in Node 4, about a 3x performance improvement in Node 6, and a full 3.8x improvement in the new Node 8.4 release. And if you compare against React 15 without compilation, React 16 has a full order of magnitude gain in SSR in the latest version of Node!" (As Sasha points out, please be aware that these numbers are based on synthetic benchmarks and may not reflect real-world performance.)
+
+
In addition, React 16 is better at hydrating server-rendered HTML once it reaches the client. It no longer requires the initial render to exactly match the result from the server. Instead, it will attempt to reuse as much of the existing DOM as possible. No more checksums! In general, we don't recommend that you render different content on the client versus the server, but it can be useful in some cases (e.g. timestamps).
Instead of ignoring unrecognized HTML and SVG attributes, React will now pass them through to the DOM. This has the added benefit of allowing us to get rid of most of React's attribute whitelist, resulting in reduced file sizes.
+
+
Reduced file size
+
+
Despite all these additions, React 16 is actually smaller compared to 15.6.1!
+
+
+
react is 5.3 kb (2.2 kb gzipped), down from 20.7 kb (6.9 kb gzipped).
+
react-dom is 103.7 kb (32.6 kb gzipped), down from 141 kb (42.9 kb gzipped).
+
react + react-dom is 109 kb (34.8 kb gzipped), down from 161.7 kb (49.8 kb gzipped).
+
+
+
That amounts to a combined 32% size decrease compared to the previous version (30% post-gzip).
+
+
The size difference is partly attributable to a change in packaging. React now uses Rollup to create flat bundles for each of its different target formats, resulting in both size and runtime performance wins. The flat bundle format also means that React's impact on bundle size is roughly consistent regardless of how your ship your app, whether it's with Webpack, Browserify, the pre-built UMD bundles, or any other system.
+
+
MIT licensed
+
+
In case you missed it, React 16 is available under the MIT license. We've also published React 15.6.2 under MIT, for those who are unable to upgrade immediately.
+
+
New core architecture
+
+
React 16 is the first version of React built on top of a new core architecture, codenamed "Fiber." You can read all about this project over on Facebook's engineering blog. (Spoiler: we rewrote React!)
+
+
Fiber is responsible for most of the new features in React 16, like error boundaries and fragments. Over the next few releases, you can expect more new features as we begin to unlock the full potential of React.
+
+
Perhaps the most exciting area we're working on is async rendering—a strategy for cooperatively scheduling rendering work by periodically yielding execution to the browser. The upshot is that, with async rendering, apps are more responsive because React avoids blocking the main thread.
+
+
This demo provides an early peek at the types of problems async rendering can solve:
We think async rendering is a big deal, and represents the future of React. To make migration to v16.0 as smooth as possible, we're not enabling any async features yet, but we're excited to start rolling them out in the coming months. Stay tuned!
Although React 16 includes significant internal changes, in terms of upgrading, you can think of this like any other major React release. We've been serving React 16 to Facebook and Messenger.com users since earlier this year, and we released several beta and release candidate versions to flush out additional issues. With minor exceptions, if your app runs in 15.6 without any warnings, it should work in 16.
+
+
New deprecations
+
+
Hydrating a server-rendered container now has an explicit API. If you're reviving server-rendered HTML, use ReactDOM.hydrate instead of ReactDOM.render. Keep using ReactDOM.render if you're just doing client-side rendering.
+
+
React Addons
+
+
As previously announced, we've discontinued support for React Addons. We expect the latest version of each addon (except react-addons-perf; see below) to work for the foreseeable future, but we won't publish additional updates.
React 16 includes a number of small breaking changes. These only affect uncommon use cases and we don't expect them to break most apps.
+
+
+
React 15 had limited, undocumented support for error boundaries using unstable_handleError. This method has been renamed to componentDidCatch. You can use a codemod to automatically migrate to the new API.
+
ReactDOM.render and ReactDOM.unstable_renderIntoContainer now return null if called from inside a lifecycle method. To work around this, you can use portals or refs.
+
setState:
+
+
+
Calling setState with null no longer triggers an update. This allows you to decide in an updater function if you want to re-render.
+
Calling setState directly in render always causes an update. This was not previously the case. Regardless, you should not be calling setState from render.
+
setState callbacks (second argument) now fire immediately after componentDidMount / componentDidUpdate instead of after all components have rendered.
+
+
When replacing <A /> with <B />, B.componentWillMount now always happens before A.componentWillUnmount. Previously, A.componentWillUnmount could fire first in some cases.
+
Previously, changing the ref to a component would always detach the ref before that component's render is called. Now, we change the ref later, when applying the changes to the DOM.
+
It is not safe to re-render into a container that was modified by something other than React. This worked previously in some cases but was never supported. We now emit a warning in this case. Instead you should clean up your component trees using ReactDOM.unmountComponentAtNode. See this example.
+
componentDidUpdate lifecycle no longer receives prevContext param. (See #8631)
+
Shallow renderer no longer calls componentDidUpdate because DOM refs are not available. This also makes it consistent with componentDidMount (which does not get called in previous versions either).
+
Shallow renderer does not implement unstable_batchedUpdates anymore.
+
+
+
Packaging
+
+
+
There is no react/lib/* and react-dom/lib/* anymore. Even in CommonJS environments, React and ReactDOM are precompiled to single files (“flat bundles”). If you previously relied on undocumented React internals, and they don’t work anymore, let us know about your specific case in a new issue, and we’ll try to figure out a migration strategy for you.
+
There is no react-with-addons.js build anymore. All compatible addons are published separately on npm, and have single-file browser versions if you need them.
+
The deprecations introduced in 15.x have been removed from the core package. React.createClass is now available as create-react-class, React.PropTypes as prop-types, React.DOM as react-dom-factories, react-addons-test-utils as react-dom/test-utils, and shallow renderer as react-test-renderer/shallow. See 15.5.0 and 15.6.0 blog posts for instructions on migrating code and automated codemods.
+
The names and paths to the single-file browser builds have changed to emphasize the difference between development and production builds. For example:
+
+
React 16 depends on the collection types Map and Set. If you support older browsers and devices which may not yet provide these natively (e.g. IE < 11), consider including a global polyfill in your bundled application, such as core-js or babel-polyfill.
+
+
A polyfilled environment for React 16 using core-js to support older browsers might look like:
As always, this release would not have been possible without our open source contributors. Thanks to everyone who filed bugs, opened PRs, responded to issues, wrote documentation, and more!
Less than a year ago, we introduced Create React App as an officially supported way to create apps with zero configuration. The project has since enjoyed tremendous growth, with over 950 commits by more than 250 contributors.
-
-
Today, we are excited to announce that many features that have been in the pipeline for the last few months are finally released.
-
-
As usual with Create React App, you can enjoy these improvements in your existing non-ejected apps by updating a single dependency and following our migration instructions.
-
-
Newly created apps will get these improvements automatically.
We have upgraded to webpack 2 which has been officially released a few months ago. It is a big upgrade with many bugfixes and general improvements. We have been testing it for a while, and now consider it stable enough to recommend it to everyone.
-
-
While the Webpack configuration format has changed, Create React App users who didn't eject don't need to worry about it as we have updated the configuration on our side.
-
-
If you had to eject your app for one reason or another, Webpack provides a configuration migration guide that you can follow to update your apps. Note that with each release of Create React App, we are working to support more use cases out of the box so that you don't have to eject in the future.
-
-
The biggest notable webpack 2 feature is the ability to write and import ES6 modules directly without compiling them to CommonJS. This shouldn’t affect how you write code since you likely already use import and export statements, but it will help catch more mistakes like missing named exports at compile time:
-
-
-
-
In the future, as the ecosystem around ES6 modules matures, you can expect more improvements to your app's bundle size thanks to tree shaking.
Have you ever made a mistake in code and only realized it after the console is flooded with cryptic errors? Or worse, have you ever shipped an app with crashes in production because you accidentally missed an error in development?
-
-
To address these issues, we are introducing an overlay that pops up whenever there is an uncaught error in your application. It only appears in development, and you can dismiss it by pressing Escape.
-
-
A GIF is worth a thousand words:
-
-
-
-
(Yes, it integrates with your editor!)
-
-
In the future, we plan to teach the runtime error overlay to understand more about your React app. For example, after React 16 we plan to show React component stacks in addition to the JavaScript stacks when an error is thrown.
Newly created projects are built as Progressive Web Apps by default. This means that they employ service workers with an offline-first caching strategy to minimize the time it takes to serve the app to the users who visit it again. You can opt out of this behavior, but we recommend it both for new and existing apps, especially if you target mobile devices.
-
-
-
-
New apps automatically have these features, but you can easily convert an existing project to a Progressive Web App by following our migration guide.
We are now using the latest version of Jest that includes numerous bugfixes and improvements. You can read more about the changes in Jest 19 and Jest 20 blog posts.
It is important to keep the initial JavaScript payload of web apps down to the minimum, and load the rest of the code on demand. Although Create React App supported code splitting using require.ensure() since the first release, it used a webpack-specific syntax that did not work in Jest or other environments.
-
-
In this release, we are adding support for the dynamic import() proposal which aligns with the future web standards. Unlike require.ensure(), it doesn't break Jest tests, and should eventually become a part of JavaScript. We encourage you to use import() to delay loading the code for non-critical component subtrees until you need to render them.
We have improved the console output across the board.
-
-
For example, when you start the development server, we now display the LAN address in additional to the localhost address so that you can quickly access the app from a mobile device on the same network:
-
-
-
-
When lint errors are reported, we no longer show the warnings so that you can concentrate on more critical issues. Errors and warnings in the production build output are better formatted, and the build error overlay font size now matches the browser font size more closely.
You can read the full changelog and the migration guide in the v1.0.0 release notes.
-
-
Acknowledgements
-
-
This release is a result of months of work from many people in the React community. It is focused on improving both developer and end user experience, as we believe they are complementary and go hand in hand.
-
-
We are grateful to everyone who has offered their contributions, whether in code, documentation, or by helping other people. We would like to specifically thank Joe Haddad for his invaluable help maintaining the project.
-
-
We are excited to bring these improvements to everybody using Create React App, and we are looking forward to more of your feedback and contributions.
In January at React.js Conf, we announced React Native, a new framework for building native apps using React. We're happy to announce that we're open-sourcing React Native and you can start building your apps with it today.
What we really want is the user experience of the native mobile platforms, combined with the developer experience we have when building with React on the web.
+
+
With a bit of work, we can make it so the exact same React that's on GitHub can power truly native mobile applications. The only difference in the mobile environment is that instead of running React in the browser and rendering to divs and spans, we run it an embedded instance of JavaScriptCore inside our apps and render to higher-level platform-specific components.
+
+
It's worth noting that we're not chasing “write once, run anywhere.” Different platforms have different looks, feels, and capabilities, and as such, we should still be developing discrete apps for each platform, but the same set of engineers should be able to build applications for whatever platform they choose, without needing to learn a fundamentally different set of technologies for each. We call this approach “learn once, write anywhere.”
Thanks to everybody who has already been testing the release candidate. We've received some good feedback and as a result we're going to do a second release candidate. The changes are minimal. We haven't changed the behavior of any APIs we exposed in the previous release candidate. Here's a summary of the changes:
-
-
-
Introduced a new API (React.cloneElement, see below for details).
-
Fixed a bug related to validating propTypes when using the new React.addons.createFragment API.
We've also published version 0.13.0-rc2 of the react and react-tools packages on npm and the react package on bower.
-
-
-
-
React.cloneElement
-
-
In React v0.13 RC2 we will introduce a new API, similar to React.addons.cloneWithProps, with this signature:
-
React.cloneElement(element,props,...children);
-
-
Unlike cloneWithProps, this new function does not have any magic built-in behavior for merging style and className for the same reason we don't have that feature from transferPropsTo. Nobody is sure what exactly the complete list of magic things are, which makes it difficult to reason about the code and difficult to reuse when style has a different signature (e.g. in the upcoming React Native).
However, unlike JSX and cloneWithProps, it also preserves refs. This means that if you get a child with a ref on it, you won't accidentally steal it from your ancestor. You will get the same ref attached to your new element.
-
-
One common pattern is to map over your children and add a new prop. There were many issues reported about cloneWithProps losing the ref, making it harder to reason about your code. Now following the same pattern with cloneElement will work as expected. For example:
Note: React.cloneElement(child, { ref: 'newRef' })DOES override the ref so it is still not possible for two parents to have a ref to the same child, unless you use callback-refs.
-
-
-
This was a critical feature to get into React 0.13 since props are now immutable. The upgrade path is often to clone the element, but by doing so you might lose the ref. Therefore, we needed a nicer upgrade path here. As we were upgrading callsites at Facebook we realized that we needed this method. We got the same feedback from the community. Therefore we decided to make another RC before the final release to make sure we get this in.
-
-
We plan to eventually deprecate React.addons.cloneWithProps. We're not doing it yet, but this is a good opportunity to start thinking about your own uses and consider using React.cloneElement instead. We'll be sure to ship a release with deprecation notices before we actually remove it so no immediate action is necessary.
Thanks to everybody who has already been testing the release candidate. We've received some good feedback and as a result we're going to do a second release candidate. The changes are minimal. We haven't changed the behavior of any APIs we exposed in the previous release candidate. Here's a summary of the changes:
+
+
+
Introduced a new API (React.cloneElement, see below for details).
+
Fixed a bug related to validating propTypes when using the new React.addons.createFragment API.
We've also published version 0.13.0-rc2 of the react and react-tools packages on npm and the react package on bower.
+
+
+
+
React.cloneElement
+
+
In React v0.13 RC2 we will introduce a new API, similar to React.addons.cloneWithProps, with this signature:
+
React.cloneElement(element,props,...children);
+
+
Unlike cloneWithProps, this new function does not have any magic built-in behavior for merging style and className for the same reason we don't have that feature from transferPropsTo. Nobody is sure what exactly the complete list of magic things are, which makes it difficult to reason about the code and difficult to reuse when style has a different signature (e.g. in the upcoming React Native).
However, unlike JSX and cloneWithProps, it also preserves refs. This means that if you get a child with a ref on it, you won't accidentally steal it from your ancestor. You will get the same ref attached to your new element.
+
+
One common pattern is to map over your children and add a new prop. There were many issues reported about cloneWithProps losing the ref, making it harder to reason about your code. Now following the same pattern with cloneElement will work as expected. For example:
Note: React.cloneElement(child, { ref: 'newRef' })DOES override the ref so it is still not possible for two parents to have a ref to the same child, unless you use callback-refs.
+
+
+
This was a critical feature to get into React 0.13 since props are now immutable. The upgrade path is often to clone the element, but by doing so you might lose the ref. Therefore, we needed a nicer upgrade path here. As we were upgrading callsites at Facebook we realized that we needed this method. We got the same feedback from the community. Therefore we decided to make another RC before the final release to make sure we get this in.
+
+
We plan to eventually deprecate React.addons.cloneWithProps. We're not doing it yet, but this is a good opportunity to start thinking about your own uses and consider using React.cloneElement instead. We'll be sure to ship a release with deprecation notices before we actually remove it so no immediate action is necessary.
- Tom Occhino, Ben Alpert, Lee Byron, Christopher Chedeau, Sebastian Markbåge, Jing Chen, and Dan Schafer closed the conference with a Q&A session.
+ Tom Occhino, Sophie Alpert, Lee Byron, Christopher Chedeau, Sebastian Markbåge, Jing Chen, and Dan Schafer closed the conference with a Q&A session.
React 0.13 has a lot of nice features but there is one particular feature that I'm really excited about. I couldn't wait for React.js Conf to start tomorrow morning.
-
-
Maybe you're like me and staying up late excited about the conference, or maybe you weren't one of the lucky ones to get a ticket. Either way I figured I'd give you all something to play with until then.
-
-
We just published a beta version of React v0.13.0 to npm! You can install it with npm install react@0.13.0-beta.1. Since this is a pre-release, we don't have proper release notes ready.
-
-
So what is that one feature I'm so excited about that I just couldn't wait to share?
-
-
Plain JavaScript Classes!!
-
-
JavaScript originally didn't have a built-in class system. Every popular framework built their own, and so did we. This means that you have a learn slightly different semantics for each framework.
-
-
We figured that we're not in the business of designing a class system. We just want to use whatever is the idiomatic JavaScript way of creating classes.
-
-
In React 0.13.0 you no longer need to use React.createClass to create React components. If you have a transpiler you can use ES6 classes today. You can use the transpiler we ship with react-tools by making use of the harmony option: jsx --harmony.
The API is mostly what you would expect, with the exception of getInitialState. We figured that the idiomatic way to specify class state is to just use a simple instance property. Likewise getDefaultProps and propTypes are really just properties on the constructor.
Wait, assigning to properties seems like a very imperative way of defining classes! You're right, however, we designed it this way because it's idiomatic. We fully expect a more declarative syntax for property initialization to arrive in future version of JavaScript. It might look something like this:
This was inspired by TypeScript's property initializers.
-
-
Autobinding
-
-
React.createClass has a built-in magic feature that bound all methods to this automatically for you. This can be a little confusing for JavaScript developers that are not used to this feature in other classes, or it can be confusing when they move from React to other classes.
-
-
Therefore we decided not to have this built-in into React's class model. You can still explicitly prebind methods in your constructor if you want.
Unfortunately, we will not launch any mixin support for ES6 classes in React. That would defeat the purpose of only using idiomatic JavaScript concepts.
-
-
There is no standard and universal way to define mixins in JavaScript. In fact, several features to support mixins were dropped from ES6 today. There are a lot of libraries with different semantics. We think that there should be one way of defining mixins that you can use for any JavaScript class. React just making another doesn't help that effort.
-
-
Therefore, we will keep working with the larger JS community to create a standard for mixins. We will also start designing a new compositional API that will help make common tasks easier to do without mixins. E.g. first-class subscriptions to any kind of Flux store.
-
-
Luckily, if you want to keep using mixins, you can just keep using React.createClass.
-
-
-
Note:
-
-
The classic React.createClass style of creating classes will continue to work just fine.
-
-
-
Other Languages!
-
-
Since these classes are just plain old JavaScript classes, you can use other languages that compile to JavaScript classes, such as TypeScript.
React 0.13 has a lot of nice features but there is one particular feature that I'm really excited about. I couldn't wait for React.js Conf to start tomorrow morning.
+
+
Maybe you're like me and staying up late excited about the conference, or maybe you weren't one of the lucky ones to get a ticket. Either way I figured I'd give you all something to play with until then.
+
+
We just published a beta version of React v0.13.0 to npm! You can install it with npm install react@0.13.0-beta.1. Since this is a pre-release, we don't have proper release notes ready.
+
+
So what is that one feature I'm so excited about that I just couldn't wait to share?
+
+
Plain JavaScript Classes!!
+
+
JavaScript originally didn't have a built-in class system. Every popular framework built their own, and so did we. This means that you have a learn slightly different semantics for each framework.
+
+
We figured that we're not in the business of designing a class system. We just want to use whatever is the idiomatic JavaScript way of creating classes.
+
+
In React 0.13.0 you no longer need to use React.createClass to create React components. If you have a transpiler you can use ES6 classes today. You can use the transpiler we ship with react-tools by making use of the harmony option: jsx --harmony.
The API is mostly what you would expect, with the exception of getInitialState. We figured that the idiomatic way to specify class state is to just use a simple instance property. Likewise getDefaultProps and propTypes are really just properties on the constructor.
Wait, assigning to properties seems like a very imperative way of defining classes! You're right, however, we designed it this way because it's idiomatic. We fully expect a more declarative syntax for property initialization to arrive in future version of JavaScript. It might look something like this:
This was inspired by TypeScript's property initializers.
+
+
Autobinding
+
+
React.createClass has a built-in magic feature that bound all methods to this automatically for you. This can be a little confusing for JavaScript developers that are not used to this feature in other classes, or it can be confusing when they move from React to other classes.
+
+
Therefore we decided not to have this built-in into React's class model. You can still explicitly prebind methods in your constructor if you want.
Unfortunately, we will not launch any mixin support for ES6 classes in React. That would defeat the purpose of only using idiomatic JavaScript concepts.
+
+
There is no standard and universal way to define mixins in JavaScript. In fact, several features to support mixins were dropped from ES6 today. There are a lot of libraries with different semantics. We think that there should be one way of defining mixins that you can use for any JavaScript class. React just making another doesn't help that effort.
+
+
Therefore, we will keep working with the larger JS community to create a standard for mixins. We will also start designing a new compositional API that will help make common tasks easier to do without mixins. E.g. first-class subscriptions to any kind of Flux store.
+
+
Luckily, if you want to keep using mixins, you can just keep using React.createClass.
+
+
+
Note:
+
+
The classic React.createClass style of creating classes will continue to work just fine.
+
+
+
Other Languages!
+
+
Since these classes are just plain old JavaScript classes, you can use other languages that compile to JavaScript classes, such as TypeScript.
We're happy to announce the availability of React v0.12! After over a week of baking as the release candidate, we uncovered and fixed a few small issues. Thanks to all of you who upgraded and gave us feedback!
-
-
We have talked a lot about some of the bigger changes in this release. We introduced new terminology and changed APIs to clean up and simplify some of the concepts of React. We also made several changes to JSX and deprecated a few functions. We won't go into depth about these changes again but we encourage you to read up on these changes in the linked posts. We'll summarize these changes and discuss some of the other changes and how they may impact you below. As always, a full changelog is also included below.
We've also published version 0.12.0 of the react and react-tools packages on npm and the react package on bower.
-
-
New Terminology & Updated APIs
-
-
v0.12 is bringing about some new terminology. We introduced this 2 weeks ago and we've also documented it in a new section of the documentation. As a part of this, we also corrected many of our top-level APIs to align with the terminology. Component has been removed from all of our React.render* methods. While at one point the argument you passed to these functions was called a Component, it no longer is. You are passing ReactElements. To align with render methods in your component classes, we decided to keep the top-level functions short and sweet. React.renderComponent is now React.render.
-
-
We also corrected some other misnomers. React.isValidComponent actually determines if the argument is a ReactElement, so it has been renamed to React.isValidElement. In the same vein, React.PropTypes.component is now React.PropTypes.element and React.PropTypes.renderable is now React.PropTypes.node.
-
-
The old methods will still work but will warn upon first use. They will be removed in v0.13.
We no longer transform to a straight function call. <Component/> now becomes React.createElement(Component)
-
DOM components don't make use of React.DOM, instead we pass the tag name directly. <div/> becomes React.createElement('div')
-
We introduced spread attributes as a quick way to transfer props.
-
-
-
DevTools Improvements, No More __internals
-
-
For months we've gotten complaints about the React DevTools message. It shouldn't have logged the up-sell message when you were already using the DevTools. Unfortunately this was because the way we implemented these tools resulted in the DevTools knowing about React, but not the reverse. We finally gave this some attention and enabled React to know if the DevTools are installed. We released an update to the devtools several weeks ago making this possible. Extensions in Chrome should auto-update so you probably already have the update installed!
-
-
As a result of this update, we no longer need to expose several internal modules to the world. If you were taking advantage of this implementation detail, your code will break. React.__internals is no more.
-
-
License Change - BSD
-
-
We updated the license on React to the BSD 3-Clause license with an explicit patent grant. Previously we used the Apache 2 license. These licenses are very similar and our extra patent grant is equivalent to the grant provided in the Apache license. You can still use React with the confidence that we have granted the use of any patents covering it. This brings us in line with the same licensing we use across the majority of our open source projects at Facebook.
-
-
You can read the full text of the LICENSE and PATENTS files on GitHub.
-
-
-
-
Changelog
-
-
React Core
-
-
Breaking Changes
-
-
-
key and ref moved off props object, now accessible on the element directly
-
React is now BSD licensed with accompanying Patents grant
-
Default prop resolution has moved to Element creation time instead of mount time, making them effectively static
-
React.__internals is removed - it was exposed for DevTools which no longer needs access
-
Composite Component functions can no longer be called directly - they must be wrapped with React.createFactory first. This is handled for you when using JSX.
-
-
-
New Features
-
-
-
Spread operator ({...}) introduced to deprecate this.transferPropsTo
-
Added support for more HTML attributes: acceptCharset, classID, manifest
DEPRECATED Returning false from event handlers to preventDefault
-
DEPRECATED Convenience Constructor usage as function, instead wrap with React.createFactory
-
DEPRECATED use of key={null} to assign implicit keys
-
-
-
Bug Fixes
-
-
-
Better handling of events and updates in nested results, fixing value restoration in "layered" controlled components
-
Correctly treat event.getModifierState as case sensitive
-
Improved normalization of event.charCode
-
Better error stacks when involving autobound methods
-
Removed DevTools message when the DevTools are installed
-
Correctly detect required language features across browsers
-
Fixed support for some HTML attributes:
-
-
-
list updates correctly now
-
scrollLeft, scrollTop removed, these should not be specified as props
-
-
Improved error messages
-
-
-
React With Addons
-
-
New Features
-
-
-
React.addons.batchedUpdates added to API for hooking into update cycle
-
-
-
Breaking Changes
-
-
-
React.addons.update uses assign instead of copyProperties which does hasOwnProperty checks. Properties on prototypes will no longer be updated correctly.
-
-
-
Bug Fixes
-
-
-
Fixed some issues with CSS Transitions
-
-
-
JSX
-
-
Breaking Changes
-
-
-
Enforced convention: lower case tag names are always treated as HTML tags, upper case tag names are always treated as composite components
-
JSX no longer transforms to simple function calls
-
-
-
New Features
-
-
-
@jsx React.DOM no longer required
-
spread ({...}) operator introduced to allow easier use of props
-
-
-
Bug Fixes
-
-
-
JSXTransformer: Make sourcemaps an option when using APIs directly (eg, for react-rails)
We're happy to announce the availability of React v0.12! After over a week of baking as the release candidate, we uncovered and fixed a few small issues. Thanks to all of you who upgraded and gave us feedback!
+
+
We have talked a lot about some of the bigger changes in this release. We introduced new terminology and changed APIs to clean up and simplify some of the concepts of React. We also made several changes to JSX and deprecated a few functions. We won't go into depth about these changes again but we encourage you to read up on these changes in the linked posts. We'll summarize these changes and discuss some of the other changes and how they may impact you below. As always, a full changelog is also included below.
We've also published version 0.12.0 of the react and react-tools packages on npm and the react package on bower.
+
+
New Terminology & Updated APIs
+
+
v0.12 is bringing about some new terminology. We introduced this 2 weeks ago and we've also documented it in a new section of the documentation. As a part of this, we also corrected many of our top-level APIs to align with the terminology. Component has been removed from all of our React.render* methods. While at one point the argument you passed to these functions was called a Component, it no longer is. You are passing ReactElements. To align with render methods in your component classes, we decided to keep the top-level functions short and sweet. React.renderComponent is now React.render.
+
+
We also corrected some other misnomers. React.isValidComponent actually determines if the argument is a ReactElement, so it has been renamed to React.isValidElement. In the same vein, React.PropTypes.component is now React.PropTypes.element and React.PropTypes.renderable is now React.PropTypes.node.
+
+
The old methods will still work but will warn upon first use. They will be removed in v0.13.
We no longer transform to a straight function call. <Component/> now becomes React.createElement(Component)
+
DOM components don't make use of React.DOM, instead we pass the tag name directly. <div/> becomes React.createElement('div')
+
We introduced spread attributes as a quick way to transfer props.
+
+
+
DevTools Improvements, No More __internals
+
+
For months we've gotten complaints about the React DevTools message. It shouldn't have logged the up-sell message when you were already using the DevTools. Unfortunately this was because the way we implemented these tools resulted in the DevTools knowing about React, but not the reverse. We finally gave this some attention and enabled React to know if the DevTools are installed. We released an update to the devtools several weeks ago making this possible. Extensions in Chrome should auto-update so you probably already have the update installed!
+
+
As a result of this update, we no longer need to expose several internal modules to the world. If you were taking advantage of this implementation detail, your code will break. React.__internals is no more.
+
+
License Change - BSD
+
+
We updated the license on React to the BSD 3-Clause license with an explicit patent grant. Previously we used the Apache 2 license. These licenses are very similar and our extra patent grant is equivalent to the grant provided in the Apache license. You can still use React with the confidence that we have granted the use of any patents covering it. This brings us in line with the same licensing we use across the majority of our open source projects at Facebook.
+
+
You can read the full text of the LICENSE and PATENTS files on GitHub.
+
+
+
+
Changelog
+
+
React Core
+
+
Breaking Changes
+
+
+
key and ref moved off props object, now accessible on the element directly
+
React is now BSD licensed with accompanying Patents grant
+
Default prop resolution has moved to Element creation time instead of mount time, making them effectively static
+
React.__internals is removed - it was exposed for DevTools which no longer needs access
+
Composite Component functions can no longer be called directly - they must be wrapped with React.createFactory first. This is handled for you when using JSX.
+
+
+
New Features
+
+
+
Spread operator ({...}) introduced to deprecate this.transferPropsTo
+
Added support for more HTML attributes: acceptCharset, classID, manifest
DEPRECATED Returning false from event handlers to preventDefault
+
DEPRECATED Convenience Constructor usage as function, instead wrap with React.createFactory
+
DEPRECATED use of key={null} to assign implicit keys
+
+
+
Bug Fixes
+
+
+
Better handling of events and updates in nested results, fixing value restoration in "layered" controlled components
+
Correctly treat event.getModifierState as case sensitive
+
Improved normalization of event.charCode
+
Better error stacks when involving autobound methods
+
Removed DevTools message when the DevTools are installed
+
Correctly detect required language features across browsers
+
Fixed support for some HTML attributes:
+
+
+
list updates correctly now
+
scrollLeft, scrollTop removed, these should not be specified as props
+
+
Improved error messages
+
+
+
React With Addons
+
+
New Features
+
+
+
React.addons.batchedUpdates added to API for hooking into update cycle
+
+
+
Breaking Changes
+
+
+
React.addons.update uses assign instead of copyProperties which does hasOwnProperty checks. Properties on prototypes will no longer be updated correctly.
+
+
+
Bug Fixes
+
+
+
Fixed some issues with CSS Transitions
+
+
+
JSX
+
+
Breaking Changes
+
+
+
Enforced convention: lower case tag names are always treated as HTML tags, upper case tag names are always treated as composite components
+
JSX no longer transforms to simple function calls
+
+
+
New Features
+
+
+
@jsx React.DOM no longer required
+
spread ({...}) operator introduced to allow easier use of props
+
+
+
Bug Fixes
+
+
+
JSXTransformer: Make sourcemaps an option when using APIs directly (eg, for react-rails)
- September 24, 2014
- by
-
-
- Bill Fisher
-
-
-
-
-
-
-
-
-
A more up-to-date version of this post is available as part of the Flux documentation.
-
-
Flux is the application architecture that Facebook uses to build web applications with React. It's based on a unidirectional data flow. In previous blog posts and documentation articles, we've shown the basic structure and data flow, more closely examined the dispatcher and action creators, and shown how to put it all together with a tutorial. Now let's look at how to do formal unit testing of Flux applications with Jest, Facebook's auto-mocking testing framework.
-
-
Testing with Jest
-
-
For a unit test to operate on a truly isolated unit of the application, we need to mock every module except the one we are testing. Jest makes the mocking of other parts of a Flux application trivial. To illustrate testing with Jest, we'll return to our example TodoMVC application.
-
-
The first steps toward working with Jest are as follows:
-
-
-
Get the module dependencies for the application installed by running npm install.
-
Create a directory __tests__/ with a test file, in this case TodoStore-test.js
Now you're ready to run your tests from the command line with npm test.
-
-
By default, all modules are mocked, so the only boilerplate we need in TodoStore-test.js is a declarative call to Jest's dontMock() method.
-
jest.dontMock('TodoStore');
-
-
This tells Jest to let TodoStore be a real object with real, live methods. Jest will mock all other objects involved with the test.
-
-
Testing Stores
-
-
At Facebook, Flux stores often receive a great deal of formal unit test coverage, as this is where the application state and logic lives. Stores are arguably the most important place in a Flux application to provide coverage, but at first glance, it's not entirely obvious how to test them.
-
-
By design, stores can't be modified from the outside. They have no setters. The only way new data can enter a store is through the callback it registers with the dispatcher.
-
-
We therefore need to simulate the Flux data flow with this one weird trick.
We now have the store's registered callback, the sole mechanism by which data can enter the store.
-
-
For folks new to Jest, or mocks in general, it might not be entirely obvious what is happening in that code block, so let's look at each part of it a bit more closely. We start out by looking at the register() method of our application's dispatcher — the method that the store uses to register its callback with the dispatcher. The dispatcher has been thoroughly mocked automatically by Jest, so we can get a reference to the mocked version of the register() method just as we would normally refer to that method in our production code. But we can get additional information about that method with the mockproperty of that method. We don't often think of methods having properties, but in Jest, this idea is vital. Every method of a mocked object has this property, and it allows us to examine how the method is being called during the test. A chronologically ordered list of calls to register() is available with the calls property of mock, and each of these calls has a list of the arguments that were used in each method call.
-
-
So in this code, we are really saying, "Give me a reference to the first argument of the first call to MyDispatcher's register() method." That first argument is the store's callback, so now we have all we need to start testing. But first, we can save ourselves some semicolons and roll all of this into a single line:
We can invoke that callback whenever we like, independent of our application's dispatcher or action creators. We will, in fact, fake the behavior of the dispatcher and action creators by invoking the callback with an action that we'll create directly in our test.
The example Flux TodoMVC application has been updated with an example test for the TodoStore, but let's look at an abbreviated version of the entire test. The most important things to notice in this test are how we keep a reference to the store's registered callback in the closure of the test, and how we recreate the store before every test so that we clear the state of the store entirely.
Sometimes our stores rely on data from other stores. Because all of our modules are mocked, we'll need to simulate the data that comes from the other store. We can do this by retrieving the mock function and adding a custom return value to it.
Now we have a collection of objects that will come back from MyOtherStore whenever we call MyOtherStore.getState() in our tests. Any application state can be simulated with a combination of these custom return values and the previously shown technique of working with the store's registered callback.
-
-
A brief example of this technique is up on GitHub within the Flux Chat example's UnreadThreadStore-test.js.
-
-
For more information about the mock property of mocked methods or Jest's ability to provide custom mock values, see Jest's documentation on mock functions.
-
-
Moving Logic from React to Stores
-
-
What often starts as a little piece of seemingly benign logic in our React components often presents a problem while creating unit tests. We want to be able to write tests that read like a specification for our application's behavior, and when application logic slips into our view layer, this becomes more difficult.
-
-
For example, when a user has marked each of their to-do items as complete, the TodoMVC specification dictates that we should also change the status of the "Mark all as complete" checkbox automatically. To create that logic, we might be tempted to write code like this in our MainSection's render() method:
While this seems like an easy, normal thing to do, this is an example of application logic slipping into the views, and it can't be described in our spec-style TodoStore test. Let's take that logic and move it to the store. First, we'll create a public method on the store that will encapsulate that logic:
+ September 24, 2014
+ by
+
+
+ Bill Fisher
+
+
+
+
+
+
+
+
+
A more up-to-date version of this post is available as part of the Flux documentation.
+
+
Flux is the application architecture that Facebook uses to build web applications with React. It's based on a unidirectional data flow. In previous blog posts and documentation articles, we've shown the basic structure and data flow, more closely examined the dispatcher and action creators, and shown how to put it all together with a tutorial. Now let's look at how to do formal unit testing of Flux applications with Jest, Facebook's auto-mocking testing framework.
+
+
Testing with Jest
+
+
For a unit test to operate on a truly isolated unit of the application, we need to mock every module except the one we are testing. Jest makes the mocking of other parts of a Flux application trivial. To illustrate testing with Jest, we'll return to our example TodoMVC application.
+
+
The first steps toward working with Jest are as follows:
+
+
+
Get the module dependencies for the application installed by running npm install.
+
Create a directory __tests__/ with a test file, in this case TodoStore-test.js
Now you're ready to run your tests from the command line with npm test.
+
+
By default, all modules are mocked, so the only boilerplate we need in TodoStore-test.js is a declarative call to Jest's dontMock() method.
+
jest.dontMock('TodoStore');
+
+
This tells Jest to let TodoStore be a real object with real, live methods. Jest will mock all other objects involved with the test.
+
+
Testing Stores
+
+
At Facebook, Flux stores often receive a great deal of formal unit test coverage, as this is where the application state and logic lives. Stores are arguably the most important place in a Flux application to provide coverage, but at first glance, it's not entirely obvious how to test them.
+
+
By design, stores can't be modified from the outside. They have no setters. The only way new data can enter a store is through the callback it registers with the dispatcher.
+
+
We therefore need to simulate the Flux data flow with this one weird trick.
We now have the store's registered callback, the sole mechanism by which data can enter the store.
+
+
For folks new to Jest, or mocks in general, it might not be entirely obvious what is happening in that code block, so let's look at each part of it a bit more closely. We start out by looking at the register() method of our application's dispatcher — the method that the store uses to register its callback with the dispatcher. The dispatcher has been thoroughly mocked automatically by Jest, so we can get a reference to the mocked version of the register() method just as we would normally refer to that method in our production code. But we can get additional information about that method with the mockproperty of that method. We don't often think of methods having properties, but in Jest, this idea is vital. Every method of a mocked object has this property, and it allows us to examine how the method is being called during the test. A chronologically ordered list of calls to register() is available with the calls property of mock, and each of these calls has a list of the arguments that were used in each method call.
+
+
So in this code, we are really saying, "Give me a reference to the first argument of the first call to MyDispatcher's register() method." That first argument is the store's callback, so now we have all we need to start testing. But first, we can save ourselves some semicolons and roll all of this into a single line:
We can invoke that callback whenever we like, independent of our application's dispatcher or action creators. We will, in fact, fake the behavior of the dispatcher and action creators by invoking the callback with an action that we'll create directly in our test.
The example Flux TodoMVC application has been updated with an example test for the TodoStore, but let's look at an abbreviated version of the entire test. The most important things to notice in this test are how we keep a reference to the store's registered callback in the closure of the test, and how we recreate the store before every test so that we clear the state of the store entirely.
Sometimes our stores rely on data from other stores. Because all of our modules are mocked, we'll need to simulate the data that comes from the other store. We can do this by retrieving the mock function and adding a custom return value to it.
Now we have a collection of objects that will come back from MyOtherStore whenever we call MyOtherStore.getState() in our tests. Any application state can be simulated with a combination of these custom return values and the previously shown technique of working with the store's registered callback.
+
+
A brief example of this technique is up on GitHub within the Flux Chat example's UnreadThreadStore-test.js.
+
+
For more information about the mock property of mocked methods or Jest's ability to provide custom mock values, see Jest's documentation on mock functions.
+
+
Moving Logic from React to Stores
+
+
What often starts as a little piece of seemingly benign logic in our React components often presents a problem while creating unit tests. We want to be able to write tests that read like a specification for our application's behavior, and when application logic slips into our view layer, this becomes more difficult.
+
+
For example, when a user has marked each of their to-do items as complete, the TodoMVC specification dictates that we should also change the status of the "Mark all as complete" checkbox automatically. To create that logic, we might be tempted to write code like this in our MainSection's render() method:
While this seems like an easy, normal thing to do, this is an example of application logic slipping into the views, and it can't be described in our spec-style TodoStore test. Let's take that logic and move it to the store. First, we'll create a public method on the store that will encapsulate that logic:
Flux is the application architecture Facebook uses to build JavaScript applications. It's based on a unidirectional data flow. We've built everything from small widgets to huge applications with Flux, and it's handled everything we've thrown at it. Because we've found it to be a great way to structure our code, we're excited to share it with the open source community. Jing Chen presented Flux at the F8 conference, and since that time we've seen a lot of interest in it. We've also published an overview of Flux and a TodoMVC example, with an accompanying tutorial.
-
-
Flux is more of a pattern than a full-blown framework, and you can start using it without a lot of new code beyond React. Up until recently, however, we haven't released one crucial piece of our Flux software: the dispatcher. But along with the creation of the new Flux code repository and Flux website, we've now open sourced the same dispatcher we use in our production applications.
-
-
Where the Dispatcher Fits in the Flux Data Flow
-
-
The dispatcher is a singleton, and operates as the central hub of data flow in a Flux application. It is essentially a registry of callbacks, and can invoke these callbacks in order. Each store registers a callback with the dispatcher. When new data comes into the dispatcher, it then uses these callbacks to propagate that data to all of the stores. The process of invoking the callbacks is initiated through the dispatch() method, which takes a data payload object as its sole argument.
-
-
Actions and ActionCreators
-
-
When new data enters the system, whether through a person interacting with the application or through a web api call, that data is packaged into an action — an object literal containing the new fields of data and a specific action type. We often create a library of helper methods called ActionCreators that not only create the action object, but also pass the action to the dispatcher.
-
-
Different actions are identified by a type attribute. When all of the stores receive the action, they typically use this attribute to determine if and how they should respond to it. In a Flux application, both stores and views control themselves; they are not acted upon by external objects. Actions flow into the stores through the callbacks they define and register, not through setter methods.
-
-
Letting the stores update themselves eliminates many entanglements typically found in MVC applications, where cascading updates between models can lead to unstable state and make accurate testing very difficult. The objects within a Flux application are highly decoupled, and adhere very strongly to the Law of Demeter, the principle that each object within a system should know as little as possible about the other objects in the system. This results in software that is more maintainable, adaptable, testable, and easier for new engineering team members to understand.
-
-
-
-
Why We Need a Dispatcher
-
-
As an application grows, dependencies across different stores are a near certainty. Store A will inevitably need Store B to update itself first, so that Store A can know how to update itself. We need the dispatcher to be able to invoke the callback for Store B, and finish that callback, before moving forward with Store A. To declaratively assert this dependency, a store needs to be able to say to the dispatcher, "I need to wait for Store B to finish processing this action." The dispatcher provides this functionality through its waitFor() method.
-
-
The dispatch() method provides a simple, synchronous iteration through the callbacks, invoking each in turn. When waitFor() is encountered within one of the callbacks, execution of that callback stops and waitFor() provides us with a new iteration cycle over the dependencies. After the entire set of dependencies have been fulfilled, the original callback then continues to execute.
-
-
Further, the waitFor() method may be used in different ways for different actions, within the same store's callback. In one case, Store A might need to wait for Store B. But in another case, it might need to wait for Store C. Using waitFor() within the code block that is specific to an action allows us to have fine-grained control of these dependencies.
-
-
Problems arise, however, if we have circular dependencies. That is, if Store A needs to wait for Store B, and Store B needs to wait for Store A, we could wind up in an endless loop. The dispatcher now available in the Flux repo protects against this by throwing an informative error to alert the developer that this problem has occurred. The developer can then create a third store and resolve the circular dependency.
-
-
Example Chat App
-
-
Along with the same dispatcher that Facebook uses in its production applications, we've also published a new example chat app, slightly more complicated than the simplistic TodoMVC, so that engineers can better understand how Flux solves problems like dependencies between stores and calls to a web API.
-
-
We're hopeful that the new Flux repository will grow with time to include additional tools, boilerplate code and further examples. And we hope that Flux will prove as useful to you as it has to us. Enjoy!
Flux is the application architecture Facebook uses to build JavaScript applications. It's based on a unidirectional data flow. We've built everything from small widgets to huge applications with Flux, and it's handled everything we've thrown at it. Because we've found it to be a great way to structure our code, we're excited to share it with the open source community. Jing Chen presented Flux at the F8 conference, and since that time we've seen a lot of interest in it. We've also published an overview of Flux and a TodoMVC example, with an accompanying tutorial.
+
+
Flux is more of a pattern than a full-blown framework, and you can start using it without a lot of new code beyond React. Up until recently, however, we haven't released one crucial piece of our Flux software: the dispatcher. But along with the creation of the new Flux code repository and Flux website, we've now open sourced the same dispatcher we use in our production applications.
+
+
Where the Dispatcher Fits in the Flux Data Flow
+
+
The dispatcher is a singleton, and operates as the central hub of data flow in a Flux application. It is essentially a registry of callbacks, and can invoke these callbacks in order. Each store registers a callback with the dispatcher. When new data comes into the dispatcher, it then uses these callbacks to propagate that data to all of the stores. The process of invoking the callbacks is initiated through the dispatch() method, which takes a data payload object as its sole argument.
+
+
Actions and ActionCreators
+
+
When new data enters the system, whether through a person interacting with the application or through a web api call, that data is packaged into an action — an object literal containing the new fields of data and a specific action type. We often create a library of helper methods called ActionCreators that not only create the action object, but also pass the action to the dispatcher.
+
+
Different actions are identified by a type attribute. When all of the stores receive the action, they typically use this attribute to determine if and how they should respond to it. In a Flux application, both stores and views control themselves; they are not acted upon by external objects. Actions flow into the stores through the callbacks they define and register, not through setter methods.
+
+
Letting the stores update themselves eliminates many entanglements typically found in MVC applications, where cascading updates between models can lead to unstable state and make accurate testing very difficult. The objects within a Flux application are highly decoupled, and adhere very strongly to the Law of Demeter, the principle that each object within a system should know as little as possible about the other objects in the system. This results in software that is more maintainable, adaptable, testable, and easier for new engineering team members to understand.
+
+
+
+
Why We Need a Dispatcher
+
+
As an application grows, dependencies across different stores are a near certainty. Store A will inevitably need Store B to update itself first, so that Store A can know how to update itself. We need the dispatcher to be able to invoke the callback for Store B, and finish that callback, before moving forward with Store A. To declaratively assert this dependency, a store needs to be able to say to the dispatcher, "I need to wait for Store B to finish processing this action." The dispatcher provides this functionality through its waitFor() method.
+
+
The dispatch() method provides a simple, synchronous iteration through the callbacks, invoking each in turn. When waitFor() is encountered within one of the callbacks, execution of that callback stops and waitFor() provides us with a new iteration cycle over the dependencies. After the entire set of dependencies have been fulfilled, the original callback then continues to execute.
+
+
Further, the waitFor() method may be used in different ways for different actions, within the same store's callback. In one case, Store A might need to wait for Store B. But in another case, it might need to wait for Store C. Using waitFor() within the code block that is specific to an action allows us to have fine-grained control of these dependencies.
+
+
Problems arise, however, if we have circular dependencies. That is, if Store A needs to wait for Store B, and Store B needs to wait for Store A, we could wind up in an endless loop. The dispatcher now available in the Flux repo protects against this by throwing an informative error to alert the developer that this problem has occurred. The developer can then create a third store and resolve the circular dependency.
+
+
Example Chat App
+
+
Along with the same dispatcher that Facebook uses in its production applications, we've also published a new example chat app, slightly more complicated than the simplistic TodoMVC, so that engineers can better understand how Flux solves problems like dependencies between stores and calls to a web API.
+
+
We're hopeful that the new Flux repository will grow with time to include additional tools, boilerplate code and further examples. And we hope that Flux will prove as useful to you as it has to us. Enjoy!
Ever wanted to find developers who also share the same interest in React than you? Recently, there has been a React Meetup in San Francisco (courtesy of Telmate), and one in London (courtesy of Stuart Harris, Cain Ullah and Zoe Merchant). These two events have been big successes; a second one in London is already planned.
-
-
If you don't live near San Francisco or London, why not start one in your community?
-
-
Complementary Tools
-
-
In case you haven't seen it, we've consolidated the tooling solution around React on this wiki page. Some of the notable recent entries include:
Andrey Popp's react-quickstart, which gives you a quick template for server-side rendering and routing, among other features.
-
-
-
These are some of the links that often pop up on the #reactjs IRC channel. If you made something that you think deserves to be shown on the wiki, feel free to add it!
-
-
React in Interesting Places
-
-
The core concepts React themselves is something very valuable that the community is exploring and pushing further. A year ago, we wouldn't have imagined something like Bruce Hauman's Flappy Bird ClojureScript port, whose interactive programming has been made possible through React:
-
-
-
-
And don't forget Pete Hunt's Wolfenstein 3D rendering engine in React (source code). While it's nearly a year old, it's still a nice demo.
-
-
-
-
Give us a shoutout on IRC or React Google Groups if you've used React in some Interesting places.
-
-
Even More People Using React
-
-
Prismatic
-
-
Prismatic recently shrank their codebase fivefold with the help of React and its popular ClojureScript wrapper, Om. They detailed their very positive experience here.
-
-
-
Finally, the state is normalized: each piece of information is represented in a single place. Since React ensures consistency between the DOM and the application data, the programmer can focus on ensuring that the state properly stays up to date in response to user input. If the application state is normalized, then this consistency is guaranteed by definition, completely avoiding the possibility of an entire class of common bugs.
-
-
-
Adobe Brackets
-
-
Kevin Dangoor works on Brackets, the open-source code editor. After writing his first impression on React, he followed up with another insightful article on how to gradually make the code transition, how to preserve the editor's good parts, and how to tune Brackets' tooling around JSX.
-
-
-
We don’t need to switch to React everywhere, all at once. It’s not a framework that imposes anything on the application structure. [...] Easy, iterative adoption is definitely something in React’s favor for us.
-
-
-
Storehouse
-
-
Storehouse (Apple Design Award 2014)'s web presence is build with React. Here's an example story. Congratulations on the award!
-
-
Vim Awesome
-
-
Vim Awesome, an open-source Vim plugins directory built on React, was just launched. Be sure to check out the source code if you're curious to see an example of how to build a small single-page React app.
-
-
Random Tweets
-
-
Spent 12 hours so far with #reactjs. Spent another 2 wondering why we've been doing JS frameworks wrong until now. React makes me happy.
Ever wanted to find developers who also share the same interest in React than you? Recently, there has been a React Meetup in San Francisco (courtesy of Telmate), and one in London (courtesy of Stuart Harris, Cain Ullah and Zoe Merchant). These two events have been big successes; a second one in London is already planned.
+
+
If you don't live near San Francisco or London, why not start one in your community?
+
+
Complementary Tools
+
+
In case you haven't seen it, we've consolidated the tooling solution around React on this wiki page. Some of the notable recent entries include:
Andrey Popp's react-quickstart, which gives you a quick template for server-side rendering and routing, among other features.
+
+
+
These are some of the links that often pop up on the #reactjs IRC channel. If you made something that you think deserves to be shown on the wiki, feel free to add it!
+
+
React in Interesting Places
+
+
The core concepts React themselves is something very valuable that the community is exploring and pushing further. A year ago, we wouldn't have imagined something like Bruce Hauman's Flappy Bird ClojureScript port, whose interactive programming has been made possible through React:
+
+
+
+
And don't forget Pete Hunt's Wolfenstein 3D rendering engine in React (source code). While it's nearly a year old, it's still a nice demo.
+
+
+
+
Give us a shoutout on IRC or React Google Groups if you've used React in some Interesting places.
+
+
Even More People Using React
+
+
Prismatic
+
+
Prismatic recently shrank their codebase fivefold with the help of React and its popular ClojureScript wrapper, Om. They detailed their very positive experience here.
+
+
+
Finally, the state is normalized: each piece of information is represented in a single place. Since React ensures consistency between the DOM and the application data, the programmer can focus on ensuring that the state properly stays up to date in response to user input. If the application state is normalized, then this consistency is guaranteed by definition, completely avoiding the possibility of an entire class of common bugs.
+
+
+
Adobe Brackets
+
+
Kevin Dangoor works on Brackets, the open-source code editor. After writing his first impression on React, he followed up with another insightful article on how to gradually make the code transition, how to preserve the editor's good parts, and how to tune Brackets' tooling around JSX.
+
+
+
We don’t need to switch to React everywhere, all at once. It’s not a framework that imposes anything on the application structure. [...] Easy, iterative adoption is definitely something in React’s favor for us.
+
+
+
Storehouse
+
+
Storehouse (Apple Design Award 2014)'s web presence is build with React. Here's an example story. Congratulations on the award!
+
+
Vim Awesome
+
+
Vim Awesome, an open-source Vim plugins directory built on React, was just launched. Be sure to check out the source code if you're curious to see an example of how to build a small single-page React app.
+
+
Random Tweets
+
+
Spent 12 hours so far with #reactjs. Spent another 2 wondering why we've been doing JS frameworks wrong until now. React makes me happy.
Hot on the heels of the release candidate earlier this week, we're ready to call v0.10 done. The only major issue we discovered had to do with the react-tools package, which has been updated. We've copied over the changelog from the RC with some small clarifying changes.
-
-
The release is available for download from the CDN:
The main purpose of this release is to provide a smooth upgrade path as we evolve some of the implementation of core. In v0.9 we started warning in cases where you called methods on unmounted components. This is part of an effort to enforce the idea that the return value of a component (React.DOM.div(), MyComponent()) is in fact not a reference to the component instance React uses in the virtual DOM. The return value is instead a light-weight object that React knows how to use. Since the return value currently is a reference to the same object React uses internally, we need to make this transition in stages as many people have come to depend on this implementation detail.
-
-
In 0.10, we’re adding more warnings to catch a similar set of patterns. When a component is mounted we clone it and use that object for our internal representation. This allows us to capture calls you think you’re making to a mounted component. We’ll forward them on to the right object, but also warn you that this is breaking. See “Access to the Mounted Instance” on this page. Most of the time you can solve your pattern by using refs.
-
-
Storing a reference to your top level component is a pattern touched upon on that page, but another examples that demonstrates what we see a lot of:
-
// This is a common pattern. However instance here really refers to a
-// "descriptor", not necessarily the mounted instance.
-varinstance=<MyComponent/>;
-React.renderComponent(instance);
-// ...
-instance.setProps(...);
-
-// The change here is very simple. The return value of renderComponent will be
-// the mounted instance.
-varinstance=React.renderComponent(<MyComponent/>)
-// ...
-instance.setProps(...);
-
-
These warnings and method forwarding are only enabled in the development build. The production builds continue to work as they did in v0.9. We strongly encourage you to use the development builds to catch these warnings and fix the call sites.
-
-
The plan for v0.11 is that we will go fully to "descriptors". Method calls on the return value of MyComponent() will fail hard.
-
-
Changelog
-
-
React Core
-
-
New Features
-
-
-
Added warnings to help migrate towards descriptors
srcSet for <img> to specify images at different pixel ratios
-
textAnchor for SVG
-
-
-
-
Bug Fixes
-
-
-
Ensure all void elements don’t insert a closing tag into the markup.
-
Ensure className={false} behaves consistently
-
Ensure this.refs is defined, even if no refs are specified.
-
-
-
Addons
-
-
-
update function to deal with immutable data. Read the docs
-
-
-
react-tools
-
-
-
Added an option argument to transform function. The only option supported is harmony, which behaves the same as jsx --harmony on the command line. This uses the ES6 transforms from jstransform.
Hot on the heels of the release candidate earlier this week, we're ready to call v0.10 done. The only major issue we discovered had to do with the react-tools package, which has been updated. We've copied over the changelog from the RC with some small clarifying changes.
+
+
The release is available for download from the CDN:
The main purpose of this release is to provide a smooth upgrade path as we evolve some of the implementation of core. In v0.9 we started warning in cases where you called methods on unmounted components. This is part of an effort to enforce the idea that the return value of a component (React.DOM.div(), MyComponent()) is in fact not a reference to the component instance React uses in the virtual DOM. The return value is instead a light-weight object that React knows how to use. Since the return value currently is a reference to the same object React uses internally, we need to make this transition in stages as many people have come to depend on this implementation detail.
+
+
In 0.10, we’re adding more warnings to catch a similar set of patterns. When a component is mounted we clone it and use that object for our internal representation. This allows us to capture calls you think you’re making to a mounted component. We’ll forward them on to the right object, but also warn you that this is breaking. See “Access to the Mounted Instance” on this page. Most of the time you can solve your pattern by using refs.
+
+
Storing a reference to your top level component is a pattern touched upon on that page, but another examples that demonstrates what we see a lot of:
+
// This is a common pattern. However instance here really refers to a
+// "descriptor", not necessarily the mounted instance.
+varinstance=<MyComponent/>;
+React.renderComponent(instance);
+// ...
+instance.setProps(...);
+
+// The change here is very simple. The return value of renderComponent will be
+// the mounted instance.
+varinstance=React.renderComponent(<MyComponent/>)
+// ...
+instance.setProps(...);
+
+
These warnings and method forwarding are only enabled in the development build. The production builds continue to work as they did in v0.9. We strongly encourage you to use the development builds to catch these warnings and fix the call sites.
+
+
The plan for v0.11 is that we will go fully to "descriptors". Method calls on the return value of MyComponent() will fail hard.
+
+
Changelog
+
+
React Core
+
+
New Features
+
+
+
Added warnings to help migrate towards descriptors
srcSet for <img> to specify images at different pixel ratios
+
textAnchor for SVG
+
+
+
+
Bug Fixes
+
+
+
Ensure all void elements don’t insert a closing tag into the markup.
+
Ensure className={false} behaves consistently
+
Ensure this.refs is defined, even if no refs are specified.
+
+
+
Addons
+
+
+
update function to deal with immutable data. Read the docs
+
+
+
react-tools
+
+
+
Added an option argument to transform function. The only option supported is harmony, which behaves the same as jsx --harmony on the command line. This uses the ES6 transforms from jstransform.
We're almost ready to release React v0.9! We're posting a release candidate so that you can test your apps on it; we'd much prefer to find show-stopping bugs now rather than after we release.
-
-
The release candidate is available for download from the CDN:
In addition to the changes to React core listed below, we've made a small change to the way JSX interprets whitespace to make things more consistent. With this release, space between two components on the same line will be preserved, while a newline separating a text node from a tag will be eliminated in the output. Consider the code:
We believe this new behavior is more helpful and eliminates cases where unwanted whitespace was previously added.
-
-
In cases where you want to preserve the space adjacent to a newline, you can write a JS string like {"Monkeys: "} in your JSX source. We've included a script to do an automated codemod of your JSX source tree that preserves the old whitespace behavior by adding and removing spaces appropriately. You can install jsx_whitespace_transformer from npm and run it over your source tree to modify files in place. The transformed JSX files will preserve your code's existing whitespace behavior.
-
-
Changelog
-
-
React Core
-
-
Breaking Changes
-
-
-
The lifecycle methods componentDidMount and componentDidUpdate no longer receive the root node as a parameter; use this.getDOMNode() instead
-
Whenever a prop is equal to undefined, the default value returned by getDefaultProps will now be used instead
-
React.unmountAndReleaseReactRootNode was previously deprecated and has now been removed
-
React.renderComponentToString is now synchronous and returns the generated HTML string
-
Full-page rendering (that is, rendering the <html> tag using React) is now supported only when starting with server-rendered markup
-
On mouse wheel events, deltaY is no longer negated
-
When prop types validation fails, a warning is logged instead of an error thrown (with the production build of React, the type checks are now skipped for performance)
-
On input, select, and textarea elements, .getValue() is no longer supported; use .getDOMNode().value instead
-
this.context on components is now reserved for internal use by React
-
-
-
New Features
-
-
-
React now never rethrows errors, so stack traces are more accurate and Chrome's purple break-on-error stop sign now works properly
-
Added a new tool for profiling React components and identifying places where defining shouldComponentUpdate can give performance improvements
-
Added support for SVG tags defs, linearGradient, polygon, radialGradient, stop
-
Added support for more attributes:
-
-
-
noValidate and formNoValidate for forms
-
property for Open Graph <meta> tags
-
sandbox, seamless, and srcDoc for <iframe> tags
-
scope for screen readers
-
span for <colgroup> tags
-
-
Added support for defining propTypes in mixins
-
Added any, arrayOf, component, oneOfType, renderable, shape to React.PropTypes
-
Added support for statics on component spec for static component methods
-
On all events, .currentTarget is now properly set
-
On keyboard events, .key is now polyfilled in all browsers for special (non-printable) keys
-
On clipboard events, .clipboardData is now polyfilled in IE
-
On drag events, .dataTransfer is now present
-
Added support for onMouseOver and onMouseOut in addition to the existing onMouseEnter and onMouseLeave events
-
Added support for onLoad and onError on <img> elements
-
Added support for onReset on <form> elements
-
The autoFocus attribute is now polyfilled consistently on input, select, and textarea
-
-
-
Bug Fixes
-
-
-
React no longer adds an __owner__ property to each component's props object; passed-in props are now never mutated
-
When nesting top-level components (e.g., calling React.renderComponent within componentDidMount), events now properly bubble to the parent component
-
Fixed a case where nesting top-level components would throw an error when updating
-
Passing an invalid or misspelled propTypes type now throws an error
-
On mouse enter/leave events, .target, .relatedTarget, and .type are now set properly
-
On composition events, .data is now properly normalized in IE9 and IE10
-
CSS property values no longer have px appended for the unitless properties columnCount, flex, flexGrow, flexShrink, lineClamp, order, widows
-
Fixed a memory leak when unmounting children with a componentWillUnmount handler
-
Fixed a memory leak when renderComponentToString would store event handlers
-
Fixed an error that could be thrown when removing form elements during a click handler
-
key values containing . are now supported
-
Shortened data-reactid values for performance
-
Components now always remount when the key property changes
-
Event handlers are attached to document only when necessary, improving performance in some cases
-
Events no longer use .returnValue in modern browsers, eliminating a warning in Chrome
-
scrollLeft and scrollTop are no longer accessed on document.body, eliminating a warning in Chrome
-
General performance fixes, memory optimizations, improvements to warnings and error messages
-
-
-
React with Addons
-
-
-
React.addons.TransitionGroup was renamed to React.addons.CSSTransitionGroup
-
React.addons.TransitionGroup was added as a more general animation wrapper
-
React.addons.cloneWithProps was added for cloning components and modifying their props
-
Bug fix for adding back nodes during an exit transition for CSSTransitionGroup
-
Bug fix for changing transitionLeave in CSSTransitionGroup
-
Performance optimizations for CSSTransitionGroup
-
On checkbox <input> elements, checkedLink is now supported for two-way binding
-
-
-
JSX Compiler and react-tools Package
-
-
-
Whitespace normalization has changed; now space between two tags on the same line will be preserved, while newlines between two tags will be removed
-
The react-tools npm package no longer includes the React core libraries; use the react package instead.
-
displayName is now added in more cases, improving error messages and names in the React Dev Tools
-
Fixed an issue where an invalid token error was thrown after a JSX closing tag
-
JSXTransformer now uses source maps automatically in modern browsers
-
JSXTransformer error messages now include the filename and problematic line contents when a file fails to parse
+ February 16, 2014
+ by
+
+
+ Sophie Alpert
+
+
+
+
+
+
+
+
+
We're almost ready to release React v0.9! We're posting a release candidate so that you can test your apps on it; we'd much prefer to find show-stopping bugs now rather than after we release.
+
+
The release candidate is available for download from the CDN:
In addition to the changes to React core listed below, we've made a small change to the way JSX interprets whitespace to make things more consistent. With this release, space between two components on the same line will be preserved, while a newline separating a text node from a tag will be eliminated in the output. Consider the code:
We believe this new behavior is more helpful and eliminates cases where unwanted whitespace was previously added.
+
+
In cases where you want to preserve the space adjacent to a newline, you can write a JS string like {"Monkeys: "} in your JSX source. We've included a script to do an automated codemod of your JSX source tree that preserves the old whitespace behavior by adding and removing spaces appropriately. You can install jsx_whitespace_transformer from npm and run it over your source tree to modify files in place. The transformed JSX files will preserve your code's existing whitespace behavior.
+
+
Changelog
+
+
React Core
+
+
Breaking Changes
+
+
+
The lifecycle methods componentDidMount and componentDidUpdate no longer receive the root node as a parameter; use this.getDOMNode() instead
+
Whenever a prop is equal to undefined, the default value returned by getDefaultProps will now be used instead
+
React.unmountAndReleaseReactRootNode was previously deprecated and has now been removed
+
React.renderComponentToString is now synchronous and returns the generated HTML string
+
Full-page rendering (that is, rendering the <html> tag using React) is now supported only when starting with server-rendered markup
+
On mouse wheel events, deltaY is no longer negated
+
When prop types validation fails, a warning is logged instead of an error thrown (with the production build of React, the type checks are now skipped for performance)
+
On input, select, and textarea elements, .getValue() is no longer supported; use .getDOMNode().value instead
+
this.context on components is now reserved for internal use by React
+
+
+
New Features
+
+
+
React now never rethrows errors, so stack traces are more accurate and Chrome's purple break-on-error stop sign now works properly
+
Added a new tool for profiling React components and identifying places where defining shouldComponentUpdate can give performance improvements
+
Added support for SVG tags defs, linearGradient, polygon, radialGradient, stop
+
Added support for more attributes:
+
+
+
noValidate and formNoValidate for forms
+
property for Open Graph <meta> tags
+
sandbox, seamless, and srcDoc for <iframe> tags
+
scope for screen readers
+
span for <colgroup> tags
+
+
Added support for defining propTypes in mixins
+
Added any, arrayOf, component, oneOfType, renderable, shape to React.PropTypes
+
Added support for statics on component spec for static component methods
+
On all events, .currentTarget is now properly set
+
On keyboard events, .key is now polyfilled in all browsers for special (non-printable) keys
+
On clipboard events, .clipboardData is now polyfilled in IE
+
On drag events, .dataTransfer is now present
+
Added support for onMouseOver and onMouseOut in addition to the existing onMouseEnter and onMouseLeave events
+
Added support for onLoad and onError on <img> elements
+
Added support for onReset on <form> elements
+
The autoFocus attribute is now polyfilled consistently on input, select, and textarea
+
+
+
Bug Fixes
+
+
+
React no longer adds an __owner__ property to each component's props object; passed-in props are now never mutated
+
When nesting top-level components (e.g., calling React.renderComponent within componentDidMount), events now properly bubble to the parent component
+
Fixed a case where nesting top-level components would throw an error when updating
+
Passing an invalid or misspelled propTypes type now throws an error
+
On mouse enter/leave events, .target, .relatedTarget, and .type are now set properly
+
On composition events, .data is now properly normalized in IE9 and IE10
+
CSS property values no longer have px appended for the unitless properties columnCount, flex, flexGrow, flexShrink, lineClamp, order, widows
+
Fixed a memory leak when unmounting children with a componentWillUnmount handler
+
Fixed a memory leak when renderComponentToString would store event handlers
+
Fixed an error that could be thrown when removing form elements during a click handler
+
key values containing . are now supported
+
Shortened data-reactid values for performance
+
Components now always remount when the key property changes
+
Event handlers are attached to document only when necessary, improving performance in some cases
+
Events no longer use .returnValue in modern browsers, eliminating a warning in Chrome
+
scrollLeft and scrollTop are no longer accessed on document.body, eliminating a warning in Chrome
+
General performance fixes, memory optimizations, improvements to warnings and error messages
+
+
+
React with Addons
+
+
+
React.addons.TransitionGroup was renamed to React.addons.CSSTransitionGroup
+
React.addons.TransitionGroup was added as a more general animation wrapper
+
React.addons.cloneWithProps was added for cloning components and modifying their props
+
Bug fix for adding back nodes during an exit transition for CSSTransitionGroup
+
Bug fix for changing transitionLeave in CSSTransitionGroup
+
Performance optimizations for CSSTransitionGroup
+
On checkbox <input> elements, checkedLink is now supported for two-way binding
+
+
+
JSX Compiler and react-tools Package
+
+
+
Whitespace normalization has changed; now space between two tags on the same line will be preserved, while newlines between two tags will be removed
+
The react-tools npm package no longer includes the React core libraries; use the react package instead.
+
displayName is now added in more cases, improving error messages and names in the React Dev Tools
+
Fixed an issue where an invalid token error was thrown after a JSX closing tag
+
JSXTransformer now uses source maps automatically in modern browsers
+
JSXTransformer error messages now include the filename and problematic line contents when a file fails to parse
Happy holidays! This blog post is a little-late Christmas present for all the React users. Hopefully it will inspire you to write awesome web apps in 2014!
-
-
React Touch
-
-
Pete Hunt wrote three demos showing that React can be used to run 60fps native-like experiences on mobile web. A frosted glass effect, an image gallery with 3d animations and an infinite scroll view.
Stoyan Stefanov talked at Joe Dev On Tech about React. He goes over all the features of the library and ends with a concrete example.
-
-
-
-
JSX: E4X The Good Parts
-
-
JSX is often compared to the now defunct E4X, Vjeux went over all the E4X features and explained how JSX is different and hopefully doesn't repeat the same mistakes.
-
-
-
E4X (ECMAScript for XML) is a JavaScript syntax extension and a runtime to manipulate XML. It was promoted by Mozilla but failed to become mainstream and is now deprecated. JSX was inspired by E4X. In this article, I'm going to go over all the features of E4X and explain the design decisions behind JSX.
-
-
Historical Context
-
-
E4X has been created in 2002 by John Schneider. This was the golden age of XML where it was being used for everything: data, configuration files, code, interfaces (DOM) ... E4X was first implemented inside of Rhino, a JavaScript implementation from Mozilla written in Java.
Geert Pasteels made a small experiment with Socket.io. He wrote a very small mixin that synchronizes React state with the server. Just include this mixin to your React component and it is now live!
David Chang working at HasOffer wanted to speed up his Angular app and replaced Angular primitives by React at different layers. When using React naively it is 67% faster, but when combining it with angular's transclusion it is 450% slower.
-
-
-
Rendering this takes 803ms for 10 iterations, hovering around 35 and 55ms for each data reload (that's 67% faster). You'll notice that the first load takes a little longer than successive loads, and the second load REALLY struggles - here, it's 433ms, which is more than half of the total time!
-
Max Wang made a vim syntax highlighting and indentation plugin for vim.
-
-
-
Syntax highlighting and indenting for JSX. JSX is a JavaScript syntax transformer which translates inline XML document fragments into JavaScript objects. It was developed by Facebook alongside React.
-
-
This bundle requires pangloss's vim-javascript syntax highlighting.
-
-
Vim support for inline XML in JS is remarkably similar to the same for PHP.
Happy holidays! This blog post is a little-late Christmas present for all the React users. Hopefully it will inspire you to write awesome web apps in 2014!
+
+
React Touch
+
+
Pete Hunt wrote three demos showing that React can be used to run 60fps native-like experiences on mobile web. A frosted glass effect, an image gallery with 3d animations and an infinite scroll view.
Stoyan Stefanov talked at Joe Dev On Tech about React. He goes over all the features of the library and ends with a concrete example.
+
+
+
+
JSX: E4X The Good Parts
+
+
JSX is often compared to the now defunct E4X, Vjeux went over all the E4X features and explained how JSX is different and hopefully doesn't repeat the same mistakes.
+
+
+
E4X (ECMAScript for XML) is a JavaScript syntax extension and a runtime to manipulate XML. It was promoted by Mozilla but failed to become mainstream and is now deprecated. JSX was inspired by E4X. In this article, I'm going to go over all the features of E4X and explain the design decisions behind JSX.
+
+
Historical Context
+
+
E4X has been created in 2002 by John Schneider. This was the golden age of XML where it was being used for everything: data, configuration files, code, interfaces (DOM) ... E4X was first implemented inside of Rhino, a JavaScript implementation from Mozilla written in Java.
Geert Pasteels made a small experiment with Socket.io. He wrote a very small mixin that synchronizes React state with the server. Just include this mixin to your React component and it is now live!
David Chang working at HasOffer wanted to speed up his Angular app and replaced Angular primitives by React at different layers. When using React naively it is 67% faster, but when combining it with angular's transclusion it is 450% slower.
+
+
+
Rendering this takes 803ms for 10 iterations, hovering around 35 and 55ms for each data reload (that's 67% faster). You'll notice that the first load takes a little longer than successive loads, and the second load REALLY struggles - here, it's 433ms, which is more than half of the total time!
+
Max Wang made a vim syntax highlighting and indentation plugin for vim.
+
+
+
Syntax highlighting and indenting for JSX. JSX is a JavaScript syntax transformer which translates inline XML document fragments into JavaScript objects. It was developed by Facebook alongside React.
+
+
This bundle requires pangloss's vim-javascript syntax highlighting.
+
+
Vim support for inline XML in JS is remarkably similar to the same for PHP.
This is the 10th round-up already and React has come quite far since it was open sourced. Almost all new web projects at Khan Academy, Facebook, and Instagram are being developed using React. React has been deployed in a variety of contexts: a Chrome extension, a Windows 8 application, mobile websites, and desktop websites supporting Internet Explorer 8! Language-wise, React is not only being used within JavaScript but also CoffeeScript and ClojureScript.
-
-
The best part is that no drastic changes have been required to support all those use cases. Most of the efforts were targeted at polishing edge cases, performance improvements, and documentation.
-
-
Khan Academy - Officially moving to React
-
-
Joel Burget announced at Hack Reactor that new front-end code at Khan Academy should be written in React!
-
-
-
How did we get the rest of the team to adopt React? Using interns as an attack vector! Most full-time devs had already been working on their existing projects for a while and weren't looking to try something new at the time, but our class of summer interns was just arriving. For whatever reason, a lot of them decided to try React for their projects. Then mentors became exposed through code reviews or otherwise touching the new code. In this way React knowledge diffused to almost the whole team over the summer.
-
-
Since the first React checkin on June 5, we've somehow managed to accumulate 23500 lines of jsx (React-flavored js) code. Which is terrifying in a way - that's a lot of code - but also really exciting that it was picked up so quickly.
-
-
We held three meetings about how we should proceed with React. At the first two we decided to continue experimenting with React and deferred a final decision on whether to adopt it. At the third we adopted the policy that new code should be written in React.
-
-
I'm excited that we were able to start nudging code quality forward. However, we still have a lot of work to do! One of the selling points of this transition is adopting a uniform frontend style. We're trying to upgrade all the code from (really old) pure jQuery and (regular old) Backbone views / Handlebars to shiny React. At the moment all we've done is introduce more fragmentation. We won't be gratuitously updating working code (if it ain't broke, don't fix it), but are seeking out parts of the codebase where we can shoot two birds with one stone by rewriting in React while fixing bugs or adding functionality.
Webkit has a TodoMVC Benchmark that compares different frameworks. They recently included React and here are the results (average of 10 runs in Chrome 30):
Please don't take those numbers too seriously, they only reflect one very specific use case and are testing code that wasn't written with performance in mind.
-
-
Even though React scores as one of the fastest frameworks in the benchmark, the React code is simple and idiomatic. The only performance tweak used is the following function:
-
/**
- * This is a completely optional performance enhancement that you can implement
- * on any React component. If you were to delete this method the app would still
- * work correctly (and still be very performant!), we just use it as an example
- * of how little code it takes to get an order of magnitude performance improvement.
- */
-shouldComponentUpdate:function(nextProps,nextState){
- return(
- nextProps.todo.id!==this.props.todo.id||
- nextProps.todo!==this.props.todo||
- nextProps.editing!==this.props.editing||
- nextState.editText!==this.state.editText
- );
-},
-
-
By default, React "re-renders" all the components when anything changes. This is usually fast enough that you don't need to care. However, you can provide a function that can tell whether there will be any change based on the previous and next states and props. If it is faster than re-rendering the component, then you get a performance improvement.
-
-
The fact that you can control when components are rendered is a very important characteristic of React as it gives you control over its performance. We are going to talk more about performance in the future, stay tuned.
-
-
Guess the filter
-
-
Connor McSheffrey implemented a small game using React. The goal is to guess which filter has been used to create the Instagram photo.
-
Eerily similar, no? Maybe Facebook was inspired by Fruit Machine (after all, we got there first), but more likely, it just shows that this is a pretty decent way to solve the problem, and great minds think alike. We're graduating to a third phase in the evolution of web best practice - from intermingling of markup, style and behaviour, through a phase in which those concerns became ever more separated and encapsulated, and finally to a model where we can do that separation at a component level. Developments like Web Components show the direction the web community is moving, and frameworks like React and Fruit Machine are in fact not a lot more than polyfills for that promised behaviour to come.
Even though we weren't inspired by FruitMachine (React has been used in production since before FruitMachine was open sourced), it's great to see similar technologies emerging and becoming popular.
Less than a year ago, we introduced Create React App as an officially supported way to create apps with zero configuration. The project has since enjoyed tremendous growth, with over 950 commits by more than 250 contributors.
+
+
Today, we are excited to announce that many features that have been in the pipeline for the last few months are finally released.
+
+
As usual with Create React App, you can enjoy these improvements in your existing non-ejected apps by updating a single dependency and following our migration instructions.
+
+
Newly created apps will get these improvements automatically.
We have upgraded to webpack 2 which has been officially released a few months ago. It is a big upgrade with many bugfixes and general improvements. We have been testing it for a while, and now consider it stable enough to recommend it to everyone.
+
+
While the Webpack configuration format has changed, Create React App users who didn't eject don't need to worry about it as we have updated the configuration on our side.
+
+
If you had to eject your app for one reason or another, Webpack provides a configuration migration guide that you can follow to update your apps. Note that with each release of Create React App, we are working to support more use cases out of the box so that you don't have to eject in the future.
+
+
The biggest notable webpack 2 feature is the ability to write and import ES6 modules directly without compiling them to CommonJS. This shouldn’t affect how you write code since you likely already use import and export statements, but it will help catch more mistakes like missing named exports at compile time:
+
+
+
+
In the future, as the ecosystem around ES6 modules matures, you can expect more improvements to your app's bundle size thanks to tree shaking.
Have you ever made a mistake in code and only realized it after the console is flooded with cryptic errors? Or worse, have you ever shipped an app with crashes in production because you accidentally missed an error in development?
+
+
To address these issues, we are introducing an overlay that pops up whenever there is an uncaught error in your application. It only appears in development, and you can dismiss it by pressing Escape.
+
+
A GIF is worth a thousand words:
+
+
+
+
(Yes, it integrates with your editor!)
+
+
In the future, we plan to teach the runtime error overlay to understand more about your React app. For example, after React 16 we plan to show React component stacks in addition to the JavaScript stacks when an error is thrown.
Newly created projects are built as Progressive Web Apps by default. This means that they employ service workers with an offline-first caching strategy to minimize the time it takes to serve the app to the users who visit it again. You can opt out of this behavior, but we recommend it both for new and existing apps, especially if you target mobile devices.
+
+
+
+
New apps automatically have these features, but you can easily convert an existing project to a Progressive Web App by following our migration guide.
We are now using the latest version of Jest that includes numerous bugfixes and improvements. You can read more about the changes in Jest 19 and Jest 20 blog posts.
It is important to keep the initial JavaScript payload of web apps down to the minimum, and load the rest of the code on demand. Although Create React App supported code splitting using require.ensure() since the first release, it used a webpack-specific syntax that did not work in Jest or other environments.
+
+
In this release, we are adding support for the dynamic import() proposal which aligns with the future web standards. Unlike require.ensure(), it doesn't break Jest tests, and should eventually become a part of JavaScript. We encourage you to use import() to delay loading the code for non-critical component subtrees until you need to render them.
We have improved the console output across the board.
+
+
For example, when you start the development server, we now display the LAN address in additional to the localhost address so that you can quickly access the app from a mobile device on the same network:
+
+
+
+
When lint errors are reported, we no longer show the warnings so that you can concentrate on more critical issues. Errors and warnings in the production build output are better formatted, and the build error overlay font size now matches the browser font size more closely.
You can read the full changelog and the migration guide in the v1.0.0 release notes.
+
+
Acknowledgements
+
+
This release is a result of months of work from many people in the React community. It is focused on improving both developer and end user experience, as we believe they are complementary and go hand in hand.
+
+
We are grateful to everyone who has offered their contributions, whether in code, documentation, or by helping other people. We would like to specifically thank Joe Haddad for his invaluable help maintaining the project.
+
+
We are excited to bring these improvements to everybody using Create React App, and we are looking forward to more of your feedback and contributions.
+
+
+
+
+
+
+
+
+
+
React v15.5.0
@@ -843,7 +985,7 @@ I think we should just treat arrays of elements as a frag. This is useful for co
In March we added support for server-side rendering and for creating multiple instances of Relay on a single page. This was a coordinated effort over the course of several months by community members Denis Nedelyaev and Gerald Monaco (now at Facebook).
-
Also in March we added support for React Native. While we use Relay and React Native together internally, they didn't quite work together in open-source out of the box. We owe a big thanks to Adam Miskiewicz, Tom Burns, Gaëtan Renaudeau, David Aurelio, Martín Bigio, Paul O’Shannessy, Ben Alpert, and many others who helped track down and resolve issues. Finally, thanks to Steven Luscher for coordinating this effort and building the first Relay/ReactNative example app.
+
Also in March we added support for React Native. While we use Relay and React Native together internally, they didn't quite work together in open-source out of the box. We owe a big thanks to Adam Miskiewicz, Tom Burns, Gaëtan Renaudeau, David Aurelio, Martín Bigio, Paul O’Shannessy, Sophie Alpert, and many others who helped track down and resolve issues. Finally, thanks to Steven Luscher for coordinating this effort and building the first Relay/ReactNative example app.
We've also seen some great open-source projects spring up around Relay:
@@ -916,189 +1058,6 @@ I think we should just treat arrays of elements as a frag. This is useful for co
-
Create React App is a new officially supported way to create single-page React applications. It offers a modern build setup with no configuration.
-
-
Getting Started
-
-
Installation
-
-
First, install the global package:
-
npm install -g create-react-app
-
-
Node.js 4.x or higher is required.
-
-
Creating an App
-
-
Now you can use it to create a new app:
-
create-react-app hello-world
-
-
This will take a while as npm installs the transitive dependencies, but once it’s done, you will see a list of commands you can run in the created folder:
-
-
-
-
Starting the Server
-
-
Run npm start to launch the development server. The browser will open automatically with the created app’s URL.
-
-
-
-
Create React App uses both webpack and Babel under the hood.
-The console output is tuned to be minimal to help you focus on the problems:
-
-
-
-
ESLint is also integrated so lint warnings are displayed right in the console:
-
-
-
-
We only picked a small subset of lint rules that often lead to bugs.
-
-
Building for Production
-
-
To build an optimized bundle, run npm run build:
-
-
-
-
It is minified, correctly envified, and the assets include content hashes for caching.
-
-
One Dependency
-
-
Your package.json contains only a single build dependency and a few scripts:
We take care of updating Babel, ESLint, and webpack to stable compatible versions so you can update a single dependency to get them all.
-
-
Zero Configuration
-
-
It is worth repeating: there are no configuration files or complicated folder structures. The tool only generates the files you need to build your app.
All the build settings are preconfigured and can’t be changed. Some features, such as testing, are currently missing. This is an intentional limitation, and we recognize it might not work for everybody. And this brings us to the last point.
-
-
No Lock-In
-
-
We first saw this feature in Enclave, and we loved it. We talked to Ean, and he was excited to collaborate with us. He already sent a few pull requests!
-
-
“Ejecting” lets you leave the comfort of Create React App setup at any time. You run a single command, and all the build dependencies, configs, and scripts are moved right into your project. At this point you can customize everything you want, but effectively you are forking our configuration and going your own way. If you’re experienced with build tooling and prefer to fine-tune everything to your taste, this lets you use Create React App as a boilerplate generator.
-
-
We expect that at early stages, many people will “eject” for one reason or another, but as we learn from them, we will make the default setup more and more compelling while still providing no configuration.
-
-
Try It Out!
-
-
You can find Create React App with additional instructions on GitHub.
-
-
This is an experiment, and only time will tell if it becomes a popular way of creating and building React apps, or fades into obscurity.
-
-
We welcome you to participate in this experiment. Help us build the React tooling that more people can use. We are always open to feedback.
-
-
The Backstory
-
-
React was one of the first libraries to embrace transpiling JavaScript. As a result, even though you can learn React without any tooling, the React ecosystem has commonly become associated with an overwhelming explosion of tools.
Ultimately, the problem is that by choosing React (and inherently JSX), you’ve unwittingly opted into a confusing nest of build tools, boilerplate, linters, & time-sinks to deal with before you ever get to create anything.
-
-
-
It is tempting to write code in ES2015 and JSX. It is sensible to use a bundler to keep the codebase modular, and a linter to catch the common mistakes. It is nice to have a development server with fast rebuilds, and a command to produce optimized bundles for production.
-
-
Combining these tools requires some experience with each of them. Even so, it is far too easy to get dragged into fighting small incompatibilities, unsatisfied peerDependencies, and illegible configuration files.
-
-
Many of those tools are plugin platforms and don’t directly acknowledge each other’s existence. They leave it up to the users to wire them together. The tools mature and change independently, and tutorials quickly get out of date.
This doesn’t mean those tools aren’t great. To many of us, they have become indispensable, and we very much appreciate the effort of their maintainers. They already have too much on their plates to worry about the state of the React ecosystem.
-
-
Still, we knew it was frustrating to spend days setting up a project when all you wanted was to learn React. We wanted to fix this.
-
-
Could We Fix This?
-
-
We found ourselves in an unusual dilemma.
-
-
So far, our strategy has been to only release the code that we are using at Facebook. This helped us ensure that every project is battle-tested and has clearly defined scope and priorities.
-
-
However, tooling at Facebook is different than at many smaller companies. Linting, transpilation, and packaging are all handled by powerful remote development servers, and product engineers don’t need to configure them. While we wish we could give a dedicated server to every user of React, even Facebook cannot scale that well!
-
-
The React community is very important to us. We knew that we couldn’t fix the problem within the limits of our open source philosophy. This is why we decided to make an exception, and to ship something that we didn’t use ourselves, but that we thought would be useful to the community.
-
-
The Quest for a React CLI
-
-
Having just attended EmberCamp a week ago, I was excited about Ember CLI. Ember users have a great “getting started” experience thanks to a curated set of tools united under a single command-line interface. I have heard similar feedback about Elm Reactor.
-
-
Providing a cohesive curated experience is valuable by itself, even if the user could in theory assemble those parts themselves. Kathy Sierra explains it best:
-
-
-
If your UX asks the user to make choices, for example, even if those choices are both clear and useful, the act of deciding is a cognitive drain. And not just while they’re deciding... even after we choose, an unconscious cognitive background thread is slowly consuming/leaking resources, “Was that the right choice?”
-
-
-
I never tried to write a command-line tool for React apps, and neither has Christopher. We were chatting on Messenger about this idea, and we decided to work together on it for a week as a hackathon project.
-
-
We knew that such projects traditionally haven’t been very successful in the React ecosystem. Christopher told me that multiple “React CLI” projects have started and failed at Facebook. The community tools with similar goals also exist, but so far they have not yet gained enough traction.
-
-
Still, we decided it was worth another shot. Christopher and I created a very rough proof of concept on the weekend, and Kevin soon joined us.
-
-
We invited some of the community members to collaborate with us, and we have spent this week working on this tool. We hope that you’ll enjoy using it! Let us know what you think.
This is the 10th round-up already and React has come quite far since it was open sourced. Almost all new web projects at Khan Academy, Facebook, and Instagram are being developed using React. React has been deployed in a variety of contexts: a Chrome extension, a Windows 8 application, mobile websites, and desktop websites supporting Internet Explorer 8! Language-wise, React is not only being used within JavaScript but also CoffeeScript and ClojureScript.
+
+
The best part is that no drastic changes have been required to support all those use cases. Most of the efforts were targeted at polishing edge cases, performance improvements, and documentation.
+
+
Khan Academy - Officially moving to React
+
+
Joel Burget announced at Hack Reactor that new front-end code at Khan Academy should be written in React!
+
+
+
How did we get the rest of the team to adopt React? Using interns as an attack vector! Most full-time devs had already been working on their existing projects for a while and weren't looking to try something new at the time, but our class of summer interns was just arriving. For whatever reason, a lot of them decided to try React for their projects. Then mentors became exposed through code reviews or otherwise touching the new code. In this way React knowledge diffused to almost the whole team over the summer.
+
+
Since the first React checkin on June 5, we've somehow managed to accumulate 23500 lines of jsx (React-flavored js) code. Which is terrifying in a way - that's a lot of code - but also really exciting that it was picked up so quickly.
+
+
We held three meetings about how we should proceed with React. At the first two we decided to continue experimenting with React and deferred a final decision on whether to adopt it. At the third we adopted the policy that new code should be written in React.
+
+
I'm excited that we were able to start nudging code quality forward. However, we still have a lot of work to do! One of the selling points of this transition is adopting a uniform frontend style. We're trying to upgrade all the code from (really old) pure jQuery and (regular old) Backbone views / Handlebars to shiny React. At the moment all we've done is introduce more fragmentation. We won't be gratuitously updating working code (if it ain't broke, don't fix it), but are seeking out parts of the codebase where we can shoot two birds with one stone by rewriting in React while fixing bugs or adding functionality.
Webkit has a TodoMVC Benchmark that compares different frameworks. They recently included React and here are the results (average of 10 runs in Chrome 30):
Please don't take those numbers too seriously, they only reflect one very specific use case and are testing code that wasn't written with performance in mind.
+
+
Even though React scores as one of the fastest frameworks in the benchmark, the React code is simple and idiomatic. The only performance tweak used is the following function:
+
/**
+ * This is a completely optional performance enhancement that you can implement
+ * on any React component. If you were to delete this method the app would still
+ * work correctly (and still be very performant!), we just use it as an example
+ * of how little code it takes to get an order of magnitude performance improvement.
+ */
+shouldComponentUpdate:function(nextProps,nextState){
+ return(
+ nextProps.todo.id!==this.props.todo.id||
+ nextProps.todo!==this.props.todo||
+ nextProps.editing!==this.props.editing||
+ nextState.editText!==this.state.editText
+ );
+},
+
+
By default, React "re-renders" all the components when anything changes. This is usually fast enough that you don't need to care. However, you can provide a function that can tell whether there will be any change based on the previous and next states and props. If it is faster than re-rendering the component, then you get a performance improvement.
+
+
The fact that you can control when components are rendered is a very important characteristic of React as it gives you control over its performance. We are going to talk more about performance in the future, stay tuned.
+
+
Guess the filter
+
+
Connor McSheffrey implemented a small game using React. The goal is to guess which filter has been used to create the Instagram photo.
+
Eerily similar, no? Maybe Facebook was inspired by Fruit Machine (after all, we got there first), but more likely, it just shows that this is a pretty decent way to solve the problem, and great minds think alike. We're graduating to a third phase in the evolution of web best practice - from intermingling of markup, style and behaviour, through a phase in which those concerns became ever more separated and encapsulated, and finally to a model where we can do that separation at a component level. Developments like Web Components show the direction the web community is moving, and frameworks like React and Fruit Machine are in fact not a lot more than polyfills for that promised behaviour to come.
Even though we weren't inspired by FruitMachine (React has been used in production since before FruitMachine was open sourced), it's great to see similar technologies emerging and becoming popular.
This release focuses on fixing some small bugs that have been uncovered over the past two weeks. I would like to thank everybody involved, specifically members of the community who fixed half of the issues found. Thanks to Ben Alpert, Andrey Popp, and Laurence Rowe for their contributions!
+
This release focuses on fixing some small bugs that have been uncovered over the past two weeks. I would like to thank everybody involved, specifically members of the community who fixed half of the issues found. Thanks to Sophie Alpert, Andrey Popp, and Laurence Rowe for their contributions!
Changelog
@@ -391,7 +546,7 @@
PETE: Exactly, exactly. In order to implement that, we communicate it as a fake DOM. What we'll do is rather than throw out the actual browser html and event handlers, we have an internal representation of what the page looks like and then we generate a brand new representation of what we want the page to look like. Then we perform this really, really fast diffing algorithm between those two page representations, DOM representations. Then React will compute the minimum set of DOM mutations it needs to make to bring the page up to date.
-
Then to finally get to answer your question, that set of DOM mutations then goes into a queue and we can plug in arbitrary flushing strategies for that. For example, when we originally launched React in open source, every setState would immediately trigger a flush to the DOM. That wasn't part of the contract of setState, but that was just our strategy and it worked pretty well. Then this totally awesome open source contributor Ben Alpert at Khan Academy built a new batching strategy which would basically queue up every single DOM update and state change that happened within an event tick and would execute them in bulk at the end of the event tick.
+
Then to finally get to answer your question, that set of DOM mutations then goes into a queue and we can plug in arbitrary flushing strategies for that. For example, when we originally launched React in open source, every setState would immediately trigger a flush to the DOM. That wasn't part of the contract of setState, but that was just our strategy and it worked pretty well. Then this totally awesome open source contributor Sophie Alpert at Khan Academy built a new batching strategy which would basically queue up every single DOM update and state change that happened within an event tick and would execute them in bulk at the end of the event tick.
Ben Alpert converted marked, a Markdown JavaScript implementation, in React: marked-react. Even without using JSX, the HTML generation is now a lot cleaner. It is also safer as forgetting a call to escape will not introduce an XSS vulnerability.
-
+
Sophie Alpert converted marked, a Markdown JavaScript implementation, in React: marked-react. Even without using JSX, the HTML generation is now a lot cleaner. It is also safer as forgetting a call to escape will not introduce an XSS vulnerability.
+
Pete Hunt ported the render code of the web version of Wolfenstein 3D to React. Check out the demo and render.js file for the implementation.
-
-
-
React & Meteor
-
-
Ben Newman made a 13-lines wrapper to use React and Meteor together. Meteor handles the real-time data synchronization between client and server. React provides the declarative way to write the interface and only updates the parts of the UI that changed.
-
-
-
This repository defines a Meteor package that automatically integrates the React rendering framework on both the client and the server, to complement or replace the default Handlebars templating system.
-
-
The React core is officially agnostic about how you fetch and update your data, so it is far from obvious which approach is the best. This package provides one answer to that question (use Meteor!), and I hope you will find it a compelling combination.
Dependencies will be registered for any data accesses performed by getMeteorState so that the component can be automatically re-rendered whenever the data changes.
Jordan Walke implemented a complete React project creator called react-page. It supports both server-side and client-side rendering, source transform and packaging JSX files using CommonJS modules, and instant reload.
-
-
-
Easy Application Development with React JavaScript
-
-
-
Why Server Rendering?
-
-
-
Faster initial page speed:
-
-
-
Markup displayed before downloading large JavaScript.
-
Markup can be generated more quickly on a fast server than low power client devices.
-
-
Faster Development and Prototyping:
-
-
-
Instantly refresh your app without waiting for any watch scripts or bundlers.
-
-
Easy deployment of static content pages/blogs: just archive using recursive wget.
-
SEO benefits of indexability and perf.
-
-
-
How Does Server Rendering Work?
-
-
-
react-page computes page markup on the server, sends it to the client so the user can see it quickly.
-
The corresponding JavaScript is then packaged and sent.
-
The browser runs that JavaScript, so that all of the event handlers, interactions and update code will run seamlessly on top of the server generated markup.
-
From the developer's (and the user's) perspective, it's just as if the rendering occurred on the client, only faster.
Pete Hunt ported the render code of the web version of Wolfenstein 3D to React. Check out the demo and render.js file for the implementation.
+
+
+
React & Meteor
+
+
Ben Newman made a 13-lines wrapper to use React and Meteor together. Meteor handles the real-time data synchronization between client and server. React provides the declarative way to write the interface and only updates the parts of the UI that changed.
+
+
+
This repository defines a Meteor package that automatically integrates the React rendering framework on both the client and the server, to complement or replace the default Handlebars templating system.
+
+
The React core is officially agnostic about how you fetch and update your data, so it is far from obvious which approach is the best. This package provides one answer to that question (use Meteor!), and I hope you will find it a compelling combination.
Dependencies will be registered for any data accesses performed by getMeteorState so that the component can be automatically re-rendered whenever the data changes.
Jordan Walke implemented a complete React project creator called react-page. It supports both server-side and client-side rendering, source transform and packaging JSX files using CommonJS modules, and instant reload.
+
+
+
Easy Application Development with React JavaScript
+
+
+
Why Server Rendering?
+
+
+
Faster initial page speed:
+
+
+
Markup displayed before downloading large JavaScript.
+
Markup can be generated more quickly on a fast server than low power client devices.
+
+
Faster Development and Prototyping:
+
+
+
Instantly refresh your app without waiting for any watch scripts or bundlers.
+
+
Easy deployment of static content pages/blogs: just archive using recursive wget.
+
SEO benefits of indexability and perf.
+
+
+
How Does Server Rendering Work?
+
+
+
react-page computes page markup on the server, sends it to the client so the user can see it quickly.
+
The corresponding JavaScript is then packaged and sent.
+
The browser runs that JavaScript, so that all of the event handlers, interactions and update code will run seamlessly on top of the server generated markup.
+
From the developer's (and the user's) perspective, it's just as if the rendering occurred on the client, only faster.
We launched the React Facebook Page along with the React v0.4 launch. 700 people already liked it to get updated on the project :)
-
-
Cross-browser onChange
-
-
Ben Alpert from Khan Academy worked on a cross-browser implementation of onChange event that landed in v0.4. He wrote a blog post explaining the various browser quirks he had to deal with.
-
-
-
First off, what is the input event? If you have an <input> element and want to receive events whenever the value changes, the most obvious thing to do is to listen to the change event. Unfortunately, change fires only after the text field is defocused, rather than on each keystroke. The next obvious choice is the keyup event, which is triggered whenever a key is released. Unfortunately, keyup doesn't catch input that doesn't involve the keyboard (e.g., pasting from the clipboard using the mouse) and only fires once if a key is held down, rather than once per inserted character.
-
-
Both keydown and keypress do fire repeatedly when a key is held down, but both fire immediately before the value changes, so to read the new value you have to defer the handler to the next event loop using setTimeout(fn, 0) or similar, which slows down your app. Of course, like keyup, neither keydown nor keypress fires for non-keyboard input events, and all three can fire in cases where the value doesn't change at all (such as when pressing the arrow keys).
Domenic Denicola wrote a slide deck about the great applications of ES6 features and one slide shows how we could use Template Strings to compile JSX at run-time without the need for a pre-processing phase.
-
-
-
-
React Presentation
-
-
Tom Occhino and Jordan Walke, React developers, did a presentation of React at Facebook Seattle's office. Check out the first 25 minutes for the presentation and the remaining 45 for a Q&A. I highly recommend you watching this video.
-
-
-
-
Docs
-
-
Pete Hunt rewrote the entirety of the docs for v0.4. The goal was to add more explanation about why we built React and what the best practices are.
We launched the React Facebook Page along with the React v0.4 launch. 700 people already liked it to get updated on the project :)
+
+
Cross-browser onChange
+
+
Sophie Alpert from Khan Academy worked on a cross-browser implementation of onChange event that landed in v0.4. She wrote a blog post explaining the various browser quirks she had to deal with.
+
+
+
First off, what is the input event? If you have an <input> element and want to receive events whenever the value changes, the most obvious thing to do is to listen to the change event. Unfortunately, change fires only after the text field is defocused, rather than on each keystroke. The next obvious choice is the keyup event, which is triggered whenever a key is released. Unfortunately, keyup doesn't catch input that doesn't involve the keyboard (e.g., pasting from the clipboard using the mouse) and only fires once if a key is held down, rather than once per inserted character.
+
+
Both keydown and keypress do fire repeatedly when a key is held down, but both fire immediately before the value changes, so to read the new value you have to defer the handler to the next event loop using setTimeout(fn, 0) or similar, which slows down your app. Of course, like keyup, neither keydown nor keypress fires for non-keyboard input events, and all three can fire in cases where the value doesn't change at all (such as when pressing the arrow keys).
Domenic Denicola wrote a slide deck about the great applications of ES6 features and one slide shows how we could use Template Strings to compile JSX at run-time without the need for a pre-processing phase.
+
+
+
+
React Presentation
+
+
Tom Occhino and Jordan Walke, React developers, did a presentation of React at Facebook Seattle's office. Check out the first 25 minutes for the presentation and the remaining 45 for a Q&A. I highly recommend you watching this video.
+
+
+
+
Docs
+
+
Pete Hunt rewrote the entirety of the docs for v0.4. The goal was to add more explanation about why we built React and what the best practices are.
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.
@@ -408,122 +540,6 @@ If you were using React without JSX previously, your code should still work.
-
-
The highlight of this week is that an interaction-heavy app has been ported to React. React components are solving issues they had with nested views.
-
-
Moving From Backbone To React
-
-
Clay Allsopp successfully ported Propeller, a fairly big, interaction-heavy JavaScript app, to React.
-
-
-
Subviews involve a lot of easy-to-forget boilerplate that Backbone (by design) doesn't automate. Libraries like Backbone.Marionette offer more abstractions to make view nesting easier, but they're all limited by the fact that Backbone delegates how and went view-document attachment occurs to the application code.
-
-
React, on the other hand, manages the DOM and only exposes real nodes at select points in its API. The "elements" you code in React are actually objects which wrap DOM nodes, not the actual objects which get inserted into the DOM. Internally, React converts those abstractions into actual DOMElements and fills out the document accordingly. [...]
-
-
We moved about 20 different Backbone view classes to React over the past few weeks, including the live-preview pane that you see in our little iOS demo. Most importantly, it's allowed us to put energy into making each component work great on its own, instead of spending extra cycles to ensure they function in unison. For that reason, we think React is a more scalable way to build view-intensive apps than Backbone alone, and it doesn't require you to drop-everything-and-refactor like a move to Ember or Angular would demand.
Eric Clemmons wrote a task for Grunt that applies the JSX transformation to your JavaScript files. It also works with Browserify if you want all your files to be concatenated and minified together.
-
-
-
Grunt task for compiling Facebook React's .jsx templates into .js
Joel Burget wrote a blog post talking about the way we would write React-like components in Backbone and Handlebars.
-
-
-
The problem here is that we're trying to maniplate a tree, but there's a textual layer we have to go through. Our views are represented as a tree - the subviews are children of CommentCollectionView - and they end up as part of a tree in the DOM. But there's a Handlebars layer in the middle (which deals in flat strings), so the hierarchy must be destructed and rebuilt when we render.
-
-
What does it take to render a collection view? In the Backbone/Handlebars view of the world you have to render the template (with stubs), render each subview which replaces a stub, and keep a reference to each subview (or anything within the view that could change in the future).
-
-
So while our view is conceptually hierarchical, due to the fact that it has to go through a flat textual representation, we need to do a lot of extra work to reassemble that structure after rendering.
Vjeux used the fact that JSX is just a syntactic sugar on-top of regular JS to rewrite the React front-page examples in CoffeeScript.
-
-
-
Multiple people asked what's the story about JSX and CoffeeScript. There is no JSX pre-processor for CoffeeScript and I'm not aware of anyone working on it. Fortunately, CoffeeScript is pretty expressive and we can play around the syntax to come up with something that is usable.
We've seen a lot of people comparing React with various frameworks. Ricardo Tomasi decided to re-implement the tutorial without any framework, just plain JavaScript.
-
-
-
Facebook & Instagram launched the React framework and an accompanying tutorial. Developer Vlad Yazhbin decided to rewrite that using AngularJS. The end result is pretty neat, but if you're like me you will not actually appreciate the HTML speaking for itself and doing all the hard work. So let's see what that looks like in plain javascript.
The highlight of this week is that an interaction-heavy app has been ported to React. React components are solving issues they had with nested views.
+
+
Moving From Backbone To React
+
+
Clay Allsopp successfully ported Propeller, a fairly big, interaction-heavy JavaScript app, to React.
+
+
+
Subviews involve a lot of easy-to-forget boilerplate that Backbone (by design) doesn't automate. Libraries like Backbone.Marionette offer more abstractions to make view nesting easier, but they're all limited by the fact that Backbone delegates how and went view-document attachment occurs to the application code.
+
+
React, on the other hand, manages the DOM and only exposes real nodes at select points in its API. The "elements" you code in React are actually objects which wrap DOM nodes, not the actual objects which get inserted into the DOM. Internally, React converts those abstractions into actual DOMElements and fills out the document accordingly. [...]
+
+
We moved about 20 different Backbone view classes to React over the past few weeks, including the live-preview pane that you see in our little iOS demo. Most importantly, it's allowed us to put energy into making each component work great on its own, instead of spending extra cycles to ensure they function in unison. For that reason, we think React is a more scalable way to build view-intensive apps than Backbone alone, and it doesn't require you to drop-everything-and-refactor like a move to Ember or Angular would demand.
Eric Clemmons wrote a task for Grunt that applies the JSX transformation to your JavaScript files. It also works with Browserify if you want all your files to be concatenated and minified together.
+
+
+
Grunt task for compiling Facebook React's .jsx templates into .js
Joel Burget wrote a blog post talking about the way we would write React-like components in Backbone and Handlebars.
+
+
+
The problem here is that we're trying to maniplate a tree, but there's a textual layer we have to go through. Our views are represented as a tree - the subviews are children of CommentCollectionView - and they end up as part of a tree in the DOM. But there's a Handlebars layer in the middle (which deals in flat strings), so the hierarchy must be destructed and rebuilt when we render.
+
+
What does it take to render a collection view? In the Backbone/Handlebars view of the world you have to render the template (with stubs), render each subview which replaces a stub, and keep a reference to each subview (or anything within the view that could change in the future).
+
+
So while our view is conceptually hierarchical, due to the fact that it has to go through a flat textual representation, we need to do a lot of extra work to reassemble that structure after rendering.
Vjeux used the fact that JSX is just a syntactic sugar on-top of regular JS to rewrite the React front-page examples in CoffeeScript.
+
+
+
Multiple people asked what's the story about JSX and CoffeeScript. There is no JSX pre-processor for CoffeeScript and I'm not aware of anyone working on it. Fortunately, CoffeeScript is pretty expressive and we can play around the syntax to come up with something that is usable.
We've seen a lot of people comparing React with various frameworks. Ricardo Tomasi decided to re-implement the tutorial without any framework, just plain JavaScript.
+
+
+
Facebook & Instagram launched the React framework and an accompanying tutorial. Developer Vlad Yazhbin decided to rewrite that using AngularJS. The end result is pretty neat, but if you're like me you will not actually appreciate the HTML speaking for itself and doing all the hard work. So let's see what that looks like in plain javascript.
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:
+
It looks like Sophie Alpert is the first person outside of Facebook and Instagram to push React code to production. We are very grateful for her contributions in form of pull requests, bug reports and presence on IRC (#reactjs on Freenode). Sophie wrote about her 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:
-
JSFiddle just announced support for React. This is an exciting news as it makes collaboration on snippets of code a lot easier. You can play around this base React JSFiddle, fork it and share it! A fiddle without JSX is also available.
JSFiddle just announced support for React. This is an exciting news as it makes collaboration on snippets of code a lot easier. You can play around this base React JSFiddle, fork it and share it! A fiddle without JSX is also available.
Create React App is a new officially supported way to create single-page React applications. It offers a modern build setup with no configuration.
+
+
Getting Started
+
+
Installation
+
+
First, install the global package:
+
npm install -g create-react-app
+
+
Node.js 4.x or higher is required.
+
+
Creating an App
+
+
Now you can use it to create a new app:
+
create-react-app hello-world
+
+
This will take a while as npm installs the transitive dependencies, but once it’s done, you will see a list of commands you can run in the created folder:
+
+
+
+
Starting the Server
+
+
Run npm start to launch the development server. The browser will open automatically with the created app’s URL.
+
+
+
+
Create React App uses both webpack and Babel under the hood.
+The console output is tuned to be minimal to help you focus on the problems:
+
+
+
+
ESLint is also integrated so lint warnings are displayed right in the console:
+
+
+
+
We only picked a small subset of lint rules that often lead to bugs.
+
+
Building for Production
+
+
To build an optimized bundle, run npm run build:
+
+
+
+
It is minified, correctly envified, and the assets include content hashes for caching.
+
+
One Dependency
+
+
Your package.json contains only a single build dependency and a few scripts:
We take care of updating Babel, ESLint, and webpack to stable compatible versions so you can update a single dependency to get them all.
+
+
Zero Configuration
+
+
It is worth repeating: there are no configuration files or complicated folder structures. The tool only generates the files you need to build your app.
All the build settings are preconfigured and can’t be changed. Some features, such as testing, are currently missing. This is an intentional limitation, and we recognize it might not work for everybody. And this brings us to the last point.
+
+
No Lock-In
+
+
We first saw this feature in Enclave, and we loved it. We talked to Ean, and he was excited to collaborate with us. He already sent a few pull requests!
+
+
“Ejecting” lets you leave the comfort of Create React App setup at any time. You run a single command, and all the build dependencies, configs, and scripts are moved right into your project. At this point you can customize everything you want, but effectively you are forking our configuration and going your own way. If you’re experienced with build tooling and prefer to fine-tune everything to your taste, this lets you use Create React App as a boilerplate generator.
+
+
We expect that at early stages, many people will “eject” for one reason or another, but as we learn from them, we will make the default setup more and more compelling while still providing no configuration.
+
+
Try It Out!
+
+
You can find Create React App with additional instructions on GitHub.
+
+
This is an experiment, and only time will tell if it becomes a popular way of creating and building React apps, or fades into obscurity.
+
+
We welcome you to participate in this experiment. Help us build the React tooling that more people can use. We are always open to feedback.
+
+
The Backstory
+
+
React was one of the first libraries to embrace transpiling JavaScript. As a result, even though you can learn React without any tooling, the React ecosystem has commonly become associated with an overwhelming explosion of tools.
Ultimately, the problem is that by choosing React (and inherently JSX), you’ve unwittingly opted into a confusing nest of build tools, boilerplate, linters, & time-sinks to deal with before you ever get to create anything.
+
+
+
It is tempting to write code in ES2015 and JSX. It is sensible to use a bundler to keep the codebase modular, and a linter to catch the common mistakes. It is nice to have a development server with fast rebuilds, and a command to produce optimized bundles for production.
+
+
Combining these tools requires some experience with each of them. Even so, it is far too easy to get dragged into fighting small incompatibilities, unsatisfied peerDependencies, and illegible configuration files.
+
+
Many of those tools are plugin platforms and don’t directly acknowledge each other’s existence. They leave it up to the users to wire them together. The tools mature and change independently, and tutorials quickly get out of date.
This doesn’t mean those tools aren’t great. To many of us, they have become indispensable, and we very much appreciate the effort of their maintainers. They already have too much on their plates to worry about the state of the React ecosystem.
+
+
Still, we knew it was frustrating to spend days setting up a project when all you wanted was to learn React. We wanted to fix this.
+
+
Could We Fix This?
+
+
We found ourselves in an unusual dilemma.
+
+
So far, our strategy has been to only release the code that we are using at Facebook. This helped us ensure that every project is battle-tested and has clearly defined scope and priorities.
+
+
However, tooling at Facebook is different than at many smaller companies. Linting, transpilation, and packaging are all handled by powerful remote development servers, and product engineers don’t need to configure them. While we wish we could give a dedicated server to every user of React, even Facebook cannot scale that well!
+
+
The React community is very important to us. We knew that we couldn’t fix the problem within the limits of our open source philosophy. This is why we decided to make an exception, and to ship something that we didn’t use ourselves, but that we thought would be useful to the community.
+
+
The Quest for a React CLI
+
+
Having just attended EmberCamp a week ago, I was excited about Ember CLI. Ember users have a great “getting started” experience thanks to a curated set of tools united under a single command-line interface. I have heard similar feedback about Elm Reactor.
+
+
Providing a cohesive curated experience is valuable by itself, even if the user could in theory assemble those parts themselves. Kathy Sierra explains it best:
+
+
+
If your UX asks the user to make choices, for example, even if those choices are both clear and useful, the act of deciding is a cognitive drain. And not just while they’re deciding... even after we choose, an unconscious cognitive background thread is slowly consuming/leaking resources, “Was that the right choice?”
+
+
+
I never tried to write a command-line tool for React apps, and neither has Christopher. We were chatting on Messenger about this idea, and we decided to work together on it for a week as a hackathon project.
+
+
We knew that such projects traditionally haven’t been very successful in the React ecosystem. Christopher told me that multiple “React CLI” projects have started and failed at Facebook. The community tools with similar goals also exist, but so far they have not yet gained enough traction.
+
+
Still, we decided it was worth another shot. Christopher and I created a very rough proof of concept on the weekend, and Kevin soon joined us.
+
+
We invited some of the community members to collaborate with us, and we have spent this week working on this tool. We hope that you’ll enjoy using it! Let us know what you think.
Minified exception occurred; use the non-minified dev environment for the full error message and additional helpful warnings.
-
In order to make debugging in production easier, we're introducing an Error Code System in 15.2.0. We developed a gulp script that collects all of our invariant error messages and folds them to a JSON file, and at build-time Babel uses the JSON to rewrite our invariant calls in production to reference the corresponding error IDs. Now when things go wrong in production, the error that React throws will contain a URL with an error ID and relevant information. The URL will point you to a page in our documentation where the original error message gets reassembled.
+
In order to make debugging in production easier, we're introducing an Error Code System in 15.2.0. We developed a gulp script that collects all of our invariant error messages and folds them to a JSON file, and at build-time Babel uses the JSON to rewrite our invariant calls in production to reference the corresponding error IDs. Now when things go wrong in production, the error that React throws will contain a URL with an error ID and relevant information. The URL will point you to a page in our documentation where the original error message gets reassembled.
While we hope you don't see errors often, you can see how it works here. This is what the same error from above will look like:
@@ -801,7 +985,7 @@ Minified build for production: h
Another big change with our DOM interaction is how we render text blocks. Previously you may have noticed that React rendered a lot of extra <span>s. For example, in our most basic example on the home page we render <div>Hello {this.props.name}</div>, resulting in markup that contained 2 <span>s. Now we’ll render plain text nodes interspersed with comment nodes that are used for demarcation. This gives us the same ability to update individual pieces of text, without creating extra nested nodes. Very few people have depended on the actual markup generated here so it’s likely you are not impacted. However if you were targeting these <span>s in your CSS, you will need to adjust accordingly. You can always render them explicitly in your components.
@@ -902,7 +1086,7 @@ Minified build for production: h
We added support for defining stateless components as functions in React 0.14. However, React 0.14 still allowed you to define a class component without extending React.Component or using React.createClass(), so we couldn’t reliably tell if your component is a function or a class, and did not allow returning null from it. This issue is solved in React 15, and you can now return null from any component, whether it is a class or a function.
@@ -970,7 +1154,7 @@ Minified build for production: h
React DOM: When specifying a unit-less CSS value as a string, a future version will not add px automatically. This version now warns in this case (ex: writing style={{width: '300'}}. Unitless number values like width: 300 are unchanged. @pluma in #5140
Synthetic Events will now warn when setting and accessing properties (which will not get cleared appropriately), as well as warn on access after an event has been returned to the pool.
@@ -1003,7 +1187,7 @@ Minified build for production: h
Input events are handled more reliably in IE 10 and IE 11; spurious events no longer fire when using a placeholder. @jquense in #4051
The componentWillReceiveProps() lifecycle method is now consistently called when context changes.
@@ -1054,69 +1238,7 @@ Minified build for production: h
We have already released two release candidates for React 15, and the final version is coming soon.
-
-
However Ian Christian Myers discovered a memory leak related to server rendering in React 0.14 and contributed a fix. While this memory leak has already been fixed in a different way in the React 15 release candidates, we decided to cut another 0.14 release that contains just this fix.
We have already released two release candidates for React 15, and the final version is coming soon.
+
+
However Ian Christian Myers discovered a memory leak related to server rendering in React 0.14 and contributed a fix. While this memory leak has already been fixed in a different way in the React 15 release candidates, we decided to cut another 0.14 release that contains just this fix.
The documentation for componentWillReceiveProps states that componentWillReceiveProps will be invoked when the props change as the result of a rerender. Some people assume this means "if componentWillReceiveProps is called, then the props must have changed", but that conclusion is logically incorrect.
-
-
The guiding principle is one of my favorites from formal logic/mathematics:
-
-
-
A implies B does not imply B implies A
-
-
-
Example: "If I eat moldy food, then I will get sick" does not imply "if I am sick, then I must have eaten moldy food". There are many other reasons I could be feeling sick. For instance, maybe the flu is circulating around the office. Similarly, there are many reasons that componentWillReceiveProps might get called, even if the props didn’t change.
-
-
If you don’t believe me, call ReactDOM.render() three times with the exact same props, and try to predict the number of times componentWillReceiveProps will get called:
In this case, the answer is "2". React calls componentWillReceiveProps twice (once for each of the two updates). Both times, the value of "drinks" is printed (ie. the props didn’t change).
-
-
To understand why, we need to think about what could have happened. The data could have changed between the initial render and the two subsequent updates, if the code had performed a mutation like this:
React has no way of knowing that the data didn’t change. Therefore, React needs to call componentWillReceiveProps, because the component needs to be notified of the new props (even if the new props happen to be the same as the old props).
-
-
You might think that React could just use smarter checks for equality, but there are some issues with this idea:
-
-
-
The old mydata and the new mydata are actually the same physical object (only the object’s internal value changed). Since the references are triple-equals-equal, doing an equality check doesn’t tell us if the value has changed. The only possible solution would be to have created a deep copy of the data, and then later do a deep comparison - but this can be prohibitively expensive for large data structures (especially ones with cycles).
-
The mydata object might contain references to functions which have captured variables within closures. There is no way for React to peek into these closures, and thus no way for React to copy them and/or verify equality.
-
The mydata object might contain references to objects which are re-instantiated during the parent's render (ie. not triple-equals-equal) but are conceptually equal (ie. same keys and same values). A deep-compare (expensive) could detect this, except that functions present a problem again because there is no reliable way to compare two functions to see if they are semantically equivalent.
-
-
-
Given the language constraints, it is sometimes impossible for us to achieve meaningful equality semantics. In such cases, React will call componentWillReceiveProps (even though the props might not have changed) so the component has an opportunity to examine the new props and act accordingly.
-
-
As a result, your implementation of componentWillReceiveProps MUST NOT assume that your props have changed. If you want an operation (such as a network request) to occur only when props have changed, your componentWillReceiveProps code needs to check to see if the props actually changed.
The documentation for componentWillReceiveProps states that componentWillReceiveProps will be invoked when the props change as the result of a rerender. Some people assume this means "if componentWillReceiveProps is called, then the props must have changed", but that conclusion is logically incorrect.
+
+
The guiding principle is one of my favorites from formal logic/mathematics:
+
+
+
A implies B does not imply B implies A
+
+
+
Example: "If I eat moldy food, then I will get sick" does not imply "if I am sick, then I must have eaten moldy food". There are many other reasons I could be feeling sick. For instance, maybe the flu is circulating around the office. Similarly, there are many reasons that componentWillReceiveProps might get called, even if the props didn’t change.
+
+
If you don’t believe me, call ReactDOM.render() three times with the exact same props, and try to predict the number of times componentWillReceiveProps will get called:
In this case, the answer is "2". React calls componentWillReceiveProps twice (once for each of the two updates). Both times, the value of "drinks" is printed (ie. the props didn’t change).
+
+
To understand why, we need to think about what could have happened. The data could have changed between the initial render and the two subsequent updates, if the code had performed a mutation like this:
React has no way of knowing that the data didn’t change. Therefore, React needs to call componentWillReceiveProps, because the component needs to be notified of the new props (even if the new props happen to be the same as the old props).
+
+
You might think that React could just use smarter checks for equality, but there are some issues with this idea:
+
+
+
The old mydata and the new mydata are actually the same physical object (only the object’s internal value changed). Since the references are triple-equals-equal, doing an equality check doesn’t tell us if the value has changed. The only possible solution would be to have created a deep copy of the data, and then later do a deep comparison - but this can be prohibitively expensive for large data structures (especially ones with cycles).
+
The mydata object might contain references to functions which have captured variables within closures. There is no way for React to peek into these closures, and thus no way for React to copy them and/or verify equality.
+
The mydata object might contain references to objects which are re-instantiated during the parent's render (ie. not triple-equals-equal) but are conceptually equal (ie. same keys and same values). A deep-compare (expensive) could detect this, except that functions present a problem again because there is no reliable way to compare two functions to see if they are semantically equivalent.
+
+
+
Given the language constraints, it is sometimes impossible for us to achieve meaningful equality semantics. In such cases, React will call componentWillReceiveProps (even though the props might not have changed) so the component has an opportunity to examine the new props and act accordingly.
+
+
As a result, your implementation of componentWillReceiveProps MUST NOT assume that your props have changed. If you want an operation (such as a network request) to occur only when props have changed, your componentWillReceiveProps code needs to check to see if the props actually changed.
It's time for another installment of React patch releases! We didn't break anything in v0.14.2 but we do have a couple of other bugs we're fixing. The biggest change in this release is actually an addition of a new built file. We heard from a number of people that they still need the ability to use React to render to a string on the client. While the use cases are not common and there are other ways to achieve this, we decided that it's still valuable to support. So we're now building react-dom-server.js, which will be shipped to Bower and in the dist/ directory of the react-dom package on npm. This file works the same way as react-dom.js and therefore requires that the primary React build has already been included on the page.
It's time for another installment of React patch releases! We didn't break anything in v0.14.2 but we do have a couple of other bugs we're fixing. The biggest change in this release is actually an addition of a new built file. We heard from a number of people that they still need the ability to use React to render to a string on the client. While the use cases are not common and there are other ways to achieve this, we decided that it's still valuable to support. So we're now building react-dom-server.js, which will be shipped to Bower and in the dist/ directory of the react-dom package on npm. This file works the same way as react-dom.js and therefore requires that the primary React build has already been included on the page.
When you're in React's world you are just building components that fit into other components. Everything is a component. Unfortunately not everything around you is built using React. At the root of your tree you still have to write some plumbing code to connect the outer world into React.
-
-
The primary API for rendering into the DOM looks like this:
-
ReactDOM.render(reactElement,domContainerNode)
-
-
To update the properties of an existing component, you call render again with a new element.
-
-
If you are rendering React components within a single-page app, you may need to plug into the app's view lifecycle to ensure your app will invoke unmountComponentAtNode at the appropriate time. React will not automatically clean up a tree. You need to manually call:
This is important and often forgotten. Forgetting to call unmountComponentAtNode will cause your app to leak memory. There is no way for us to automatically detect when it is appropriate to do this work. Every system is different.
-
-
It is not unique to the DOM. If you want to insert a React Native view in the middle of an existing iOS app you will hit similar issues.
-
-
Helpers
-
-
If you have multiple React roots, or a single root that gets deleted over time, we recommend that you always create your own wrapper API. These will all look slightly different depending on what your outer system looks like. For example, at Facebook we have a system that automatically ties into our page transition router to automatically call unmountComponentAtNode.
-
-
Rather than calling ReactDOM.render() directly everywhere, consider writing/using a library that will manage mounting and unmounting within your application.
-
-
In your environment you may want to always configure internationalization, routers, user data etc. If you have many different React roots it can be a pain to set up configuration nodes all over the place. By creating your own wrapper you can unify that configuration into one place.
-
-
Object Oriented Updates
-
-
If you call ReactDOM.render a second time to update properties, all your props are completely replaced.
In object-oriented programming, all state lives on each object instance and you apply changes incrementally by mutating that state, one piece at a time. If you are using React within an app that expects an object oriented API (for instance, if you are building a custom web component using React), it might be surprising/confusing to a user that setting a single property would wipe out all the other properties on your component.
-
-
We used to have a helper function called setProps which allowed you to update only a few properties at a time. Unfortunately this API lived on a component instance, required React to keep this state internally and wasn't very natural anyway. Therefore, we're deprecating it and suggest that you build it into your own wrapper instead.
-
-
Here's some boilerplate to get you started. It is a 0.14 migration path for codebases using setProps and replaceProps.
-
classReactComponentRenderer{
- constructor(klass,container){
- this.klass=klass;
- this.container=container;
- this.props={};
- this.component=null;
- }
-
- replaceProps(props,callback){
- this.props={};
- this.setProps(props,callback);
- }
-
- setProps(partialProps,callback){
- if(this.klass==null){
- console.warn(
- 'setProps(...): Can only update a mounted or '+
- 'mounting component. This usually means you called setProps() on '+
- 'an unmounted component. This is a no-op.'
- );
- return;
- }
- Object.assign(this.props,partialProps);
- varelement=React.createElement(this.klass,this.props);
- this.component=ReactDOM.render(element,this.container,callback);
- }
-
- unmount(){
- ReactDOM.unmountComponentAtNode(this.container);
- this.klass=null;
- }
-}
-
-
Object-oriented APIs don't look like that though. They use setters and methods. I think we can do better. If you know more about the component API that you're rendering, you can create a more natural object-oriented API around your React component.
This example shows how to provide an imperative API on top of a declarative one. Similarly, the reverse can be done, and a declarative wrapper can be used when exposing a Web Component as a React component.
When you're in React's world you are just building components that fit into other components. Everything is a component. Unfortunately not everything around you is built using React. At the root of your tree you still have to write some plumbing code to connect the outer world into React.
+
+
The primary API for rendering into the DOM looks like this:
+
ReactDOM.render(reactElement,domContainerNode)
+
+
To update the properties of an existing component, you call render again with a new element.
+
+
If you are rendering React components within a single-page app, you may need to plug into the app's view lifecycle to ensure your app will invoke unmountComponentAtNode at the appropriate time. React will not automatically clean up a tree. You need to manually call:
This is important and often forgotten. Forgetting to call unmountComponentAtNode will cause your app to leak memory. There is no way for us to automatically detect when it is appropriate to do this work. Every system is different.
+
+
It is not unique to the DOM. If you want to insert a React Native view in the middle of an existing iOS app you will hit similar issues.
+
+
Helpers
+
+
If you have multiple React roots, or a single root that gets deleted over time, we recommend that you always create your own wrapper API. These will all look slightly different depending on what your outer system looks like. For example, at Facebook we have a system that automatically ties into our page transition router to automatically call unmountComponentAtNode.
+
+
Rather than calling ReactDOM.render() directly everywhere, consider writing/using a library that will manage mounting and unmounting within your application.
+
+
In your environment you may want to always configure internationalization, routers, user data etc. If you have many different React roots it can be a pain to set up configuration nodes all over the place. By creating your own wrapper you can unify that configuration into one place.
+
+
Object Oriented Updates
+
+
If you call ReactDOM.render a second time to update properties, all your props are completely replaced.
In object-oriented programming, all state lives on each object instance and you apply changes incrementally by mutating that state, one piece at a time. If you are using React within an app that expects an object oriented API (for instance, if you are building a custom web component using React), it might be surprising/confusing to a user that setting a single property would wipe out all the other properties on your component.
+
+
We used to have a helper function called setProps which allowed you to update only a few properties at a time. Unfortunately this API lived on a component instance, required React to keep this state internally and wasn't very natural anyway. Therefore, we're deprecating it and suggest that you build it into your own wrapper instead.
+
+
Here's some boilerplate to get you started. It is a 0.14 migration path for codebases using setProps and replaceProps.
+
classReactComponentRenderer{
+ constructor(klass,container){
+ this.klass=klass;
+ this.container=container;
+ this.props={};
+ this.component=null;
+ }
+
+ replaceProps(props,callback){
+ this.props={};
+ this.setProps(props,callback);
+ }
+
+ setProps(partialProps,callback){
+ if(this.klass==null){
+ console.warn(
+ 'setProps(...): Can only update a mounted or '+
+ 'mounting component. This usually means you called setProps() on '+
+ 'an unmounted component. This is a no-op.'
+ );
+ return;
+ }
+ Object.assign(this.props,partialProps);
+ varelement=React.createElement(this.klass,this.props);
+ this.component=ReactDOM.render(element,this.container,callback);
+ }
+
+ unmount(){
+ ReactDOM.unmountComponentAtNode(this.container);
+ this.klass=null;
+ }
+}
+
+
Object-oriented APIs don't look like that though. They use setters and methods. I think we can do better. If you know more about the component API that you're rendering, you can create a more natural object-oriented API around your React component.
This example shows how to provide an imperative API on top of a declarative one. Similarly, the reverse can be done, and a declarative wrapper can be used when exposing a Web Component as a React component.
Today we're excited to share an update on Relay - the technical preview is now open-source and available on GitHub.
-
-
Why Relay
-
-
While React simplified the process of developing complex user-interfaces, it left open the question of how to interact with data on the server. It turns out that this was a significant source of friction for our developers; fragile coupling between client and server caused data-related bugs and made iteration harder. Furthermore, developers were forced to constantly re-implement complex async logic instead of focusing on their apps. Relay addresses these concerns by borrowing important lessons from React: it provides declarative, component-oriented data fetching for React applications.
-
-
Declarative data-fetching means that Relay applications specify what data they need, not how to fetch that data. Just as React uses a description of the desired UI to manage view updates, Relay uses a data description in the form of GraphQL queries. Given these descriptions, Relay coalesces queries into batches for efficiency, manages error-prone asynchronous logic, caches data for performance, and automatically updates views as data changes.
-
-
Relay is also component-oriented, extending the notion of a React component to include a description of what data is necessary to render it. This colocation allows developers to reason locally about their application and eliminates bugs such as under- or over-fetching data.
-
-
Relay is in use at Facebook in production apps, and we're using it more and more because Relay lets developers focus on their products and move fast. It's working for us and we'd like to share it with the community.
-
-
What's Included
-
-
We're open-sourcing a technical preview of Relay - the core framework that we use internally, with some modifications for use outside Facebook. As this is the first release, it's good to keep in mind that there may be some incomplete or missing features. We'll continue to develop Relay and are working closely with the GraphQL community to ensure that Relay tracks updates during GraphQL's RFC period. But we couldn't wait any longer to get this in your hands, and we're looking forward to your feedback and contributions.
The team is super excited to be releasing Relay - and just as excited about what's next. Here are some of the things we'll be focusing on:
-
-
-
Offline support. This will allow applications to fulfill queries and enqueue updates without connectivity.
-
Real-time updates. In collaboration with the GraphQL community, we're working to define a specification for subscriptions and provide support for them in Relay.
-
A generic Relay. Just as the power of React was never about the virtual DOM, Relay is much more than a GraphQL client. We're working to extend Relay to provide a unified interface for interacting not only with server data, but also in-memory and native device data (and, even better, a mix of all three).
-
Finally, it's all too easy as developers to focus on those people with the newest devices and fastest internet connections. We're working to make it easier to build applications that are robust in the face of slow or intermittent connectivity.
Today we're excited to share an update on Relay - the technical preview is now open-source and available on GitHub.
+
+
Why Relay
+
+
While React simplified the process of developing complex user-interfaces, it left open the question of how to interact with data on the server. It turns out that this was a significant source of friction for our developers; fragile coupling between client and server caused data-related bugs and made iteration harder. Furthermore, developers were forced to constantly re-implement complex async logic instead of focusing on their apps. Relay addresses these concerns by borrowing important lessons from React: it provides declarative, component-oriented data fetching for React applications.
+
+
Declarative data-fetching means that Relay applications specify what data they need, not how to fetch that data. Just as React uses a description of the desired UI to manage view updates, Relay uses a data description in the form of GraphQL queries. Given these descriptions, Relay coalesces queries into batches for efficiency, manages error-prone asynchronous logic, caches data for performance, and automatically updates views as data changes.
+
+
Relay is also component-oriented, extending the notion of a React component to include a description of what data is necessary to render it. This colocation allows developers to reason locally about their application and eliminates bugs such as under- or over-fetching data.
+
+
Relay is in use at Facebook in production apps, and we're using it more and more because Relay lets developers focus on their products and move fast. It's working for us and we'd like to share it with the community.
+
+
What's Included
+
+
We're open-sourcing a technical preview of Relay - the core framework that we use internally, with some modifications for use outside Facebook. As this is the first release, it's good to keep in mind that there may be some incomplete or missing features. We'll continue to develop Relay and are working closely with the GraphQL community to ensure that Relay tracks updates during GraphQL's RFC period. But we couldn't wait any longer to get this in your hands, and we're looking forward to your feedback and contributions.
The team is super excited to be releasing Relay - and just as excited about what's next. Here are some of the things we'll be focusing on:
+
+
+
Offline support. This will allow applications to fulfill queries and enqueue updates without connectivity.
+
Real-time updates. In collaboration with the GraphQL community, we're working to define a specification for subscriptions and provide support for them in Relay.
+
A generic Relay. Just as the power of React was never about the virtual DOM, Relay is much more than a GraphQL client. We're working to extend Relay to provide a unified interface for interacting not only with server data, but also in-memory and native device data (and, even better, a mix of all three).
+
Finally, it's all too easy as developers to focus on those people with the newest devices and fastest internet connections. We're working to make it easier to build applications that are robust in the face of slow or intermittent connectivity.
Today we're sharing another patch release in the v0.13 branch. There are only a few small changes, with a couple to address some issues that arose around that undocumented feature so many of you are already using: context. We also improved developer ergonomics just a little bit, making some warnings better.
Today we're sharing another patch release in the v0.13 branch. There are only a few small changes, with a couple to address some issues that arose around that undocumented feature so many of you are already using: context. We also improved developer ergonomics just a little bit, making some warnings better.
In January at React.js Conf, we announced React Native, a new framework for building native apps using React. We're happy to announce that we're open-sourcing React Native and you can start building your apps with it today.
What we really want is the user experience of the native mobile platforms, combined with the developer experience we have when building with React on the web.
-
-
With a bit of work, we can make it so the exact same React that's on GitHub can power truly native mobile applications. The only difference in the mobile environment is that instead of running React in the browser and rendering to divs and spans, we run it an embedded instance of JavaScriptCore inside our apps and render to higher-level platform-specific components.
-
-
It's worth noting that we're not chasing “write once, run anywhere.” Different platforms have different looks, feels, and capabilities, and as such, we should still be developing discrete apps for each platform, but the same set of engineers should be able to build applications for whatever platform they choose, without needing to learn a fundamentally different set of technologies for each. We call this approach “learn once, write anywhere.”
@@ -335,7 +336,7 @@ to assistive technology, such as screen readers.
Please note that browser / screen reader combinations matter. It is recommended that you test your application in the browser best suited to your screen reader of choice.
The keys of the passed object (that is, left and right) are used as keys for the entire set of children, and the order of the object's keys is used to determine the order of the rendered children. With this change, the two sets of children will be properly reordered in the DOM without unmounting.
-
The return value of createFragment should be treated as an opaque object; you can use the React.Children helpers to loop through a fragment but should not access it directly. Note also that we're relying on the JavaScript engine preserving object enumeration order here, which is not guaranteed by the spec but is implemented by all major browsers and VMs for objects with non-numeric keys.
+
The return value of createFragment should be treated as an opaque object; you can use the React.Children helpers to loop through a fragment but should not access it directly. Note also that we're relying on the JavaScript engine preserving object enumeration order here, which is not guaranteed by the spec but is implemented by all major browsers and VMs for objects with non-numeric keys.
It renders a header saying "Hello World" on the page.
+
It renders a header saying "Hello, world!" on the page.
The next few sections will gradually introduce you to using React. We will examine the building blocks of React apps: elements and components. Once you master them, you can create complex apps from small reusable pieces.
What?! If you break it apart, it's easier to see what's going on.
// connect is a function that returns another function
@@ -320,14 +321,14 @@
This form may seem confusing or unnecessary, but it has a useful property. Single-argument HOCs like the one returned by the connect function have the signature Component => Component. Functions whose output type is the same as its input type are really easy to compose together.
// Instead of doing this...
-constEnhancedComponent=connect(commentSelector)(withRouter(WrappedComponent))
+constEnhancedComponent=withRouter(connect(commentSelector)(WrappedComponent))// ... you can use a function composition utility// compose(f, g, h) is the same as (...args) => f(g(h(...args)))constenhance=compose(// These are both single-argument HOCs
- connect(commentSelector),
- withRouter
+ withRouter,
+ connect(commentSelector))constEnhancedComponent=enhance(WrappedComponent)
If you don't want to use npm to manage client packages, the react and react-dom npm packages also provide single-file distributions in dist folders, which are hosted on a CDN:
If you don't want to use npm to manage client packages, the react and react-dom npm packages also provide single-file distributions in umd folders, which are hosted on a CDN:
The versions above are only meant for development, and are not suitable for production. Minified and optimized production versions of React are available at:
React 16 depends on the collection types Map and Set. If you support older browsers and devices which may not yet provide these natively (e.g. IE < 11), consider including a global polyfill in your bundled application, such as core-js or babel-polyfill.
+
+
A polyfilled environment for React 16 using core-js to support older browsers might look like:
Portals provide a first-class way to render children into a DOM node that exists outside the DOM hierarchy of the parent component.
+
ReactDOM.createPortal(child,container)
+
+
The first argument (child) is any renderable React child, such as an element, string, or fragment. The second argument (container) is a DOM element.
+
+
Usage
+
+
Normally, when you return an element from a component's render method, it's mounted into the DOM as a child of the nearest parent node:
+
render(){
+ // React mounts a new div and renders the children into it
+ return(
+<div>
+{this.props.children}
+</div>
+);
+}
+
+
However, sometimes it's useful to insert a child into a different location in the DOM:
+
render(){
+ // React does *not* create a new div. It renders the children into `domNode`.
+ // `domNode` is any valid DOM node, regardless of its location in the DOM.
+ returnReact.createPortal(
+ this.props.children,
+domNode,
+);
+}
+
+
A typical use case for portals is when a parent component has an overflow: hidden or z-index style, but you need the child to visually "break out" of its container. For example, dialogs, hovercards, and tooltips.
+
+
+
Note:
+
+
For most uses portals, you'll need to make sure to follow the proper accessibility guidelines.
A nice feature of portals is that, even though the DOM node can be anywhere in the DOM tree, it behaves like a normal React child in every other way. Features like context work exactly the same regardless of whether the child is a portal.
+
+
This includes event bubbling: an event fired from inside a portal will propagate to ancestors in the containing React tree, even if those elements are not ancestors in the DOM tree:
+
// These two containers are siblings in the DOM
+constappContainer=document.getElementById('app-container');
+constmodalContainer=document.getElementById('modal-container');
+
+classParentextendsReact.Component{
+ state={clicks:0};
+ onClick=()=>{
+ // This will fire when the button in Child is clicked, even though
+ // button is not direct descendant in the DOM.
+ this.setState(state=>({clicks:state.clicks+1}));
+ };
+ render(){
+ return(
+ <divonClick={this.onClick}>
+ <p>Numberofclicks:{this.state.clicks}</p>
+ <p>OpenupthebrowserDevToolstoobservethatthebuttonisnotachildthedivwithonClickhandler.</p>
+ {ReactDOM.createPortal(<Child/>,modalContainer)}
+ </div>
+ );
+ }
+}
+
+functionChild(){
+ return<button>Click</button>;
+}
+
+
+ReactDOM.render(<Parent/>,appContainer);
+
The advantage of treating portal event bubbling this way is that it makes it easier to build abstractions. For example, if you render a <Modal /> component, the parent can capture its events regardless of whether it's implemented using portals.
When called, it should examine this.props and this.state and return a single React element. This element can be either a representation of a native DOM component, such as <div />, or another composite component that you've defined yourself.
+
When called, it should examine this.props and this.state and return one of the following types:
-
You can also return null or false to indicate that you don't want anything rendered. When returning null or false, ReactDOM.findDOMNode(this) will return null.
+
+
React elements. Typically created via JSX. A element can either be a representation of a native DOM component (<div />), or a user-defined composite component (<MyComponent />).
+
String and numbers. These are rendered as text nodes in the DOM.
Booleans. Render nothing. (Mostly exists to support return test && <Child /> pattern, where test is boolean.)
+
+
+
When returning null or false, ReactDOM.findDOMNode(this) will return null.
The render() function should be pure, meaning that it does not modify component state, it returns the same result each time it's invoked, and it does not directly interact with the browser. If you need to interact with the browser, perform your work in componentDidMount() or the other lifecycle methods instead. Keeping render() pure makes components easier to think about.
Don't forget to add keys to elements in a fragment to avoid the key warning.
+
+
constructor()
@@ -358,7 +384,7 @@
displayName
-
The displayName string is used in debugging messages. JSX sets this value automatically; see JSX in Depth.
+
The displayName string is used in debugging messages. Usually, you don't need to set it explicitly because it's inferred from the name of the function or class that defines the component. You might want to set it explicitly if you want to display a different name for debugging purposes or when you create a higher-order component, see Wrap the Display Name for Easy Debugging for details.
If you load React from a <script> tag, these top-level APIs are available on the ReactDOMServer global. If you use ES6 with npm, you can write import ReactDOMServer from 'react-dom/server'. If you use ES5 with npm, you can write var ReactDOMServer = require('react-dom/server').
-
+
The ReactDOMServer object enables you to render components to static markup. Typically, it's used on a Node server:
+
// ES modules
+importReactDOMServerfrom'react-dom/server';
+// CommonJS
+varReactDOMServer=require('react-dom/server');
+
+
We also provide a separate entry-point for use in the browser:
+
// ES modules
+importReactDOMServerfrom'react-dom/server.browser';
+// CommonJS
+varReactDOMServer=require('react-dom/server.browser');
+
+
Or, using UMD:
+
<script crossoriginsrc="https://unpkg.com/react-dom/umd/react-dom-server.browser.production.min.js"/>
+<!-- Accessible as window.ReactDOMServer -->
+
Overview
-
The ReactDOMServer object allows you to render your components on the server.
+
The following methods can be used in both the server and browser environments:
Render a React element to its initial HTML. This should only be used on the server. React will return an HTML string. You can use this method to generate HTML on the server and send the markup down on the initial request for faster page loads and to allow search engines to crawl your pages for SEO purposes.
+
Render a React element to its initial HTML. React will return an HTML string. You can use this method to generate HTML on the server and send the markup down on the initial request for faster page loads and to allow search engines to crawl your pages for SEO purposes.
-
If you call ReactDOM.render() on a node that already has this server-rendered markup, React will preserve it and only attach event handlers, allowing you to have a very performant first-load experience.
+
If you call ReactDOM.hydrate() on a node that already has this server-rendered markup, React will preserve it and only attach event handlers, allowing you to have a very performant first-load experience.
@@ -107,6 +129,36 @@
Similar to renderToString, except this doesn't create extra DOM attributes such as data-reactid, that React uses internally. This is useful if you want to use React as a simple static page generator, as stripping away the extra attributes can save lots of bytes.
+
+
+
renderToNodeStream()
+
ReactDOMNodeStream.renderToNodeStream(element)
+
+
Render a React element to its initial HTML. Returns a Readable stream that outputs an HTML string. The HTML output by this stream is exactly equal to what ReactDOMServer.renderToString would return.
+
+
+
Note:
+
+
Server-only. This API is not available in the browser.
+
+
The stream returned from this method will return a byte stream encoded in utf-8. If you need a stream in another encoding, take a look a project like iconv-lite, which provides transform streams for transcoding text.
Similar to renderToNodeStream, except this doesn't create extra DOM attributes such as data-reactid, that React uses internally. The HTML output by this stream is exactly equal to what ReactDOMServer.renderToStaticMarkup would return.
+
+
+
Note:
+
+
Server-only. This API is not available in the browser.
+
+
The stream returned from this method will return a byte stream encoded in utf-8. If you need a stream in another encoding, take a look a project like iconv-lite, which provides transform streams for transcoding text.
ReactDOM.render() currently returns a reference to the root ReactComponent instance. However, using this return value is legacy
and should be avoided because future versions of React may render components asynchronously in some cases. If you need a reference to the root ReactComponent instance, the preferred solution is to attach a
callback ref to the root element.
+
+
Using ReactDOM.render() to hydrate a server-rendered container is deprecated and will be removed in React 17. Use hydrate() instead.
Same as render(), but is used to hydrate a container whose HTML contents were rendered by ReactDOMServer. React will attach event listeners while preserving as much of the existing DOM as possible. For best results, you should try to render the same content on the server as on the client, with as few differences as possible.
+
+
+
unmountComponentAtNode()
ReactDOM.unmountComponentAtNode(container)
@@ -153,6 +169,13 @@ and should be avoided because future versions of React may render components asy
findDOMNode cannot be used on functional components.
importTestRendererfrom'react-test-renderer';// ES6
+constTestRenderer=require('react-test-renderer');// ES5 with npm
+
+
Overview
+
+
This package provides a React renderer that can be used to render React components to pure JavaScript objects, without depending on the DOM or a native mobile environment.
+
+
Essentially, this package makes it easy to grab a snapshot of the platform view hierarchy (similar to a DOM tree) rendered by a React DOM or React Native component without using a browser or jsdom.
You can use Jest's snapshot testing feature to automatically save a copy of the JSON tree to a file and check in your tests that it hasn't changed: Learn more about it.
+
+
You can also traverse the output to find specific nodes and make assertions about them.
Create a TestRenderer instance with a passed element, which has the following methods and properties.
+
+
testRenderer.toJSON()
+
testRenderer.toJSON()
+
+
Return a JSON object representing the element.
+
+
testRenderer.toTree()
+
testRenderer.toTree()
+
+
Return a tree object representing the element.
+
+
testRenderer.update()
+
testRenderer.update(element)
+
+
Update the element with a passed element.
+
+
testRenderer.unmount()
+
testRenderer.unmount()
+
+
Unmount the element from testRenderer.
+
+
testRenderer.getInstance()
+
testRenderer.getInstance()
+
+
Return a root container instance.
+
+
testRenderer.root
+
testRenderer.root
+
+
root is a testInstance, which has the following methods and properties.
+
+
testInstance.find()
+
testInstance.find(test)
+
+
Find a descendant testInstance that test(testInstance) is true.
+
+
testInstance.findByType()
+
testInstance.findByType(type)
+
+
Find a descendant testInstance that matches the provided type.
+
+
testInstance.findByProps()
+
testInstance.findByProps(props)
+
+
Find a descendant testInstance that matches the provided props.
+
+
testInstance.findAll()
+
testInstance.findAll(test)
+
+
Find all descendant testInstances that test(testInstance) is true.
+
+
testInstance.findAllByType()
+
testInstance.findAllByType(type)
+
+
Find all descendant testInstances that matches the provided type.
+
+
testInstance.findAllByProps()
+
testInstance.findAllByProps(props)
+
+
Find all descendant testInstances that matches the provided props.
+
+
testInstance.instance
+
testInstance.instance
+
+
instance is a component instance of the testInstance.
+
+
testInstance.type
+
testInstance.type
+
+
type is a Component type of the testInstance.
+
+
testInstance.props
+
testInstance.props
+
+
props is a props object of the testInstance.
+
+
testInstance.parent
+
testInstance.parent
+
+
parent is a parent testInstance.
+
+
testInstance.children
+
testInstance.children
+
+
children is children of the testInstance.
+
+
Ideas
+
+
You can pass createNodeMock function to TestRenderer.create as the option, which allows for custom mock refs.
+createNodeMock accepts the current element and should return a mock ref object.
+This is useful when you test a component rely on refs.
LinkedStateMixin is an easy way to express two-way binding with React.
-
In React, data flows one way: from owner to child. This is because data only flows one direction in the Von Neumann model of computing. You can think of it as "one-way data binding."
+
In React, data flows one way: from owner to child. We think that this makes your app's code easier to understand. You can think of it as "one-way data binding."
However, there are lots of applications that require you to read some data and flow it back into your program. For example, when developing forms, you'll often want to update some React state when you receive user input. Or perhaps you want to perform layout in JavaScript and react to changes in some DOM element size.
+
diff --git a/downloads/react-15.4.0-rc.3.zip b/downloads/react-15.4.0-rc.3.zip
new file mode 100644
index 0000000000..d1a9786648
Binary files /dev/null and b/downloads/react-15.4.0-rc.3.zip differ
diff --git a/downloads/react-15.4.1.zip b/downloads/react-15.4.1.zip
deleted file mode 100644
index c29baf37e1..0000000000
Binary files a/downloads/react-15.4.1.zip and /dev/null differ
diff --git a/feed.xml b/feed.xml
index b65ce1a640..ea07047994 100644
--- a/feed.xml
+++ b/feed.xml
@@ -6,6 +6,206 @@
https://facebook.github.io/react
+
+ React v16.0
+ <p>We're excited to announce the release of React v16.0! Among the changes are some long-standing feature requests, including <a href="#new-render-return-types-fragments-and-strings"><strong>fragments</strong></a>, <a href="#better-error-handling"><strong>error boundaries</strong></a>, <a href="#portals"><strong>portals</strong></a>, support for <a href="#support-for-custom-dom-attributes"><strong>custom DOM attributes</strong></a>, improved <a href="#better-server-side-rendering"><strong>server-side rendering</strong></a>, and <a href="#reduced-file-size"><strong>reduced file size</strong></a>.</p>
+
+<h3>New render return types: fragments and strings</h3>
+
+<p>You can now return an array of elements from a component's <code>render</code> method. Like with other arrays, you'll need to add a key to each element to avoid the key warning:</p>
+<div class="highlight"><pre><code class="language-js" data-lang="js"><span class="nx">render</span><span class="p">()</span> <span class="p">{</span>
+ <span class="c1">// No need to wrap list items in an extra element!</span>
+ <span class="k">return</span> <span class="p">[</span>
+ <span class="c1">// Don't forget the keys :)</span>
+ <span class="o"><</span><span class="nx">li</span> <span class="nx">key</span><span class="o">=</span><span class="s2">"A"</span><span class="o">></span><span class="nx">First</span> <span class="nx">item</span><span class="o"><</span><span class="err">/li>,</span>
+ <span class="o"><</span><span class="nx">li</span> <span class="nx">key</span><span class="o">=</span><span class="s2">"B"</span><span class="o">></span><span class="nx">Second</span> <span class="nx">item</span><span class="o"><</span><span class="err">/li>,</span>
+ <span class="o"><</span><span class="nx">li</span> <span class="nx">key</span><span class="o">=</span><span class="s2">"C"</span><span class="o">></span><span class="nx">Third</span> <span class="nx">item</span><span class="o"><</span><span class="err">/li>,</span>
+ <span class="p">];</span>
+<span class="p">}</span>
+</code></pre></div>
+<p>In the future, we'll likely add a special fragment syntax to JSX that doesn't require keys.</p>
+
+<p>We've added support for returning strings, too:</p>
+<div class="highlight"><pre><code class="language-js" data-lang="js"><span class="nx">render</span><span class="p">()</span> <span class="p">{</span>
+ <span class="k">return</span> <span class="s1">'Look ma, no spans!'</span><span class="p">;</span>
+<span class="p">}</span>
+</code></pre></div>
+<p><a href="/react/docs/react-component.html#render">See the full list of supported return types</a>.</p>
+
+<h3>Better error handling</h3>
+
+<p>Previously, runtime errors during rendering could put React in a broken state, producing cryptic error messages and requiring a page refresh to recover. To address this problem, React 16 uses a more resilient error-handling strategy. By default, if an error is thrown inside a component's render or lifecycle methods, the whole component tree is unmounted from the root. This prevents the display of corrupted data. However, it's probably not the ideal user experience.</p>
+
+<p>Instead of unmounting the whole app every time there's an error, you can use error boundaries. Error boundaries are special components that capture errors inside their subtree and display a fallback UI in its place. Think of error boundaries like try-catch statements, but for React components.</p>
+
+<p>For more details, check out our <a href="/react/blog/2017/07/26/error-handling-in-react-16.html">previous post on error handling in React 16</a>.</p>
+
+<h3>Portals</h3>
+
+<p>Portals provide a first-class way to render children into a DOM node that exists outside the DOM hierarchy of the parent component.</p>
+<div class="highlight"><pre><code class="language-js" data-lang="js"><span class="nx">render</span><span class="p">()</span> <span class="p">{</span>
+ <span class="c1">// React does *not* create a new div. It renders the children into `domNode`.</span>
+ <span class="c1">// `domNode` is any valid DOM node, regardless of its location in the DOM.</span>
+ <span class="k">return</span> <span class="nx">ReactDOM</span><span class="p">.</span><span class="nx">createPortal</span><span class="p">(</span>
+ <span class="k">this</span><span class="p">.</span><span class="nx">props</span><span class="p">.</span><span class="nx">children</span><span class="p">,</span>
+ <span class="nx">domNode</span><span class="p">,</span>
+ <span class="p">);</span>
+<span class="p">}</span>
+</code></pre></div>
+<p>See a full example in the <a href="/react/docs/portals.html">documentation for portals</a>.</p>
+
+<h3>Better server-side rendering</h3>
+
+<p>React 16 includes a completely rewritten server renderer. It's really fast. It supports <strong>streaming</strong>, so you can start sending bytes to the client faster. And thanks to a <a href="#reduced-file-size">new packaging strategy</a> that compiles away <code>process.env</code> checks (Believe it or not, reading <code>process.env</code> in Node is really slow!), you no longer need to bundle React to get good server-rendering performance.</p>
+
+<p>Core team member Sasha Aickin wrote a <a href="https://medium.com/@aickin/whats-new-with-server-side-rendering-in-react-16-9b0d78585d67">great article describing React 16's SSR improvements</a>. According to Sasha's synthetic benchmarks, server rendering in React 16 is roughly <strong>three times faster</strong> than React 15. "When comparing against React 15 with <code>process.env</code> compiled out, there’s about a 2.4x improvement in Node 4, about a 3x performance improvement in Node 6, and a full 3.8x improvement in the new Node 8.4 release. And if you compare against React 15 without compilation, React 16 has a full order of magnitude gain in SSR in the latest version of Node!" (As Sasha points out, please be aware that these numbers are based on synthetic benchmarks and may not reflect real-world performance.)</p>
+
+<p>In addition, React 16 is better at hydrating server-rendered HTML once it reaches the client. It no longer requires the initial render to exactly match the result from the server. Instead, it will attempt to reuse as much of the existing DOM as possible. No more checksums! In general, we don't recommend that you render different content on the client versus the server, but it can be useful in some cases (e.g. timestamps).</p>
+
+<p>See the <a href="/react/docs/react-dom-server.html">documentation for <code>ReactDOMServer</code></a> for more details.</p>
+
+<h3>Support for custom DOM attributes</h3>
+
+<p>Instead of ignoring unrecognized HTML and SVG attributes, React will now <a href="https://facebook.github.io/react/blog/2017/09/08/dom-attributes-in-react-16.html">pass them through to the DOM</a>. This has the added benefit of allowing us to get rid of most of React's attribute whitelist, resulting in reduced file sizes.</p>
+
+<h3>Reduced file size</h3>
+
+<p>Despite all these additions, React 16 is actually <strong>smaller</strong> compared to 15.6.1!</p>
+
+<ul>
+<li><code>react</code> is 5.3 kb (2.2 kb gzipped), down from 20.7 kb (6.9 kb gzipped).</li>
+<li><code>react-dom</code> is 103.7 kb (32.6 kb gzipped), down from 141 kb (42.9 kb gzipped).</li>
+<li><code>react</code> + <code>react-dom</code> is 109 kb (34.8 kb gzipped), down from 161.7 kb (49.8 kb gzipped).</li>
+</ul>
+
+<p>That amounts to a combined <strong>32% size decrease compared to the previous version (30% post-gzip)</strong>.</p>
+
+<p>The size difference is partly attributable to a change in packaging. React now uses <a href="https://rollupjs.org/">Rollup</a> to create flat bundles for each of its different target formats, resulting in both size and runtime performance wins. The flat bundle format also means that React's impact on bundle size is roughly consistent regardless of how your ship your app, whether it's with Webpack, Browserify, the pre-built UMD bundles, or any other system.</p>
+
+<h3>MIT licensed</h3>
+
+<p><a href="https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/">In case you missed it</a>, React 16 is available under the MIT license. We've also published React 15.6.2 under MIT, for those who are unable to upgrade immediately.</p>
+
+<h3>New core architecture</h3>
+
+<p>React 16 is the first version of React built on top of a new core architecture, codenamed "Fiber." You can read all about this project over on <a href="https://code.facebook.com/posts/1716776591680069/react-16-a-look-inside-an-api-compatible-rewrite-of-our-frontend-ui-library/">Facebook's engineering blog</a>. (Spoiler: we rewrote React!)</p>
+
+<p>Fiber is responsible for most of the new features in React 16, like error boundaries and fragments. Over the next few releases, you can expect more new features as we begin to unlock the full potential of React.</p>
+
+<p>Perhaps the most exciting area we're working on is <strong>async rendering</strong>—a strategy for cooperatively scheduling rendering work by periodically yielding execution to the browser. The upshot is that, with async rendering, apps are more responsive because React avoids blocking the main thread.</p>
+
+<p>This demo provides an early peek at the types of problems async rendering can solve:</p>
+
+<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Ever wonder what "async rendering" means? Here's a demo of how to coordinate an async React tree with non-React work <a href="https://t.co/3snoahB3uV">https://t.co/3snoahB3uV</a> <a href="https://t.co/egQ988gBjR">pic.twitter.com/egQ988gBjR</a></p>— Andrew Clark (@acdlite) <a href="https://twitter.com/acdlite/status/909926793536094209">September 18, 2017</a></blockquote>
+
+<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
+
+<p><em>Tip: Pay attention to the spinning black square.</em></p>
+
+<p>We think async rendering is a big deal, and represents the future of React. To make migration to v16.0 as smooth as possible, we're not enabling any async features yet, but we're excited to start rolling them out in the coming months. Stay tuned!</p>
+
+<h2>Installation</h2>
+
+<p>React v16.0.0 is available on the npm registry.</p>
+
+<p>To install React 16 with Yarn, run:</p>
+<div class="highlight"><pre><code class="language-bash" data-lang="bash">yarn add react@^16.0.0 react-dom@^16.0.0
+</code></pre></div>
+<p>To install React 16 with npm, run:</p>
+<div class="highlight"><pre><code class="language-bash" data-lang="bash">npm install --save react@^16.0.0 react-dom@^16.0.0
+</code></pre></div>
+<p>We also provide UMD builds of React via a CDN:</p>
+<div class="highlight"><pre><code class="language-html" data-lang="html"><span class="nt"><script </span><span class="na">crossorigin</span> <span class="na">src=</span><span class="s">"https://unpkg.com/react@16/umd/react.production.min.js"</span><span class="nt">></script></span>
+<span class="nt"><script </span><span class="na">crossorigin</span> <span class="na">src=</span><span class="s">"https://unpkg.com/react-dom@16/umd/react-dom.production.min.js"</span><span class="nt">></script></span>
+</code></pre></div>
+<p>Refer to the documentation for <a href="/react/docs/installation.html">detailed installation instructions</a>.</p>
+
+<h2>Upgrading</h2>
+
+<p>Although React 16 includes significant internal changes, in terms of upgrading, you can think of this like any other major React release. We've been serving React 16 to Facebook and Messenger.com users since earlier this year, and we released several beta and release candidate versions to flush out additional issues. With minor exceptions, <strong>if your app runs in 15.6 without any warnings, it should work in 16.</strong></p>
+
+<h3>New deprecations</h3>
+
+<p>Hydrating a server-rendered container now has an explicit API. If you're reviving server-rendered HTML, use <a href="/react/docs/react-dom.html#hydrate"><code>ReactDOM.hydrate</code></a> instead of <code>ReactDOM.render</code>. Keep using <code>ReactDOM.render</code> if you're just doing client-side rendering.</p>
+
+<h3>React Addons</h3>
+
+<p>As previously announced, we've <a href="/react/blog/2017/04/07/react-v15.5.0.html#discontinuing-support-for-react-addons">discontinued support for React Addons</a>. We expect the latest version of each addon (except <code>react-addons-perf</code>; see below) to work for the foreseeable future, but we won't publish additional updates.</p>
+
+<p>Refer to the previous announcement for <a href="/react/blog/2017/04/07/react-v15.5.0.html#discontinuing-support-for-react-addons">suggestions on how to migrate</a>.</p>
+
+<p><code>react-addons-perf</code> no longer works at all in React 16. It's likely that we'll release a new version of this tool in the future. In the meantime, you can <a href="/react/docs/optimizing-performance.html#profiling-components-with-the-chrome-performance-tab">use your browser's performance tools to profile React components</a>.</p>
+
+<h3>Breaking changes</h3>
+
+<p>React 16 includes a number of small breaking changes. These only affect uncommon use cases and we don't expect them to break most apps.</p>
+
+<ul>
+<li>React 15 had limited, undocumented support for error boundaries using <code>unstable_handleError</code>. This method has been renamed to <code>componentDidCatch</code>. You can use a codemod to <a href="https://github.com/reactjs/react-codemod#error-boundaries">automatically migrate to the new API</a>.</li>
+<li><code>ReactDOM.render</code> and <code>ReactDOM.unstable_renderIntoContainer</code> now return null if called from inside a lifecycle method. To work around this, you can use <a href="https://github.com/facebook/react/issues/10309#issuecomment-318433235">portals</a> or <a href="https://github.com/facebook/react/issues/10309#issuecomment-318434635">refs</a>.</li>
+<li><code>setState</code>:
+
+<ul>
+<li>Calling <code>setState</code> with null no longer triggers an update. This allows you to decide in an updater function if you want to re-render.</li>
+<li>Calling <code>setState</code> directly in render always causes an update. This was not previously the case. Regardless, you should not be calling setState from render.</li>
+<li><code>setState</code> callbacks (second argument) now fire immediately after <code>componentDidMount</code> / <code>componentDidUpdate</code> instead of after all components have rendered.</li>
+</ul></li>
+<li>When replacing <code><A /></code> with <code><B /></code>, <code>B.componentWillMount</code> now always happens before <code>A.componentWillUnmount</code>. Previously, <code>A.componentWillUnmount</code> could fire first in some cases.</li>
+<li>Previously, changing the ref to a component would always detach the ref before that component's render is called. Now, we change the ref later, when applying the changes to the DOM.</li>
+<li>It is not safe to re-render into a container that was modified by something other than React. This worked previously in some cases but was never supported. We now emit a warning in this case. Instead you should clean up your component trees using <code>ReactDOM.unmountComponentAtNode</code>. <a href="https://github.com/facebook/react/issues/10294#issuecomment-318820987">See this example.</a></li>
+<li><code>componentDidUpdate</code> lifecycle no longer receives <code>prevContext</code> param. (See <a href="https://github.com/facebook/react/issues/8631">#8631</a>)</li>
+<li>Shallow renderer no longer calls <code>componentDidUpdate</code> because DOM refs are not available. This also makes it consistent with <code>componentDidMount</code> (which does not get called in previous versions either).</li>
+<li>Shallow renderer does not implement <code>unstable_batchedUpdates</code> anymore.</li>
+</ul>
+
+<h3>Packaging</h3>
+
+<ul>
+<li>There is no <code>react/lib/*</code> and <code>react-dom/lib/*</code> anymore. Even in CommonJS environments, React and ReactDOM are precompiled to single files (“flat bundles”). If you previously relied on undocumented React internals, and they don’t work anymore, let us know about your specific case in a new issue, and we’ll try to figure out a migration strategy for you.</li>
+<li>There is no <code>react-with-addons.js</code> build anymore. All compatible addons are published separately on npm, and have single-file browser versions if you need them.</li>
+<li>The deprecations introduced in 15.x have been removed from the core package. <code>React.createClass</code> is now available as <code>create-react-class</code>, <code>React.PropTypes</code> as <code>prop-types</code>, <code>React.DOM</code> as <code>react-dom-factories</code>, <code>react-addons-test-utils</code> as <code>react-dom/test-utils</code>, and shallow renderer as <code>react-test-renderer/shallow</code>. See <a href="https://facebook.github.io/react/blog/2017/04/07/react-v15.5.0.html">15.5.0</a> and <a href="https://facebook.github.io/react/blog/2017/06/13/react-v15.6.0.html">15.6.0</a> blog posts for instructions on migrating code and automated codemods.</li>
+<li>The names and paths to the single-file browser builds have changed to emphasize the difference between development and production builds. For example:
+
+<ul>
+<li><code>react/dist/react.js</code> → <code>react/umd/react.development.js</code></li>
+<li><code>react/dist/react.min.js</code> → <code>react/umd/react.production.min.js</code></li>
+<li><code>react-dom/dist/react-dom.js</code> → <code>react-dom/umd/react-dom.development.js</code></li>
+<li><code>react-dom/dist/react-dom.min</code>.js → <code>react-dom/umd/react-dom.production.min.js</code></li>
+</ul></li>
+</ul>
+
+<h2>JavaScript Environment Requirements</h2>
+
+<p>React 16 depends on the collection types <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map">Map</a> and <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set">Set</a>. If you support older browsers and devices which may not yet provide these natively (e.g. IE < 11), consider including a global polyfill in your bundled application, such as <a href="https://github.com/zloirock/core-js">core-js</a> or <a href="https://babeljs.io/docs/usage/polyfill/">babel-polyfill</a>.</p>
+
+<p>A polyfilled environment for React 16 using core-js to support older browsers might look like:</p>
+<div class="highlight"><pre><code class="language-js" data-lang="js"><span class="kr">import</span> <span class="s1">'core-js/es6/map'</span><span class="p">;</span>
+<span class="kr">import</span> <span class="s1">'core-js/es6/set'</span><span class="p">;</span>
+
+<span class="kr">import</span> <span class="nx">React</span> <span class="nx">from</span> <span class="s1">'react'</span><span class="p">;</span>
+<span class="kr">import</span> <span class="nx">ReactDOM</span> <span class="nx">from</span> <span class="s1">'react-dom'</span><span class="p">;</span>
+
+<span class="nx">ReactDOM</span><span class="p">.</span><span class="nx">render</span><span class="p">(</span>
+ <span class="o"><</span><span class="nx">h1</span><span class="o">></span><span class="nx">Hello</span><span class="p">,</span> <span class="nx">world</span><span class="o">!<</span><span class="err">/h1>,</span>
+ <span class="nb">document</span><span class="p">.</span><span class="nx">getElementById</span><span class="p">(</span><span class="s1">'root'</span><span class="p">)</span>
+<span class="p">);</span>
+</code></pre></div>
+<p>React also depends on <code>requestAnimationFrame</code> (even in test environments). A simple shim for test environments would be:</p>
+<div class="highlight"><pre><code class="language-js" data-lang="js"><span class="nx">global</span><span class="p">.</span><span class="nx">requestAnimationFrame</span> <span class="o">=</span> <span class="kd">function</span><span class="p">(</span><span class="nx">callback</span><span class="p">)</span> <span class="p">{</span>
+ <span class="nx">setTimeout</span><span class="p">(</span><span class="nx">callback</span><span class="p">,</span> <span class="mi">0</span><span class="p">);</span>
+<span class="p">};</span>
+</code></pre></div>
+<h2>Acknowledgments</h2>
+
+<p>As always, this release would not have been possible without our open source contributors. Thanks to everyone who filed bugs, opened PRs, responded to issues, wrote documentation, and more!</p>
+
+<p>Special thanks to our core contributors, especially for their heroic efforts over the past few weeks during the prerelease cycle: <a href="https://twitter.com/aweary">Brandon Dail</a>, <a href="https://twitter.com/monasticpanic">Jason Quense</a>, <a href="https://twitter.com/natehunzaker">Nathan Hunzaker</a>, and <a href="https://twitter.com/xander76">Sasha Aickin</a>.</p>
+
+ 2017-09-26T00:00:00-07:00
+ https://facebook.github.io/react/blog/2017/09/26/react-v16.0.html
+ https://facebook.github.io/react/blog/2017/09/26/react-v16.0.html
+
+
React v15.6.2<p>Today we're sending out React 15.6.2. In 15.6.1, we shipped a few fixes for change events and inputs that had some unintended consequences. Those regressions have been ironed out, and we've also included a few more fixes to improve the stability of React across all browsers.</p>
@@ -1199,7 +1399,7 @@ I think we should just treat arrays of elements as a frag. This is useful for co
<ul>
<li>In March we added support for server-side rendering and for creating multiple instances of Relay on a single page. This was a coordinated effort over the course of several months by community members <a href="https://github.com/denvned">Denis Nedelyaev</a> and <a href="https://github.com/devknoll">Gerald Monaco</a> (now at Facebook).</li>
-<li>Also in March we added support for React Native. While we use Relay and React Native together internally, they didn't quite work together in open-source out of the box. We owe a big thanks to <a href="https://github.com/skevy">Adam Miskiewicz</a>, <a href="https://github.com/boourns">Tom Burns</a>, <a href="https://github.com/gre">Gaëtan Renaudeau</a>, <a href="https://github.com/davidaurelio">David Aurelio</a>, <a href="https://github.com/martinbigio">Martín Bigio</a>, <a href="https://github.com/zpao">Paul O’Shannessy</a>, <a href="https://github.com/spicyj">Ben Alpert</a>, and many others who helped track down and resolve issues. Finally, thanks to <a href="https://github.com/steveluscher">Steven Luscher</a> for coordinating this effort and building the first Relay/ReactNative example app.</li>
+<li>Also in March we added support for React Native. While we use Relay and React Native together internally, they didn't quite work together in open-source out of the box. We owe a big thanks to <a href="https://github.com/skevy">Adam Miskiewicz</a>, <a href="https://github.com/boourns">Tom Burns</a>, <a href="https://github.com/gre">Gaëtan Renaudeau</a>, <a href="https://github.com/davidaurelio">David Aurelio</a>, <a href="https://github.com/martinbigio">Martín Bigio</a>, <a href="https://github.com/zpao">Paul O’Shannessy</a>, <a href="https://github.com/sophiebits">Sophie Alpert</a>, and many others who helped track down and resolve issues. Finally, thanks to <a href="https://github.com/steveluscher">Steven Luscher</a> for coordinating this effort and building the first Relay/ReactNative example app.</li>
</ul>
<p>We've also seen some great open-source projects spring up around Relay:</p>
@@ -1273,166 +1473,5 @@ I think we should just treat arrays of elements as a frag. This is useful for co
https://facebook.github.io/react/blog/2016/08/05/relay-state-of-the-state.html
-
- Create Apps with No Configuration
- <p><strong><a href="https://github.com/facebookincubator/create-react-app">Create React App</a></strong> is a new officially supported way to create single-page React applications. It offers a modern build setup with no configuration.</p>
-
-<h2>Getting Started</h2>
-
-<h3>Installation</h3>
-
-<p>First, install the global package:</p>
-<div class="highlight"><pre><code class="language-sh" data-lang="sh">npm install -g create-react-app
-</code></pre></div>
-<p>Node.js 4.x or higher is required.</p>
-
-<h3>Creating an App</h3>
-
-<p>Now you can use it to create a new app:</p>
-<div class="highlight"><pre><code class="language-sh" data-lang="sh">create-react-app hello-world
-</code></pre></div>
-<p>This will take a while as npm installs the transitive dependencies, but once it’s done, you will see a list of commands you can run in the created folder:</p>
-
-<p><img src="/react/img/blog/create-apps-with-no-configuration/created-folder.png" alt="created folder"></p>
-
-<h3>Starting the Server</h3>
-
-<p>Run <code>npm start</code> to launch the development server. The browser will open automatically with the created app’s URL.</p>
-
-<p><img src="/react/img/blog/create-apps-with-no-configuration/compiled-successfully.png" alt="compiled successfully"></p>
-
-<p>Create React App uses both webpack and Babel under the hood.
-The console output is tuned to be minimal to help you focus on the problems:</p>
-
-<p><img src="/react/img/blog/create-apps-with-no-configuration/failed-to-compile.png" alt="failed to compile"></p>
-
-<p>ESLint is also integrated so lint warnings are displayed right in the console:</p>
-
-<p><img src="/react/img/blog/create-apps-with-no-configuration/compiled-with-warnings.png" alt="compiled with warnings"></p>
-
-<p>We only picked a small subset of lint rules that often lead to bugs.</p>
-
-<h3>Building for Production</h3>
-
-<p>To build an optimized bundle, run <code>npm run build</code>:</p>
-
-<p><img src="/react/img/blog/create-apps-with-no-configuration/npm-run-build.png" alt="npm run build"></p>
-
-<p>It is minified, correctly envified, and the assets include content hashes for caching.</p>
-
-<h3>One Dependency</h3>
-
-<p>Your <code>package.json</code> contains only a single build dependency and a few scripts:</p>
-<div class="highlight"><pre><code class="language-js" data-lang="js"><span class="p">{</span>
- <span class="s2">"name"</span><span class="o">:</span> <span class="s2">"hello-world"</span><span class="p">,</span>
- <span class="s2">"dependencies"</span><span class="o">:</span> <span class="p">{</span>
- <span class="s2">"react"</span><span class="o">:</span> <span class="s2">"^15.2.1"</span><span class="p">,</span>
- <span class="s2">"react-dom"</span><span class="o">:</span> <span class="s2">"^15.2.1"</span>
- <span class="p">},</span>
- <span class="s2">"devDependencies"</span><span class="o">:</span> <span class="p">{</span>
- <span class="s2">"react-scripts"</span><span class="o">:</span> <span class="s2">"0.1.0"</span>
- <span class="p">},</span>
- <span class="s2">"scripts"</span><span class="o">:</span> <span class="p">{</span>
- <span class="s2">"start"</span><span class="o">:</span> <span class="s2">"react-scripts start"</span><span class="p">,</span>
- <span class="s2">"build"</span><span class="o">:</span> <span class="s2">"react-scripts build"</span><span class="p">,</span>
- <span class="s2">"eject"</span><span class="o">:</span> <span class="s2">"react-scripts eject"</span>
- <span class="p">}</span>
-<span class="p">}</span>
-</code></pre></div>
-<p>We take care of updating Babel, ESLint, and webpack to stable compatible versions so you can update a single dependency to get them all.</p>
-
-<h3>Zero Configuration</h3>
-
-<p>It is worth repeating: there are no configuration files or complicated folder structures. The tool only generates the files you need to build your app.</p>
-<div class="highlight"><pre><code class="language-text" data-lang="text">hello-world/
- README.md
- index.html
- favicon.ico
- node_modules/
- package.json
- src/
- App.css
- App.js
- index.css
- index.js
- logo.svg
-</code></pre></div>
-<p>All the build settings are preconfigured and can’t be changed. Some features, such as testing, are currently missing. This is an intentional limitation, and we recognize it might not work for everybody. And this brings us to the last point.</p>
-
-<h3>No Lock-In</h3>
-
-<p>We first saw this feature in <a href="https://github.com/eanplatter/enclave">Enclave</a>, and we loved it. We talked to <a href="https://twitter.com/EanPlatter">Ean</a>, and he was excited to collaborate with us. He already sent a few pull requests!</p>
-
-<p>“Ejecting” lets you leave the comfort of Create React App setup at any time. You run a single command, and all the build dependencies, configs, and scripts are moved right into your project. At this point you can customize everything you want, but effectively you are forking our configuration and going your own way. If you’re experienced with build tooling and prefer to fine-tune everything to your taste, this lets you use Create React App as a boilerplate generator.</p>
-
-<p>We expect that at early stages, many people will “eject” for one reason or another, but as we learn from them, we will make the default setup more and more compelling while still providing no configuration.</p>
-
-<h2>Try It Out!</h2>
-
-<p>You can find <a href="https://github.com/facebookincubator/create-react-app"><strong>Create React App</strong></a> with additional instructions on GitHub.</p>
-
-<p>This is an experiment, and only time will tell if it becomes a popular way of creating and building React apps, or fades into obscurity.</p>
-
-<p>We welcome you to participate in this experiment. Help us build the React tooling that more people can use. We are always <a href="https://github.com/facebookincubator/create-react-app/issues/11">open to feedback</a>.</p>
-
-<h2>The Backstory</h2>
-
-<p>React was one of the first libraries to embrace transpiling JavaScript. As a result, even though you can <a href="https://github.com/facebook/react/blob/3fd582643ef3d222a00a0c756292c15b88f9f83c/examples/basic-jsx/index.html">learn React without any tooling</a>, the React ecosystem has commonly become associated with an overwhelming explosion of tools.</p>
-
-<p>Eric Clemmons called this phenomenon the “<a href="https://medium.com/@ericclemmons/javascript-fatigue-48d4011b6fc4">JavaScript Fatigue</a>”:</p>
-
-<blockquote>
-<p>Ultimately, the problem is that by choosing React (and inherently JSX), you’ve unwittingly opted into a confusing nest of build tools, boilerplate, linters, & time-sinks to deal with before you ever get to create anything.</p>
-</blockquote>
-
-<p>It is tempting to write code in ES2015 and JSX. It is sensible to use a bundler to keep the codebase modular, and a linter to catch the common mistakes. It is nice to have a development server with fast rebuilds, and a command to produce optimized bundles for production.</p>
-
-<p>Combining these tools requires some experience with each of them. Even so, it is far too easy to get dragged into fighting small incompatibilities, unsatisfied peerDependencies, and illegible configuration files.</p>
-
-<p>Many of those tools are plugin platforms and don’t directly acknowledge each other’s existence. They leave it up to the users to wire them together. The tools mature and change independently, and tutorials quickly get out of date.</p>
-
-<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Marc was almost ready to implement his "hello world" React app <a href="https://t.co/ptdg4yteF1">pic.twitter.com/ptdg4yteF1</a></p>— Thomas Fuchs (@thomasfuchs) <a href="https://twitter.com/thomasfuchs/status/708675139253174273">March 12, 2016</a></blockquote>
-
-<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
-
-<p>This doesn’t mean those tools aren’t great. To many of us, they have become indispensable, and we very much appreciate the effort of their maintainers. They already have too much on their plates to worry about the state of the React ecosystem.</p>
-
-<p>Still, we knew it was frustrating to spend days setting up a project when all you wanted was to learn React. We wanted to fix this.</p>
-
-<h2>Could We Fix This?</h2>
-
-<p>We found ourselves in an unusual dilemma.</p>
-
-<p>So far, <a href="/react/contributing/design-principles.html#dogfooding">our strategy</a> has been to only release the code that we are using at Facebook. This helped us ensure that every project is battle-tested and has clearly defined scope and priorities.</p>
-
-<p>However, tooling at Facebook is different than at many smaller companies. Linting, transpilation, and packaging are all handled by powerful remote development servers, and product engineers don’t need to configure them. While we wish we could give a dedicated server to every user of React, even Facebook cannot scale that well!</p>
-
-<p>The React community is very important to us. We knew that we couldn’t fix the problem within the limits of our open source philosophy. This is why we decided to make an exception, and to ship something that we didn’t use ourselves, but that we thought would be useful to the community.</p>
-
-<h2>The Quest for a React <abbr title="Command Line Interface">CLI</abbr></h2>
-
-<p>Having just attended <a href="http://embercamp.com/">EmberCamp</a> a week ago, I was excited about <a href="https://ember-cli.com/">Ember CLI</a>. Ember users have a great “getting started” experience thanks to a curated set of tools united under a single command-line interface. I have heard similar feedback about <a href="https://github.com/elm-lang/elm-reactor">Elm Reactor</a>.</p>
-
-<p>Providing a cohesive curated experience is valuable by itself, even if the user could in theory assemble those parts themselves. Kathy Sierra <a href="http://seriouspony.com/blog/2013/7/24/your-app-makes-me-fat">explains it best</a>:</p>
-
-<blockquote>
-<p>If your UX asks the user to make <em>choices</em>, for example, even if those choices are both clear and useful, the act of <em>deciding</em> is a cognitive drain. And not just <em>while</em> they’re deciding... even <em>after</em> we choose, an unconscious cognitive background thread is slowly consuming/leaking resources, “Was <em>that</em> the right choice?”</p>
-</blockquote>
-
-<p>I never tried to write a command-line tool for React apps, and neither has <a href="https://twitter.com/vjeux">Christopher</a>. We were chatting on Messenger about this idea, and we decided to work together on it for a week as a hackathon project.</p>
-
-<p>We knew that such projects traditionally haven’t been very successful in the React ecosystem. Christopher told me that multiple “React CLI” projects have started and failed at Facebook. The community tools with similar goals also exist, but so far they have not yet gained enough traction.</p>
-
-<p>Still, we decided it was worth another shot. Christopher and I created a very rough proof of concept on the weekend, and <a href="https://twitter.com/lacker">Kevin</a> soon joined us.</p>
-
-<p>We invited some of the community members to collaborate with us, and we have spent this week working on this tool. We hope that you’ll enjoy using it! <a href="https://github.com/facebookincubator/create-react-app/issues/11">Let us know what you think.</a></p>
-
-<p>We would like to express our gratitude to <a href="https://twitter.com/mxstbr">Max Stoiber</a>, <a href="https://twitter.com/jbscript">Jonny Buchanan</a>, <a href="https://twitter.com/eanplatter">Ean Platter</a>, <a href="https://github.com/tylermcginnis">Tyler McGinnis</a>, <a href="https://github.com/kentcdodds">Kent C. Dodds</a>, and <a href="https://twitter.com/ericclemmons">Eric Clemmons</a> for their early feedback, ideas, and contributions.</p>
-
- 2016-07-22T00:00:00-07:00
- https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html
- https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html
-
-
diff --git a/index.html b/index.html
index 88df801e90..dc3b32bc2c 100644
--- a/index.html
+++ b/index.html
@@ -36,6 +36,7 @@
+
@@ -63,7 +64,7 @@
diff --git a/js/ErrorDecoderComponent.js b/js/ErrorDecoderComponent.js
index 090fb9d151..41d34eb78a 100644
--- a/js/ErrorDecoderComponent.js
+++ b/js/ErrorDecoderComponent.js
@@ -7,8 +7,6 @@
/* global React ReactDOM errorMap:true */
'use strict';
-var _jsxFileName = '_js/ErrorDecoderComponent.js';
-
function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } }
function _possibleConstructorReturn(self, call) { if (!self) { throw new ReferenceError("this hasn't been initialised - super() hasn't been called"); } return call && (typeof call === "object" || typeof call === "function") ? call : self; }
@@ -32,11 +30,7 @@ function urlify(str) {
if (i % 2 === 1) {
segments[i] = React.createElement(
'a',
- { key: i, target: '_blank', href: segments[i], __source: {
- fileName: _jsxFileName,
- lineNumber: 25
- }
- },
+ { key: i, target: '_blank', href: segments[i] },
segments[i]
);
}
@@ -75,42 +69,22 @@ function ErrorResult(props) {
if (!code) {
return React.createElement(
'p',
- {
- __source: {
- fileName: _jsxFileName,
- lineNumber: 61
- }
- },
+ null,
'When you encounter an error, you\'ll receive a link to this page for that specific error and we\'ll show you the full error text.'
);
}
return React.createElement(
'div',
- {
- __source: {
- fileName: _jsxFileName,
- lineNumber: 66
- }
- },
+ null,
React.createElement(
'p',
- {
- __source: {
- fileName: _jsxFileName,
- lineNumber: 67
- }
- },
+ null,
'The full text of the error you just encountered is:'
),
React.createElement(
'code',
- {
- __source: {
- fileName: _jsxFileName,
- lineNumber: 68
- }
- },
+ null,
urlify(errorMsg)
)
);
@@ -153,20 +127,11 @@ var ErrorDecoder = function (_React$Component) {
ErrorDecoder.prototype.render = function render() {
return React.createElement(ErrorResult, {
code: this.state.code,
- msg: this.state.errorMsg,
- __source: {
- fileName: _jsxFileName,
- lineNumber: 98
- }
+ msg: this.state.errorMsg
});
};
return ErrorDecoder;
}(React.Component);
-ReactDOM.render(React.createElement(ErrorDecoder, {
- __source: {
- fileName: _jsxFileName,
- lineNumber: 107
- }
-}), document.querySelector('.error-decoder-container'));
\ No newline at end of file
+ReactDOM.render(React.createElement(ErrorDecoder, null), document.querySelector('.error-decoder-container'));
\ No newline at end of file
diff --git a/js/anchor-links.js b/js/anchor-links.js
index 1b457f8962..c0b84a6785 100644
--- a/js/anchor-links.js
+++ b/js/anchor-links.js
@@ -1,5 +1,3 @@
-"use strict";
-
// Add anchors to headings client-side, which prevents them from showing up
// in RSS feeds. See https://github.com/facebook/react/issues/4124.
(function () {
diff --git a/js/errorMap.js b/js/errorMap.js
index 924db31270..148b08724a 100644
--- a/js/errorMap.js
+++ b/js/errorMap.js
@@ -204,10 +204,10 @@ var errorMap = {
"202": "ReactDOM.render(): Invalid component element. Instead of passing a class like Foo, pass React.createElement(Foo) or .",
"203": "ReactDOM.render(): Invalid component element. This may be caused by unintentionally loading two independent copies of React.",
"204": "ReactDOM.render(): Invalid component element.",
- "205": "renderToStream(): Invalid component element.",
- "206": "renderToStaticStream(): Invalid component element.",
- "207": "ReactDOMServer.renderToStream(): The streaming API is not available in the browser. Use ReactDOMServer.renderToString() instead.",
- "208": "ReactDOMServer.renderToStaticStream(): The streaming API is not available in the browser. Use ReactDOMServer.renderToStaticMarkup() instead.",
+ "205": "renderToNodeStream(): Invalid component element.",
+ "206": "renderToStaticNodeStream(): Invalid component element.",
+ "207": "ReactDOMServer.renderToNodeStream(): The streaming API is not available in the browser. Use ReactDOMServer.renderToString() instead.",
+ "208": "ReactDOMServer.renderToStaticNodeStream(): The streaming API is not available in the browser. Use ReactDOMServer.renderToStaticMarkup() instead.",
"209": "renderToString(): Invalid component element.",
"210": "renderToStaticMarkup(): Invalid component element.",
"211": "Missing injection for fiber findDOMNode",
@@ -232,5 +232,6 @@ var errorMap = {
"230": "_processChildContext is not available in React 16+. This likely means you have multiple copies of React and are attempting to nest a React 15 tree inside a React 16 tree using unstable_renderSubtreeIntoContainer, which isn't supported. Try to make sure you have only one copy of React (and ideally, switch to ReactDOM.unstable_createPortal).",
"231": "Expected `%s` listener to be a function, instead got a value of `%s` type.",
"232": "_processChildContext is not available in React 16+. This likely means you have multiple copies of React and are attempting to nest a React 15 tree inside a React 16 tree using unstable_renderSubtreeIntoContainer, which isn't supported. Try to make sure you have only one copy of React (and ideally, switch to ReactDOM.createPortal).",
- "233": "Unsupported top level event type \"%s\" dispatched"
+ "233": "Unsupported top level event type \"%s\" dispatched",
+ "234": "Event cannot be both direct and bubbling: %s"
};
diff --git a/js/examples/hello.js b/js/examples/hello.js
index 71b5907b52..7372889f07 100644
--- a/js/examples/hello.js
+++ b/js/examples/hello.js
@@ -1,11 +1,4 @@
-'use strict';
-
-var _jsxFileName = '_js/examples/hello.js';
var name = Math.random() > 0.5 ? 'Jane' : 'John';
var HELLO_COMPONENT = ('\nclass HelloMessage extends React.Component {\n render() {\n return
Hello {this.props.name}
;\n }\n}\n\nReactDOM.render(, mountNode);\n').trim();
-ReactDOM.render(React.createElement(ReactPlayground, { codeText: HELLO_COMPONENT, __source: {
- fileName: _jsxFileName,
- lineNumber: 13
- }
-}), document.getElementById('helloExample'));
\ No newline at end of file
+ReactDOM.render(React.createElement(ReactPlayground, { codeText: HELLO_COMPONENT }), document.getElementById('helloExample'));
\ No newline at end of file
diff --git a/js/examples/markdown.js b/js/examples/markdown.js
index ddcac8a45b..4eb2e488da 100644
--- a/js/examples/markdown.js
+++ b/js/examples/markdown.js
@@ -1,10 +1,3 @@
-'use strict';
+var MARKDOWN_COMPONENT = '\nclass MarkdownEditor extends React.Component {\n constructor(props) {\n super(props);\n this.handleChange = this.handleChange.bind(this);\n this.state = {value: \'Type some *markdown* here!\'};\n }\n\n handleChange(e) {\n this.setState({value: e.target.value});\n }\n\n getRawMarkup() {\n var md = new Remarkable();\n return { __html: md.render(this.state.value) };\n }\n\n render() {\n return (\n
\n );\n }\n}\n\nReactDOM.render(, mountNode);\n'.trim();
-ReactDOM.render(React.createElement(ReactPlayground, { codeText: TODO_COMPONENT, __source: {
- fileName: _jsxFileName,
- lineNumber: 56
- }
-}), document.getElementById('todoExample'));
\ No newline at end of file
+ReactDOM.render(React.createElement(ReactPlayground, { codeText: TODO_COMPONENT }), document.getElementById('todoExample'));
\ No newline at end of file
diff --git a/js/html-jsx-lib.js b/js/html-jsx-lib.js
index 8f266c9981..75b1886c53 100644
--- a/js/html-jsx-lib.js
+++ b/js/html-jsx-lib.js
@@ -1,5 +1,3 @@
-'use strict';
-
// Ideally it would be nice to just redirect, but GitHub Pages is very basic and
// lacks that functionality.
console.warn('html-jsx-lib.js has moved to http://reactjs.github.io/react-magic/' + 'htmltojsx.min.js. If using React-Magic, you are no longer required to ' + 'link to this file. Please delete its
+
@@ -63,7 +64,7 @@
@@ -1127,7 +1128,7 @@
// this method has not changed}
-
Then update stepNumber when a new move is made by adding stepNumber: history.length to the state update in Game's handleClick:
+
Then update stepNumber when a new move is made by adding stepNumber: history.length to the state update in Game's handleClick. We'll also update handleClick to be aware of stepNumber when reading the current board state so that you can go back in time then click in the board to create a new entry.:
If you click any move link now, the board should immediately update to show what the game looked like at that time.
-
You may also want to update handleClick to be aware of stepNumber when reading the current board state so that you can go back in time then click in the board to create a new entry. (Hint: It's easiest to .slice() off the extra elements from history at the very top of handleClick.)
Inspect the stack trace produced by the warning. You will find the component definition responsible for the PropTypes direct call. Most likely, the issue is due to third-party PropTypes that wrap React’s PropTypes, for example:
In this case, ThirdPartyPropTypes.deprecated is a wrapper calling React.PropTypes.bool. This pattern by itself is fine, but triggers a false positive because React thinks you are calling PropTypes directly. The next section explains how to fix this problem for a library implementing something like ThirdPartyPropTypes. If it's not a library you wrote, you can file an issue against it.
+
In this case, ThirdPartyPropTypes.deprecated is a wrapper calling PropTypes.bool. This pattern by itself is fine, but triggers a false positive because React thinks you are calling PropTypes directly. The next section explains how to fix this problem for a library implementing something like ThirdPartyPropTypes. If it's not a library you wrote, you can file an issue against it.
Fixing the false positive in third party PropTypes
You are probably here because you got the following error messages:
+
You are probably here because you got one of the following error messages:
+
+
React 16.0.0+
+
+
+
Warning:
+
+
Element ref was specified as a string (myRefName) but no owner was set. You may have multiple copies of React loaded. (details: https://fb.me/react-refs-must-have-owner).
+ React
+ 
