.gitignore

@@ -24,3 +24,4 @@ chrome-user-data
 *.sublime-workspace
 .idea
 *.iml
+.vscode

CHANGELOG.md

@@ -1,4 +1,14 @@
-## 0.14.6 (January 6, 2015)
+## 0.14.7 (January 28, 2016)
+
+### React
+- Fixed bug with `<option>` tags when using `dangerouslySetInnerHTML`
+- Fixed memory leak in synthetic event system
+
+### React TestUtils Add-on
+- Fixed bug with calling `setState` in `componentWillMount` when using shallow rendering
+
+
+## 0.14.6 (January 6, 2016)
 
 ### React
 - Updated `fbjs` dependency to pick up change affecting handling of undefined document.

README.md

@@ -37,12 +37,12 @@ The fastest way to get started is to serve JavaScript from the CDN (also availab
 
 ```html
 <!-- The core React library -->
-<script src="https://fb.me/react-0.14.6.js"></script>
+<script src="https://fb.me/react-0.14.7.js"></script>
 <!-- The ReactDOM Library -->
-<script src="https://fb.me/react-dom-0.14.6.js"></script>
+<script src="https://fb.me/react-dom-0.14.7.js"></script>
 ```
 
-We've also built a [starter kit](https://facebook.github.io/react/downloads/react-0.14.6.zip) which might be useful if this is your first time using React. It includes a webpage with an example of using React with live code.
+We've also built a [starter kit](https://facebook.github.io/react/downloads/react-0.14.7.zip) which might be useful if this is your first time using React. It includes a webpage with an example of using React with live code.
 
 If you'd like to use [bower](http://bower.io), it's as easy as:
 

docs/_config.yml

@@ -2,9 +2,9 @@
 name: React
 description: A JavaScript library for building user interfaces
 url: https://facebook.github.io
-baseurl: /react
-permalink: /blog/:year/:month/:day/:title.html
-paginate_path: /blog/page:num/
+baseurl: "/react"
+permalink: "/blog/:year/:month/:day/:title.html"
+paginate_path: "/blog/page:num/"
 relative_permalinks: true
 paginate: 5
 timezone: America/Los_Angeles
@@ -36,4 +36,4 @@ sass:
   sass_dir: _css
 gems:
 - jekyll-redirect-from
-react_version: 0.14.5
+react_version: 0.14.6

docs/_posts/2016-01-08-A-implies-B-does-not-imply-B-implies-A.md

@@ -0,0 +1,60 @@
+---
+title: "(A => B) !=> (B => A)"
+author: jimfb
+---
+
+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:
+
+
+```js
+class Component extends React.Component {
+  componentWillReceiveProps(nextProps) {
+    console.log('componentWillReceiveProps', nextProps.data.bar);
+  }
+  render() {
+    return <div>Bar {this.props.data.bar}!</div>;
+  }
+}
+
+var container = document.getElementById('container');
+
+var mydata = {bar: 'drinks'};
+ReactDOM.render(<Component data={mydata} />, container);
+ReactDOM.render(<Component data={mydata} />, container);
+ReactDOM.render(<Component data={mydata} />, container);
+```
+
+
+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:
+
+```js
+var mydata = {bar: 'drinks'};
+ReactDOM.render(<Component data={mydata} />, container);
+mydata.bar = 'food'
+ReactDOM.render(<Component data={mydata} />, container);
+mydata.bar = 'noise'
+ReactDOM.render(<Component data={mydata} />, container);
+```
+
+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.
+
+

docs/_posts/2016-01-12-discontinuing-ie8-support.md

@@ -0,0 +1,10 @@
+---
+title: "Discontinuing IE 8 Support in React DOM"
+author: spicyj
+---
+
+Since its 2013 release, React has supported all popular browsers, including Internet Explorer 8 and above. We handle normalizing many quirks present in old browser versions, including event system differences, so that your app code doesn't have to worry about most browser bugs.
+
+Today, Microsoft [discontinued support for older versions of IE](https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support). Starting with React v15, we're discontinuing React DOM's support for IE 8. We've heard that most React DOM apps already don't support old versions of Internet Explorer, so this shouldn't affect many people. This change will help us develop faster and make React DOM even better. (We won't actively remove IE 8–related code quite yet, but we will deprioritize new bugs that are reported. If you need to support IE 8 we recommend you stay on React v0.14.)
+
+React DOM will continue to support IE 9 and above for the foreseeable future.

docs/css/react.scss

