diff --git a/community/conferences.html b/community/conferences.html index ee8b9fd094..8b2b6dfdf3 100644 --- a/community/conferences.html +++ b/community/conferences.html @@ -88,6 +88,10 @@

March 13-14 in Santa Clara, CA

Website

+

React London 2017 #

+

March 28th at the QEII Centre, London

+ +

Website

ReactEurope 2017 #

May 18th & 19th in Paris, France

diff --git a/docs/handling-events.html b/docs/handling-events.html index 859a39cfd7..bc7c94d38d 100644 --- a/docs/handling-events.html +++ b/docs/handling-events.html @@ -189,7 +189,7 @@ } } -

The problem with this syntax is that a different callback is created each time the LoggingButton renders. In most cases, this is fine. However, if this callback is passed as a prop to lower components, those components might do an extra re-rendering. We generally recommend binding in the constructor to avoid this sort of performance problem.

+

The problem with this syntax is that a different callback is created each time the LoggingButton renders. In most cases, this is fine. However, if this callback is passed as a prop to lower components, those components might do an extra re-rendering. We generally recommend binding in the constructor or using the property initializer syntax, to avoid this sort of performance problem.

diff --git a/docs/higher-order-components.html b/docs/higher-order-components.html index 6b963379fd..13fd361dfd 100644 --- a/docs/higher-order-components.html +++ b/docs/higher-order-components.html @@ -323,7 +323,7 @@

(This same property also allows connect and other enhancer-style HOCs to be used as decorators, an experimental JavaScript proposal.)

-

The compose utility function is provided by many third-party libraries including lodash (as lodash.flowRight), Redux, and Rambda.

+

The compose utility function is provided by many third-party libraries including lodash (as lodash.flowRight), Redux, and Ramda.

Convention: Wrap the Display Name for Easy Debugging #

The container components created by HOCs show up in the React Developer Tools like any other component. To ease debugging, choose a display name that communicates that it's the result of an HOC.

diff --git a/docs/jsx-in-depth.html b/docs/jsx-in-depth.html index 6852506db5..918e1a6bab 100644 --- a/docs/jsx-in-depth.html +++ b/docs/jsx-in-depth.html @@ -309,22 +309,22 @@ }

Functions as Children #

Normally, JavaScript expressions inserted in JSX will evaluate to a string, a React element, or a list of those things. However, props.children works just like any other prop in that it can pass any sort of data, not just the sorts that React knows how to render. For example, if you have a custom component, you could have it take a callback as props.children:

