Files
react.dev/docs/addons-perf.md
Flarnie Marchan 803e5da950 All doc updates forv15.5 (#9359)
* `react-addons-test-utils` -> `react-dom/test-utils`

Updating all references and docs on the `React.addons.TestUtils` and the
shallow renderer to refer to the correct targets.

Instead of:
```
const React = require('react');

// ...
React.addons.Testutils
// or

const ReactTestUtils = require('react-addons-test-utils');
```
we now show:
```
const ReactTestUtils = require('react-dom/test-utils');
```

And for shallow renderer, instead of:
```
const shallowRenderer = TestUtils.createRenderer();
```

we now show:
```
const shallowRenderer = require('react-test-renderer/shallow');
```

* Update the 'prev' and 'next' attributes of 'add-ons' docs

These flags are used to set arrow links to easily navigate through the
documents. They were wrong or missing in some of the 'add-ons' pages and
this bothered me when manually testing the updates from the previous
commit.

* Update syntax for instantiating shallow renderer

Missed this when updating the docs for the changes to shallow-renderer
in React 15.5.

* Fix pointers in addons docs

Thanks @bvaughn for catching this

* Make example of shallow renderer more consistent

We should show using the same variable names between code samples.

* Make names in example even more consistent

We should use the same variable name for the same thing across examples.
`renderer` -> `shallowRenderer`.

* Update docs to deprecate React<CSS>TransitionGroup

 - removes link to the docs about `ReactCSSTransitionGroup` and
   `ReactTransitionGroup` from the main navigation
 - updates 'prev' and 'next' pointers to skip this page
 - adds deprecation warning to the top of the page
 - remove references to these modules from the packages README
 - updates 'add-ons' main page to list this as a deprecated add-on

* Update `React.createClass` to `createReactClass` in the docs

The `React.createClass` method is being deprecated in favor of
`createReactClass`.

* Remove 'React.createClass' from top level API docs

It no longer makes sense to have a section for the 'createClass' method
in this page, since it won't be available as a top level method on
'React'.

I initially was going to pull the section about 'createClass' into a
separate page to add under 'addons' but it was short and duplicative of
the 'react-without-es6' docs. So I just linked to those.

* Remove *most* `React.PropTypes` from the docs

I am doing the docs for `context` in a separate commit because that case
was a bit less clear-cut.

We will no longer support `React.PropTypes` as a built-in feature of
React, and instead should direct folks to use the `PropTypes` project
that stands alone.

Rather than retaining the `React.PropTypes` examples and just revamping
them to show the use of the stand-alone `PropTypes` library with React,
it makes more sense to direct people to that project and reduce the
perceived API area and complexity of React core. The proper place to
document `PropTypes` is in the README or docs of that project, not in
React docs.

* Update `context` docs to not use `React.PropTypes`

We use `React.PropTypes` to define the `contextType` for the `context`
feature of React. It's unclear how this will work once `React.PropTypes`
is replaced by the external `PropTypes` library. Some options;

a) Deprecate `context`, either in v16 or shortly after. Seems reasonable
based on the intense warnings against using context that we have in the
docs -
https://facebook.github.io/react/docs/context.html#why-not-to-use-context
**Except** that probably some widely used libraries depend on it, like
`React-Router`.

b) Expect users will use external `PropTypes` library when defining
`contextTypes` and just don't do our `checkReactTypeSpec` against them
any more in v16.

c) Stop masking context and pass the whole context
unmasked everywhere. Worst option, do not recommend.

I went with `b` and assume that, for now, we will get users to use the
external `PropTypes` when defining context. I will update this PR if we
want a different approach.

* Remove 'addons' items from left nav, and deprecate 'addons' doc page

The plan:
[X] Remove links to 'addons' items from main navigation
[X] Add deprecation notices where appropriate, and update syntax to show
using the separate modules.
[ ] Update other references to 'React.addons' in docs. Coming in next
commit.
--- blocked but coming in future PRs
[ ] Link to a blog post describing the new locations of add-ons in the
deprecation notice on the '/docs/addons.html' page. Blocked until we
actually publish that blog post.
[ ] Move the docs for each add-on to the actual github repo where it now
lives.
[ ] Redirect the old add-ons doc permalinks to the docs in the separate
github repos for those modules.
[ ] Remove the old add-ons doc markdown files from React core docs.

* Remove references to `React.addons` from docs

Just misc. places where we referenced the 'addons' feature. All gone!
2017-04-06 17:20:54 -07:00

4.4 KiB

id, title, permalink, layout, category
id title permalink layout category
perf Performance Tools docs/perf.html docs Add-Ons

Importing

import Perf from 'react-addons-perf'; // ES6
var Perf = require('react-addons-perf'); // ES5 with npm

Overview

React is usually quite fast out of the box. However, in situations where you need to squeeze every ounce of performance out of your app, it provides a shouldComponentUpdate() hook where you can add optimization hints to React's diff algorithm.

In addition to giving you an overview of your app's overall performance, Perf is a profiling tool that tells you exactly where you need to put these hooks.

See these articles for an introduction to React performance tooling:

Development vs. Production Builds

If you're benchmarking or seeing performance problems in your React apps, make sure you're testing with the minified production build. The development build includes extra warnings that are helpful when building your apps, but it is slower due to the extra bookkeeping it does.

However, the perf tools described on this page only work when using the development build of React. Therefore, the profiler only serves to indicate the relatively expensive parts of your app.

Using Perf

The Perf object can be used with React in development mode only. You should not include this bundle when building your app for production.

Getting Measurements

Printing Results

The following methods use the measurements returned by Perf.getLastMeasurements() to pretty-print the result.


Reference

start()

stop()

Perf.start()
// ...
Perf.stop()

Start/stop the measurement. The React operations in-between are recorded for analyses below. Operations that took an insignificant amount of time are ignored.

After stopping, you will need Perf.getLastMeasurements() to get the measurements.


getLastMeasurements()

Perf.getLastMeasurements()

Get the opaque data structure describing measurements from the last start-stop session. You can save it and pass it to the other print methods in Perf to analyze past measurements.

Note

Don't rely on the exact format of the return value because it may change in minor releases. We will update the documentation if the return value format becomes a supported part of the public API.


printInclusive()

Perf.printInclusive(measurements)

Prints the overall time taken. If no argument's passed, defaults to all the measurements from the last recording. This prints a nicely formatted table in the console, like so:


printExclusive()

Perf.printExclusive(measurements)

"Exclusive" times don't include the times taken to mount the components: processing props, calling componentWillMount and componentDidMount, etc.


printWasted()

Perf.printWasted(measurements)

The most useful part of the profiler.

"Wasted" time is spent on components that didn't actually render anything, e.g. the render stayed the same, so the DOM wasn't touched.


printOperations()

Perf.printOperations(measurements)

Prints the underlying DOM manipulations, e.g. "set innerHTML" and "remove".


printDOM()

Perf.printDOM(measurements)

This method has been renamed to printOperations(). Currently printDOM() still exists as an alias but it prints a deprecation warning and will eventually be removed.