@@ -409,6 +409,7 @@ h1, h2, h3, h4, h5, h6 {
   .playgroundPreview {
     padding: 0;
     width: 600px;
+    word-wrap: break-word;
 
     pre {
       @include code-typography;

docs/docs/03-interactivity-and-dynamic-uis.md

@@ -36,7 +36,7 @@ ReactDOM.render(
 
 ## Event Handling and Synthetic Events
 
-With React you simply pass your event handler as a camelCased prop similar to how you'd do it in normal HTML. React ensures that all events behave identically in IE8 and above by implementing a synthetic event system. That is, React knows how to bubble and capture events according to the spec, and the events passed to your event handler are guaranteed to be consistent with [the W3C spec](http://www.w3.org/TR/DOM-Level-3-Events/), regardless of which browser you're using.
+With React you simply pass your event handler as a camelCased prop similar to how you'd do it in normal HTML. React ensures that all events behave similarly in all browsers by implementing a synthetic event system. That is, React knows how to bubble and capture events according to the spec, and the events passed to your event handler are guaranteed to be consistent with [the W3C spec](http://www.w3.org/TR/DOM-Level-3-Events/), regardless of which browser you're using.
 
 ## Under the Hood: Autobinding and Event Delegation
 

docs/docs/05-reusable-components.md

@@ -254,4 +254,4 @@ However, you may still specify `.propTypes` and `.defaultProps` by setting them
 >
 > Because stateless functions don't have a backing instance, you can't attach a ref to a stateless function component. Normally this isn't an issue, since stateless functions do not provide an imperative API. Without an imperative API, there isn't much you could do with an instance anyway. However, if a user wants to find the DOM node of a stateless function component, they must wrap the component in a stateful component (eg. ES6 class component) and attach the ref to the stateful wrapper component.
 
-In an ideal world, most of your components would be stateless functions because these stateless components can follow a faster code path within the React core. This is the recommended pattern, when possible.
+In an ideal world, most of your components would be stateless functions because in the future we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations. This is the recommended pattern, when possible.

docs/docs/07-forms.md

@@ -95,7 +95,7 @@ If you want to initialize the component with a non-empty value, you can supply a
 
 This example will function much like the **Uncontrolled Components** example above.
 
-Likewise, `<input>` supports `defaultChecked` and `<select>` supports `defaultValue`.
+Likewise, `<input type="checkbox">` and `<input type="radio">` support `defaultChecked`, and `<select>` supports `defaultValue`.
 
 > Note:
 >

docs/docs/08-working-with-the-browser.md

@@ -12,7 +12,7 @@ React provides powerful abstractions that free you from touching the DOM directl
 
 React is very fast because it never talks to the DOM directly. React maintains a fast in-memory representation of the DOM. `render()` methods actually return a *description* of the DOM, and React can compare this description with the in-memory representation to compute the fastest way to update the browser.
 
-Additionally, React implements a full synthetic event system such that all event objects are guaranteed to conform to the W3C spec despite browser quirks, and everything bubbles consistently and efficiently across browsers. You can even use some HTML5 events in IE8!
+Additionally, React implements a full synthetic event system such that all event objects are guaranteed to conform to the W3C spec despite browser quirks, and everything bubbles consistently and efficiently across browsers. You can even use some HTML5 events in older browsers that don't ordinarily support them!
 
 Most of the time you should stay within React's "faked browser" world since it's more performant and easier to reason about. However, sometimes you simply need to access the underlying API, perhaps to work with a third-party library like a jQuery plugin. React provides escape hatches for you to use the underlying DOM API directly.
 
@@ -53,45 +53,8 @@ _Mounted_ composite components also support the following method:
 
 * `component.forceUpdate()` can be invoked on any mounted component when you know that some deeper aspect of the component's state has changed without using `this.setState()`.
 
-## Browser Support and Polyfills
+## Browser Support
 
-At Facebook, we support older browsers, including IE8. We've had polyfills in place for a long time to allow us to write forward-thinking JS. This means we don't have a bunch of hacks scattered throughout our codebase and we can still expect our code to "just work". For example, instead of seeing `+new Date()`, we can just write `Date.now()`. Since the open source React is the same as what we use internally, we've carried over this philosophy of using forward thinking JS.
+React supports most popular browsers, including Internet Explorer 9 and above.
 
-In addition to that philosophy, we've also taken the stance that we, as authors of a JS library, should not be shipping polyfills as a part of our library. If every library did this, there's a good chance you'd be sending down the same polyfill multiple times, which could be a sizable chunk of dead code. If your product needs to support older browsers, chances are you're already using something like [es5-shim](https://github.com/es-shims/es5-shim).
-
-### Polyfills Needed to Support Older Browsers
-
-`es5-shim.js` from [kriskowal's es5-shim](https://github.com/es-shims/es5-shim) provides the following that React needs:
-
-* `Array.isArray`
-* `Array.prototype.every`
-* `Array.prototype.forEach`
-* `Array.prototype.indexOf`
-* `Array.prototype.map`
-* `Date.now`
-* `Function.prototype.bind`
-* `Object.keys`
-* `String.prototype.split`
-* `String.prototype.trim`
-
-`es5-sham.js`, also from [kriskowal's es5-shim](https://github.com/es-shims/es5-shim), provides the following that React needs:
-
-* `Object.create`
-* `Object.freeze`
-
-The unminified build of React needs the following from [paulmillr's console-polyfill](https://github.com/paulmillr/console-polyfill).
-
-* `console.*`
-
-When using HTML5 elements in IE8 including `<section>`, `<article>`, `<nav>`, `<header>`, and `<footer>`, it's also necessary to include [html5shiv](https://github.com/aFarkas/html5shiv) or a similar script.
-
-### Cross-browser Issues
-
-Although React is pretty good at abstracting browser differences, some browsers are limited or present quirky behaviors that we couldn't find a workaround for.
-
-#### onScroll event on IE8
-
-On IE8 the `onScroll` event doesn't bubble and IE8 doesn't have an API to define handlers to the capturing phase of an event, meaning there is no way for React to listen to these events.
-Currently a handler to this event is ignored on IE8.
-
-See the [onScroll doesn't work in IE8](https://github.com/facebook/react/issues/631) GitHub issue for more information.
+(We don't support older browsers that don't support ES5 methods, but you may find that your apps do work in older browsers if polyfills such as [es5-shim and es5-sham](https://github.com/es-shims/es5-shim) are included in the page. You're on your own if you choose to take this path.)

docs/docs/08.1-more-about-refs.md

@@ -91,11 +91,13 @@ In order to get a reference to a React component, you can either use `this` to g
 var MyComponent = React.createClass({
   handleClick: function() {
     // Explicitly focus the text input using the raw DOM API.
-    this.myTextInput.focus();
+    if (this.myTextInput !== null) {
+      this.myTextInput.focus();
+    }
   },
   render: function() {
-    // The ref attribute adds a reference to the component to
-    // this.refs when the component is mounted.
+    // The ref attribute is a callback that saves a reference to the
+    // component to this.myTextInput when the component is mounted.
     return (
       <div>
         <input type="text" ref={(ref) => this.myTextInput = ref} />
@@ -131,7 +133,7 @@ Refs are a great way to send a message to a particular child instance in a way t
 
 ### Cautions:
 
-- *Never* access refs inside of any component's render method - or while any component's render method is even running anywhere in the call stack.
+- *Never* access refs inside of any component's render method – or while any component's render method is even running anywhere in the call stack.
 - If you want to preserve Google Closure Compiler advanced-mode crushing resilience, make sure to never access as a property what was specified as a string. This means you must access using `this.refs['myRefString']` if your ref was defined as `ref="myRefString"`.
-- If you have not programmed several apps with React, your first inclination is usually going to be to try to use refs to "make things happen" in your app. If this is the case, take a moment and think more critically about where `state` should be owned in the component hierarchy. Often, it becomes clear that the proper place to "own" that state is at a higher level in the hierarchy. Placing the state there often eliminates any desire to use `ref`s to "make things happen" – instead, the data flow will usually accomplish your goal.
+- If you have not programmed several apps with React, your first inclination is usually going to be to try to use refs to "make things happen" in your app. If this is the case, take a moment and think more critically about where state should be owned in the component hierarchy. Often, it becomes clear that the proper place to "own" that state is at a higher level in the hierarchy. Placing the state there often eliminates any desire to use `ref`s to "make things happen" – instead, the data flow will usually accomplish your goal.
 - Refs may not be attached to a [stateless function](/react/docs/reusable-components.html#stateless-functions), because the component does not have a backing instance. You can always wrap a stateless component in a standard composite component and attach a ref to the composite component.

docs/docs/10-addons.md

@@ -18,7 +18,7 @@ The React add-ons are a collection of useful utility modules for building React
 
 The add-ons below are in the development (unminified) version of React only:
 
-- [`TestUtils`](test-utils.html), simple helpers for writing test cases (unminified build only).
-- [`Perf`](perf.html), for measuring performance and giving you hint where to optimize.
+- [`TestUtils`](test-utils.html), simple helpers for writing test cases.
+- [`Perf`](perf.html), a performance profiling tool for finding optimization opportunities.
 
 To get the add-ons, install them individually from npm (e.g., `npm install react-addons-pure-render-mixin`). We don't support using the addons if you're not using npm.

docs/docs/10.10-shallow-compare.zh-CN.md

@@ -0,0 +1,32 @@
+---
+id: shallow-compare-zh-CN
+title: 浅比较
+permalink: shallow-compare-zh-CN.html
+prev: perf-zh-CN.html
+next: advanced-performance-zh-CN.html
+---
+
+`shallowCompare` 是一个辅助函数 在以ES6类使用React时，完成和 `PureRenderMixin` 相同的功能。
+
+如果你的React组件的绘制函数是 “干净的” （换句话说，它在给定的 props 和 state 下绘制相同的结果）,你可以使用这个辅助函数以在某些情况下提升性能。
+
+例如:
+
+```js
+var shallowCompare = require('react-addons-shallow-compare');
+export class SampleComponent extends React.Component {
+  shouldComponentUpdate(nextProps, nextState) {
+    return shallowCompare(this, nextProps, nextState);
+  }
+
+  render() {
+    return <div className={this.props.className}>foo</div>;
+  }
+}
+```
+
+`shallowCompare` 对当前的 `props` 和 `nextProps`对象 执行一个浅的相等检查，同样对于 `state` 和 `nextState`对象。
+它 通过迭代比较对象的keys 并在 对象的key值不严格相等时返回false 实现此功能.
+
+`shallowCompare` 返回 `true` 如果对 props 或 state的浅比较失败，因此组件应该更新。
+`shallowCompare` 返回 `false` 如果对 props 或 state的浅比较都通过了，因此组件不应该更新。