-
function ListOfTenThings() {
+
// Calls the children callback numTimes to produce a repeated component
+function Repeat(props) {
+  let items = [];
+  for (let i = 0; i < props.numTimes; i++) {
+    items.push(props.children(i));
+  }
+  return <div>{items}</div>;
+}
+
+function ListOfTenThings() {
   return (
     <Repeat numTimes={10}>
       {(index) => <div key={index}>This is item {index} in the list</div>}
     </Repeat>
   );
 }
-
-// Calls the children callback numTimes to produce a repeated component
-function Repeat(props) {
-  let items = [];
-  for (let i = 0; i < props.numTimes; i++) {
-    items.push(props.children(i));
-  }
-  return <div>{items}</div>;
-}
 

 
Children passed to a custom component can be anything, as long as that component transforms them into something React can understand before rendering. This usage is not common, but it works if you want to stretch what JSX is capable of.

 
Booleans, Null, and Undefined Are Ignored #

diff --git a/docs/optimizing-performance.html b/docs/optimizing-performance.html
index 7c9ffa27ff..b0723e5cc4 100644
--- a/docs/optimizing-performance.html
+++ b/docs/optimizing-performance.html
@@ -96,6 +96,24 @@
 new webpack.optimize.UglifyJsPlugin()

The development build includes extra warnings that are helpful when building your apps, but it is slower due to the extra bookkeeping it does.

+

Profiling Components with Chrome Timeline #

+

In the development mode, you can visualize how components mount, update, and unmount, using the performance tools in supported browsers. For example:

+ +

React components in Chrome timeline

+ +

To do this in Chrome:

+ +
    +

  1. Load your app with ?react_perf in the query string (for example, http://localhost:3000/?react_perf).

    2. +

  2. Open the Chrome DevTools Timeline tab and press Record.

    3. +

  3. Perform the actions you want to profile. Don't record more than 20 seconds or Chrome might hang.

    4. +

  4. Stop recording.

    5. +

  5. React events will be grouped under the User Timing label.

    6. +
+ +

Note that the numbers are relative so components will render faster in production. Still, this should help you realize when unrelated UI gets updated by mistake, and how deep and how often your UI updates occur.

+ +

Currently Chrome, Edge, and IE are the only browsers supporting this feature, but we use the standard User Timing API so we expect more browsers to add support for it.

Avoid Reconciliation #

React builds and maintains an internal representation of the rendered UI. It includes the React elements you return from your components. This representation lets React avoid creating DOM nodes and accessing existing ones beyond necessity, as that can be slower than operations on JavaScript objects. Sometimes it is referred to as a "virtual DOM", but it works the same way on React Native.

diff --git a/docs/react-api.html b/docs/react-api.html index f56cccdc26..5887995d1d 100644 --- a/docs/react-api.html +++ b/docs/react-api.html @@ -164,7 +164,7 @@

Note

-

React.PureComponent's shouldComponentUpdate() only shallowly compares the objects. If these contain complex data structures, it may produce false-negatives for deeper differences. Only mix into components which have simple props and state, or use forceUpdate() when you know deep data structures have changed. Or, consider using immutable objects to facilitate fast comparisons of nested data.

+

React.PureComponent's shouldComponentUpdate() only shallowly compares the objects. If these contain complex data structures, it may produce false-negatives for deeper differences. Only extend PureComponent when you expect to have simple props and state, or use forceUpdate() when you know deep data structures have changed. Or, consider using immutable objects to facilitate fast comparisons of nested data.

Furthermore, React.PureComponent's shouldComponentUpdate() skips prop updates for the whole component subtree. Make sure all the children components are also "pure".

diff --git a/docs/react-component.html b/docs/react-component.html index 045169a9e1..85c2d53fbb 100644 --- a/docs/react-component.html +++ b/docs/react-component.html @@ -198,7 +198,7 @@

Use shouldComponentUpdate() to let React know if a component's output is not affected by the current change in state or props. The default behavior is to re-render on every state change, and in the vast majority of cases you should rely on the default behavior.

-

shouldComponentUpdate() is invoked before rendering when new props or state are being received. Defaults to true This method is not called for the initial render or when forceUpdate() is used.

+

shouldComponentUpdate() is invoked before rendering when new props or state are being received. Defaults to true. This method is not called for the initial render or when forceUpdate() is used.

Returning false does not prevent child components from re-rendering when their state changes.

diff --git a/docs/refs-and-the-dom.html b/docs/refs-and-the-dom.html index 03b40f8c32..6f563b7e5c 100644 --- a/docs/refs-and-the-dom.html +++ b/docs/refs-and-the-dom.html @@ -114,7 +114,9 @@

React will call the ref callback with the DOM element when the component mounts, and call it with null when it unmounts.

-

Using the ref callback just to set a property on the class is a common pattern for accessing DOM elements. If you are currently using this.refs.myRefName to access refs, we recommend using this pattern instead.

+

Using the ref callback just to set a property on the class is a common pattern for accessing DOM elements. The preferred way is to set the property in the ref callback like in the above example. There is even a shorter way to write it: ref={input => this.textInput = input}.

+ +

If you worked with React before, you might be familiar with an older API where the ref attribute is a string, like "textInput", and the DOM node is accessed as this.refs.textInput. We advise against it because string refs have some issues, are considered legacy, and are likely to be removed in one of the future releases. If you're currently using this.refs.textInput to access refs, we recommend the callback pattern instead.

When the ref attribute is used on a custom component, the ref callback receives the mounted instance of the component as its argument. For example, if we wanted to wrap the CustomTextInput above to simulate it being clicked immediately after mounting:

class AutoFocusTextInput extends React.Component {
@@ -154,6 +156,8 @@
 }

Don't Overuse Refs #

Your first inclination may be 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. See the Lifting State Up guide for examples of this.

+

Caveats #

+

If the ref callback is defined as an inline function, it will get called twice during updates, first with null and then again with the DOM element. This is because a new instance of the function is created with each render, so React needs to clear the old ref and set up the new one. You can avoid this by defining the ref callback as a bound method on the class, but note that it shouldn't matter in most cases.

diff --git a/docs/typechecking-with-proptypes.html b/docs/typechecking-with-proptypes.html index 861bb7dbe3..3d69e8dce6 100644 --- a/docs/typechecking-with-proptypes.html +++ b/docs/typechecking-with-proptypes.html @@ -172,7 +172,7 @@ } }) }; -

Requiring Single Children #

+

Requiring Single Child #

With React.PropTypes.element you can specify that only a single child can be passed to a component as children.

class MyComponent extends React.Component {
   render() {