You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

222 lines
6.0 KiB

---
id: react-without-es6
title: React Without ES6
permalink: docs/react-without-es6.html
---
Normally you would define a React component as a plain JavaScript class:
```javascript
class Greeting extends React.Component {
render() {
return <h1>Hello, {this.props.name}</h1>;
}
}
```
All doc updates forv15.5 (#9359) * `react-addons-test-utils` -&gt; `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(&#39;react&#39;); // ... React.addons.Testutils // or const ReactTestUtils = require(&#39;react-addons-test-utils&#39;); ``` we now show: ``` const ReactTestUtils = require(&#39;react-dom/test-utils&#39;); ``` And for shallow renderer, instead of: ``` const shallowRenderer = TestUtils.createRenderer(); ``` we now show: ``` const shallowRenderer = require(&#39;react-test-renderer/shallow&#39;); ``` * Update the &#39;prev&#39; and &#39;next&#39; attributes of &#39;add-ons&#39; docs These flags are used to set arrow links to easily navigate through the documents. They were wrong or missing in some of the &#39;add-ons&#39; 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` -&gt; `shallowRenderer`. * Update docs to deprecate React&lt;CSS&gt;TransitionGroup - removes link to the docs about `ReactCSSTransitionGroup` and `ReactTransitionGroup` from the main navigation - updates &#39;prev&#39; and &#39;next&#39; pointers to skip this page - adds deprecation warning to the top of the page - remove references to these modules from the packages README - updates &#39;add-ons&#39; 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 &#39;React.createClass&#39; from top level API docs It no longer makes sense to have a section for the &#39;createClass&#39; method in this page, since it won&#39;t be available as a top level method on &#39;React&#39;. I initially was going to pull the section about &#39;createClass&#39; into a separate page to add under &#39;addons&#39; but it was short and duplicative of the &#39;react-without-es6&#39; 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&#39;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&#39;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 &#39;addons&#39; items from left nav, and deprecate &#39;addons&#39; doc page The plan: [X] Remove links to &#39;addons&#39; items from main navigation [X] Add deprecation notices where appropriate, and update syntax to show using the separate modules. [ ] Update other references to &#39;React.addons&#39; 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 &#39;/docs/addons.html&#39; 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 &#39;addons&#39; feature. All gone!
8 years ago
If you don't use ES6 yet, you may use the `create-react-class` module instead:
```javascript
All doc updates forv15.5 (#9359) * `react-addons-test-utils` -&gt; `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(&#39;react&#39;); // ... React.addons.Testutils // or const ReactTestUtils = require(&#39;react-addons-test-utils&#39;); ``` we now show: ``` const ReactTestUtils = require(&#39;react-dom/test-utils&#39;); ``` And for shallow renderer, instead of: ``` const shallowRenderer = TestUtils.createRenderer(); ``` we now show: ``` const shallowRenderer = require(&#39;react-test-renderer/shallow&#39;); ``` * Update the &#39;prev&#39; and &#39;next&#39; attributes of &#39;add-ons&#39; docs These flags are used to set arrow links to easily navigate through the documents. They were wrong or missing in some of the &#39;add-ons&#39; 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` -&gt; `shallowRenderer`. * Update docs to deprecate React&lt;CSS&gt;TransitionGroup - removes link to the docs about `ReactCSSTransitionGroup` and `ReactTransitionGroup` from the main navigation - updates &#39;prev&#39; and &#39;next&#39; pointers to skip this page - adds deprecation warning to the top of the page - remove references to these modules from the packages README - updates &#39;add-ons&#39; 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 &#39;React.createClass&#39; from top level API docs It no longer makes sense to have a section for the &#39;createClass&#39; method in this page, since it won&#39;t be available as a top level method on &#39;React&#39;. I initially was going to pull the section about &#39;createClass&#39; into a separate page to add under &#39;addons&#39; but it was short and duplicative of the &#39;react-without-es6&#39; 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&#39;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&#39;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 &#39;addons&#39; items from left nav, and deprecate &#39;addons&#39; doc page The plan: [X] Remove links to &#39;addons&#39; items from main navigation [X] Add deprecation notices where appropriate, and update syntax to show using the separate modules. [ ] Update other references to &#39;React.addons&#39; 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 &#39;/docs/addons.html&#39; 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 &#39;addons&#39; feature. All gone!
8 years ago
var createReactClass = require('create-react-class');
var Greeting = createReactClass({
render: function() {
return <h1>Hello, {this.props.name}</h1>;
}
});
```
All doc updates forv15.5 (#9359) * `react-addons-test-utils` -&gt; `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(&#39;react&#39;); // ... React.addons.Testutils // or const ReactTestUtils = require(&#39;react-addons-test-utils&#39;); ``` we now show: ``` const ReactTestUtils = require(&#39;react-dom/test-utils&#39;); ``` And for shallow renderer, instead of: ``` const shallowRenderer = TestUtils.createRenderer(); ``` we now show: ``` const shallowRenderer = require(&#39;react-test-renderer/shallow&#39;); ``` * Update the &#39;prev&#39; and &#39;next&#39; attributes of &#39;add-ons&#39; docs These flags are used to set arrow links to easily navigate through the documents. They were wrong or missing in some of the &#39;add-ons&#39; 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` -&gt; `shallowRenderer`. * Update docs to deprecate React&lt;CSS&gt;TransitionGroup - removes link to the docs about `ReactCSSTransitionGroup` and `ReactTransitionGroup` from the main navigation - updates &#39;prev&#39; and &#39;next&#39; pointers to skip this page - adds deprecation warning to the top of the page - remove references to these modules from the packages README - updates &#39;add-ons&#39; 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 &#39;React.createClass&#39; from top level API docs It no longer makes sense to have a section for the &#39;createClass&#39; method in this page, since it won&#39;t be available as a top level method on &#39;React&#39;. I initially was going to pull the section about &#39;createClass&#39; into a separate page to add under &#39;addons&#39; but it was short and duplicative of the &#39;react-without-es6&#39; 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&#39;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&#39;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 &#39;addons&#39; items from left nav, and deprecate &#39;addons&#39; doc page The plan: [X] Remove links to &#39;addons&#39; items from main navigation [X] Add deprecation notices where appropriate, and update syntax to show using the separate modules. [ ] Update other references to &#39;React.addons&#39; 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 &#39;/docs/addons.html&#39; 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 &#39;addons&#39; feature. All gone!
8 years ago
The API of ES6 classes is similar to `createReactClass()` with a few exceptions.
## Declaring Default Props {#declaring-default-props}
All doc updates forv15.5 (#9359) * `react-addons-test-utils` -&gt; `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(&#39;react&#39;); // ... React.addons.Testutils // or const ReactTestUtils = require(&#39;react-addons-test-utils&#39;); ``` we now show: ``` const ReactTestUtils = require(&#39;react-dom/test-utils&#39;); ``` And for shallow renderer, instead of: ``` const shallowRenderer = TestUtils.createRenderer(); ``` we now show: ``` const shallowRenderer = require(&#39;react-test-renderer/shallow&#39;); ``` * Update the &#39;prev&#39; and &#39;next&#39; attributes of &#39;add-ons&#39; docs These flags are used to set arrow links to easily navigate through the documents. They were wrong or missing in some of the &#39;add-ons&#39; 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` -&gt; `shallowRenderer`. * Update docs to deprecate React&lt;CSS&gt;TransitionGroup - removes link to the docs about `ReactCSSTransitionGroup` and `ReactTransitionGroup` from the main navigation - updates &#39;prev&#39; and &#39;next&#39; pointers to skip this page - adds deprecation warning to the top of the page - remove references to these modules from the packages README - updates &#39;add-ons&#39; 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 &#39;React.createClass&#39; from top level API docs It no longer makes sense to have a section for the &#39;createClass&#39; method in this page, since it won&#39;t be available as a top level method on &#39;React&#39;. I initially was going to pull the section about &#39;createClass&#39; into a separate page to add under &#39;addons&#39; but it was short and duplicative of the &#39;react-without-es6&#39; 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&#39;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&#39;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 &#39;addons&#39; items from left nav, and deprecate &#39;addons&#39; doc page The plan: [X] Remove links to &#39;addons&#39; items from main navigation [X] Add deprecation notices where appropriate, and update syntax to show using the separate modules. [ ] Update other references to &#39;React.addons&#39; 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 &#39;/docs/addons.html&#39; 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 &#39;addons&#39; feature. All gone!
8 years ago
With functions and ES6 classes `defaultProps` is defined as a property on the component itself:
```javascript
class Greeting extends React.Component {
// ...
}
Greeting.defaultProps = {
name: 'Mary'
};
```
All doc updates forv15.5 (#9359) * `react-addons-test-utils` -&gt; `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(&#39;react&#39;); // ... React.addons.Testutils // or const ReactTestUtils = require(&#39;react-addons-test-utils&#39;); ``` we now show: ``` const ReactTestUtils = require(&#39;react-dom/test-utils&#39;); ``` And for shallow renderer, instead of: ``` const shallowRenderer = TestUtils.createRenderer(); ``` we now show: ``` const shallowRenderer = require(&#39;react-test-renderer/shallow&#39;); ``` * Update the &#39;prev&#39; and &#39;next&#39; attributes of &#39;add-ons&#39; docs These flags are used to set arrow links to easily navigate through the documents. They were wrong or missing in some of the &#39;add-ons&#39; 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` -&gt; `shallowRenderer`. * Update docs to deprecate React&lt;CSS&gt;TransitionGroup - removes link to the docs about `ReactCSSTransitionGroup` and `ReactTransitionGroup` from the main navigation - updates &#39;prev&#39; and &#39;next&#39; pointers to skip this page - adds deprecation warning to the top of the page - remove references to these modules from the packages README - updates &#39;add-ons&#39; 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 &#39;React.createClass&#39; from top level API docs It no longer makes sense to have a section for the &#39;createClass&#39; method in this page, since it won&#39;t be available as a top level method on &#39;React&#39;. I initially was going to pull the section about &#39;createClass&#39; into a separate page to add under &#39;addons&#39; but it was short and duplicative of the &#39;react-without-es6&#39; 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&#39;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&#39;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 &#39;addons&#39; items from left nav, and deprecate &#39;addons&#39; doc page The plan: [X] Remove links to &#39;addons&#39; items from main navigation [X] Add deprecation notices where appropriate, and update syntax to show using the separate modules. [ ] Update other references to &#39;React.addons&#39; 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 &#39;/docs/addons.html&#39; 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 &#39;addons&#39; feature. All gone!
8 years ago
With `createReactClass()`, you need to define `getDefaultProps()` as a function on the passed object:
```javascript
All doc updates forv15.5 (#9359) * `react-addons-test-utils` -&gt; `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(&#39;react&#39;); // ... React.addons.Testutils // or const ReactTestUtils = require(&#39;react-addons-test-utils&#39;); ``` we now show: ``` const ReactTestUtils = require(&#39;react-dom/test-utils&#39;); ``` And for shallow renderer, instead of: ``` const shallowRenderer = TestUtils.createRenderer(); ``` we now show: ``` const shallowRenderer = require(&#39;react-test-renderer/shallow&#39;); ``` * Update the &#39;prev&#39; and &#39;next&#39; attributes of &#39;add-ons&#39; docs These flags are used to set arrow links to easily navigate through the documents. They were wrong or missing in some of the &#39;add-ons&#39; 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` -&gt; `shallowRenderer`. * Update docs to deprecate React&lt;CSS&gt;TransitionGroup - removes link to the docs about `ReactCSSTransitionGroup` and `ReactTransitionGroup` from the main navigation - updates &#39;prev&#39; and &#39;next&#39; pointers to skip this page - adds deprecation warning to the top of the page - remove references to these modules from the packages README - updates &#39;add-ons&#39; 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 &#39;React.createClass&#39; from top level API docs It no longer makes sense to have a section for the &#39;createClass&#39; method in this page, since it won&#39;t be available as a top level method on &#39;React&#39;. I initially was going to pull the section about &#39;createClass&#39; into a separate page to add under &#39;addons&#39; but it was short and duplicative of the &#39;react-without-es6&#39; 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&#39;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&#39;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 &#39;addons&#39; items from left nav, and deprecate &#39;addons&#39; doc page The plan: [X] Remove links to &#39;addons&#39; items from main navigation [X] Add deprecation notices where appropriate, and update syntax to show using the separate modules. [ ] Update other references to &#39;React.addons&#39; 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 &#39;/docs/addons.html&#39; 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 &#39;addons&#39; feature. All gone!
8 years ago
var Greeting = createReactClass({
getDefaultProps: function() {
return {
name: 'Mary'
};
},
// ...
});
```
## Setting the Initial State {#setting-the-initial-state}
In ES6 classes, you can define the initial state by assigning `this.state` in the constructor:
```javascript
class Counter extends React.Component {
constructor(props) {
super(props);
this.state = {count: props.initialCount};
}
// ...
}
```
All doc updates forv15.5 (#9359) * `react-addons-test-utils` -&gt; `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(&#39;react&#39;); // ... React.addons.Testutils // or const ReactTestUtils = require(&#39;react-addons-test-utils&#39;); ``` we now show: ``` const ReactTestUtils = require(&#39;react-dom/test-utils&#39;); ``` And for shallow renderer, instead of: ``` const shallowRenderer = TestUtils.createRenderer(); ``` we now show: ``` const shallowRenderer = require(&#39;react-test-renderer/shallow&#39;); ``` * Update the &#39;prev&#39; and &#39;next&#39; attributes of &#39;add-ons&#39; docs These flags are used to set arrow links to easily navigate through the documents. They were wrong or missing in some of the &#39;add-ons&#39; 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` -&gt; `shallowRenderer`. * Update docs to deprecate React&lt;CSS&gt;TransitionGroup - removes link to the docs about `ReactCSSTransitionGroup` and `ReactTransitionGroup` from the main navigation - updates &#39;prev&#39; and &#39;next&#39; pointers to skip this page - adds deprecation warning to the top of the page - remove references to these modules from the packages README - updates &#39;add-ons&#39; 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 &#39;React.createClass&#39; from top level API docs It no longer makes sense to have a section for the &#39;createClass&#39; method in this page, since it won&#39;t be available as a top level method on &#39;React&#39;. I initially was going to pull the section about &#39;createClass&#39; into a separate page to add under &#39;addons&#39; but it was short and duplicative of the &#39;react-without-es6&#39; 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&#39;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&#39;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 &#39;addons&#39; items from left nav, and deprecate &#39;addons&#39; doc page The plan: [X] Remove links to &#39;addons&#39; items from main navigation [X] Add deprecation notices where appropriate, and update syntax to show using the separate modules. [ ] Update other references to &#39;React.addons&#39; 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 &#39;/docs/addons.html&#39; 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 &#39;addons&#39; feature. All gone!
8 years ago
With `createReactClass()`, you have to provide a separate `getInitialState` method that returns the initial state:
```javascript
All doc updates forv15.5 (#9359) * `react-addons-test-utils` -&gt; `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(&#39;react&#39;); // ... React.addons.Testutils // or const ReactTestUtils = require(&#39;react-addons-test-utils&#39;); ``` we now show: ``` const ReactTestUtils = require(&#39;react-dom/test-utils&#39;); ``` And for shallow renderer, instead of: ``` const shallowRenderer = TestUtils.createRenderer(); ``` we now show: ``` const shallowRenderer = require(&#39;react-test-renderer/shallow&#39;); ``` * Update the &#39;prev&#39; and &#39;next&#39; attributes of &#39;add-ons&#39; docs These flags are used to set arrow links to easily navigate through the documents. They were wrong or missing in some of the &#39;add-ons&#39; 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` -&gt; `shallowRenderer`. * Update docs to deprecate React&lt;CSS&gt;TransitionGroup - removes link to the docs about `ReactCSSTransitionGroup` and `ReactTransitionGroup` from the main navigation - updates &#39;prev&#39; and &#39;next&#39; pointers to skip this page - adds deprecation warning to the top of the page - remove references to these modules from the packages README - updates &#39;add-ons&#39; 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 &#39;React.createClass&#39; from top level API docs It no longer makes sense to have a section for the &#39;createClass&#39; method in this page, since it won&#39;t be available as a top level method on &#39;React&#39;. I initially was going to pull the section about &#39;createClass&#39; into a separate page to add under &#39;addons&#39; but it was short and duplicative of the &#39;react-without-es6&#39; 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&#39;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&#39;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 &#39;addons&#39; items from left nav, and deprecate &#39;addons&#39; doc page The plan: [X] Remove links to &#39;addons&#39; items from main navigation [X] Add deprecation notices where appropriate, and update syntax to show using the separate modules. [ ] Update other references to &#39;React.addons&#39; 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 &#39;/docs/addons.html&#39; 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 &#39;addons&#39; feature. All gone!
8 years ago
var Counter = createReactClass({
getInitialState: function() {
return {count: this.props.initialCount};
},
// ...
});
```
## Autobinding {#autobinding}
In React components declared as ES6 classes, methods follow the same semantics as regular ES6 classes. This means that they don't automatically bind `this` to the instance. You'll have to explicitly use `.bind(this)` in the constructor:
```javascript
class SayHello extends React.Component {
constructor(props) {
super(props);
this.state = {message: 'Hello!'};
// This line is important!
this.handleClick = this.handleClick.bind(this);
}
handleClick() {
alert(this.state.message);
}
render() {
// Because `this.handleClick` is bound, we can use it as an event handler.
return (
<button onClick={this.handleClick}>
Say hello
</button>
);
}
}
```
All doc updates forv15.5 (#9359) * `react-addons-test-utils` -&gt; `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(&#39;react&#39;); // ... React.addons.Testutils // or const ReactTestUtils = require(&#39;react-addons-test-utils&#39;); ``` we now show: ``` const ReactTestUtils = require(&#39;react-dom/test-utils&#39;); ``` And for shallow renderer, instead of: ``` const shallowRenderer = TestUtils.createRenderer(); ``` we now show: ``` const shallowRenderer = require(&#39;react-test-renderer/shallow&#39;); ``` * Update the &#39;prev&#39; and &#39;next&#39; attributes of &#39;add-ons&#39; docs These flags are used to set arrow links to easily navigate through the documents. They were wrong or missing in some of the &#39;add-ons&#39; 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` -&gt; `shallowRenderer`. * Update docs to deprecate React&lt;CSS&gt;TransitionGroup - removes link to the docs about `ReactCSSTransitionGroup` and `ReactTransitionGroup` from the main navigation - updates &#39;prev&#39; and &#39;next&#39; pointers to skip this page - adds deprecation warning to the top of the page - remove references to these modules from the packages README - updates &#39;add-ons&#39; 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 &#39;React.createClass&#39; from top level API docs It no longer makes sense to have a section for the &#39;createClass&#39; method in this page, since it won&#39;t be available as a top level method on &#39;React&#39;. I initially was going to pull the section about &#39;createClass&#39; into a separate page to add under &#39;addons&#39; but it was short and duplicative of the &#39;react-without-es6&#39; 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&#39;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&#39;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 &#39;addons&#39; items from left nav, and deprecate &#39;addons&#39; doc page The plan: [X] Remove links to &#39;addons&#39; items from main navigation [X] Add deprecation notices where appropriate, and update syntax to show using the separate modules. [ ] Update other references to &#39;React.addons&#39; 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 &#39;/docs/addons.html&#39; 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 &#39;addons&#39; feature. All gone!
8 years ago
With `createReactClass()`, this is not necessary because it binds all methods:
```javascript
All doc updates forv15.5 (#9359) * `react-addons-test-utils` -&gt; `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(&#39;react&#39;); // ... React.addons.Testutils // or const ReactTestUtils = require(&#39;react-addons-test-utils&#39;); ``` we now show: ``` const ReactTestUtils = require(&#39;react-dom/test-utils&#39;); ``` And for shallow renderer, instead of: ``` const shallowRenderer = TestUtils.createRenderer(); ``` we now show: ``` const shallowRenderer = require(&#39;react-test-renderer/shallow&#39;); ``` * Update the &#39;prev&#39; and &#39;next&#39; attributes of &#39;add-ons&#39; docs These flags are used to set arrow links to easily navigate through the documents. They were wrong or missing in some of the &#39;add-ons&#39; 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` -&gt; `shallowRenderer`. * Update docs to deprecate React&lt;CSS&gt;TransitionGroup - removes link to the docs about `ReactCSSTransitionGroup` and `ReactTransitionGroup` from the main navigation - updates &#39;prev&#39; and &#39;next&#39; pointers to skip this page - adds deprecation warning to the top of the page - remove references to these modules from the packages README - updates &#39;add-ons&#39; 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 &#39;React.createClass&#39; from top level API docs It no longer makes sense to have a section for the &#39;createClass&#39; method in this page, since it won&#39;t be available as a top level method on &#39;React&#39;. I initially was going to pull the section about &#39;createClass&#39; into a separate page to add under &#39;addons&#39; but it was short and duplicative of the &#39;react-without-es6&#39; 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&#39;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&#39;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 &#39;addons&#39; items from left nav, and deprecate &#39;addons&#39; doc page The plan: [X] Remove links to &#39;addons&#39; items from main navigation [X] Add deprecation notices where appropriate, and update syntax to show using the separate modules. [ ] Update other references to &#39;React.addons&#39; 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 &#39;/docs/addons.html&#39; 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 &#39;addons&#39; feature. All gone!
8 years ago
var SayHello = createReactClass({
getInitialState: function() {
return {message: 'Hello!'};
},
All doc updates forv15.5 (#9359) * `react-addons-test-utils` -&gt; `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(&#39;react&#39;); // ... React.addons.Testutils // or const ReactTestUtils = require(&#39;react-addons-test-utils&#39;); ``` we now show: ``` const ReactTestUtils = require(&#39;react-dom/test-utils&#39;); ``` And for shallow renderer, instead of: ``` const shallowRenderer = TestUtils.createRenderer(); ``` we now show: ``` const shallowRenderer = require(&#39;react-test-renderer/shallow&#39;); ``` * Update the &#39;prev&#39; and &#39;next&#39; attributes of &#39;add-ons&#39; docs These flags are used to set arrow links to easily navigate through the documents. They were wrong or missing in some of the &#39;add-ons&#39; 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` -&gt; `shallowRenderer`. * Update docs to deprecate React&lt;CSS&gt;TransitionGroup - removes link to the docs about `ReactCSSTransitionGroup` and `ReactTransitionGroup` from the main navigation - updates &#39;prev&#39; and &#39;next&#39; pointers to skip this page - adds deprecation warning to the top of the page - remove references to these modules from the packages README - updates &#39;add-ons&#39; 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 &#39;React.createClass&#39; from top level API docs It no longer makes sense to have a section for the &#39;createClass&#39; method in this page, since it won&#39;t be available as a top level method on &#39;React&#39;. I initially was going to pull the section about &#39;createClass&#39; into a separate page to add under &#39;addons&#39; but it was short and duplicative of the &#39;react-without-es6&#39; 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&#39;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&#39;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 &#39;addons&#39; items from left nav, and deprecate &#39;addons&#39; doc page The plan: [X] Remove links to &#39;addons&#39; items from main navigation [X] Add deprecation notices where appropriate, and update syntax to show using the separate modules. [ ] Update other references to &#39;React.addons&#39; 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 &#39;/docs/addons.html&#39; 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 &#39;addons&#39; feature. All gone!
8 years ago
handleClick: function() {
alert(this.state.message);
},
render: function() {
return (
<button onClick={this.handleClick}>
Say hello
</button>
);
}
});
```
This means writing ES6 classes comes with a little more boilerplate code for event handlers, but the upside is slightly better performance in large applications.
If the boilerplate code is too unattractive to you, you may use [ES2022 Class Properties](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Public_class_fields#public_instance_fields) syntax:
```javascript
class SayHello extends React.Component {
constructor(props) {
super(props);
this.state = {message: 'Hello!'};
}
// Using an arrow here binds the method:
handleClick = () => {
alert(this.state.message);
};
render() {
return (
<button onClick={this.handleClick}>
Say hello
</button>
);
}
}
```
You also have a few other options:
* Bind methods in the constructor.
* Use arrow functions, e.g. `onClick={(e) => this.handleClick(e)}`.
All doc updates forv15.5 (#9359) * `react-addons-test-utils` -&gt; `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(&#39;react&#39;); // ... React.addons.Testutils // or const ReactTestUtils = require(&#39;react-addons-test-utils&#39;); ``` we now show: ``` const ReactTestUtils = require(&#39;react-dom/test-utils&#39;); ``` And for shallow renderer, instead of: ``` const shallowRenderer = TestUtils.createRenderer(); ``` we now show: ``` const shallowRenderer = require(&#39;react-test-renderer/shallow&#39;); ``` * Update the &#39;prev&#39; and &#39;next&#39; attributes of &#39;add-ons&#39; docs These flags are used to set arrow links to easily navigate through the documents. They were wrong or missing in some of the &#39;add-ons&#39; 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` -&gt; `shallowRenderer`. * Update docs to deprecate React&lt;CSS&gt;TransitionGroup - removes link to the docs about `ReactCSSTransitionGroup` and `ReactTransitionGroup` from the main navigation - updates &#39;prev&#39; and &#39;next&#39; pointers to skip this page - adds deprecation warning to the top of the page - remove references to these modules from the packages README - updates &#39;add-ons&#39; 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 &#39;React.createClass&#39; from top level API docs It no longer makes sense to have a section for the &#39;createClass&#39; method in this page, since it won&#39;t be available as a top level method on &#39;React&#39;. I initially was going to pull the section about &#39;createClass&#39; into a separate page to add under &#39;addons&#39; but it was short and duplicative of the &#39;react-without-es6&#39; 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&#39;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&#39;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 &#39;addons&#39; items from left nav, and deprecate &#39;addons&#39; doc page The plan: [X] Remove links to &#39;addons&#39; items from main navigation [X] Add deprecation notices where appropriate, and update syntax to show using the separate modules. [ ] Update other references to &#39;React.addons&#39; 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 &#39;/docs/addons.html&#39; 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 &#39;addons&#39; feature. All gone!
8 years ago
* Keep using `createReactClass`.
## Mixins {#mixins}
>**Note:**
>
>ES6 launched without any mixin support. Therefore, there is no support for mixins when you use React with ES6 classes.
>
>**We also found numerous issues in codebases using mixins, [and don't recommend using them in the new code](/blog/2016/07/13/mixins-considered-harmful.html).**
>
>This section exists only for the reference.
Sometimes very different components may share some common functionality. These are sometimes called [cross-cutting concerns](https://en.wikipedia.org/wiki/Cross-cutting_concern). `createReactClass` lets you use a legacy `mixins` system for that.
One common use case is a component wanting to update itself on a time interval. It's easy to use `setInterval()`, but it's important to cancel your interval when you don't need it anymore to save memory. React provides [lifecycle methods](/docs/react-component.html#the-component-lifecycle) that let you know when a component is about to be created or destroyed. Let's create a simple mixin that uses these methods to provide an easy `setInterval()` function that will automatically get cleaned up when your component is destroyed.
```javascript
var SetIntervalMixin = {
componentWillMount: function() {
this.intervals = [];
},
setInterval: function() {
this.intervals.push(setInterval.apply(null, arguments));
},
componentWillUnmount: function() {
this.intervals.forEach(clearInterval);
}
};
All doc updates forv15.5 (#9359) * `react-addons-test-utils` -&gt; `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(&#39;react&#39;); // ... React.addons.Testutils // or const ReactTestUtils = require(&#39;react-addons-test-utils&#39;); ``` we now show: ``` const ReactTestUtils = require(&#39;react-dom/test-utils&#39;); ``` And for shallow renderer, instead of: ``` const shallowRenderer = TestUtils.createRenderer(); ``` we now show: ``` const shallowRenderer = require(&#39;react-test-renderer/shallow&#39;); ``` * Update the &#39;prev&#39; and &#39;next&#39; attributes of &#39;add-ons&#39; docs These flags are used to set arrow links to easily navigate through the documents. They were wrong or missing in some of the &#39;add-ons&#39; 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` -&gt; `shallowRenderer`. * Update docs to deprecate React&lt;CSS&gt;TransitionGroup - removes link to the docs about `ReactCSSTransitionGroup` and `ReactTransitionGroup` from the main navigation - updates &#39;prev&#39; and &#39;next&#39; pointers to skip this page - adds deprecation warning to the top of the page - remove references to these modules from the packages README - updates &#39;add-ons&#39; 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 &#39;React.createClass&#39; from top level API docs It no longer makes sense to have a section for the &#39;createClass&#39; method in this page, since it won&#39;t be available as a top level method on &#39;React&#39;. I initially was going to pull the section about &#39;createClass&#39; into a separate page to add under &#39;addons&#39; but it was short and duplicative of the &#39;react-without-es6&#39; 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&#39;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&#39;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 &#39;addons&#39; items from left nav, and deprecate &#39;addons&#39; doc page The plan: [X] Remove links to &#39;addons&#39; items from main navigation [X] Add deprecation notices where appropriate, and update syntax to show using the separate modules. [ ] Update other references to &#39;React.addons&#39; 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 &#39;/docs/addons.html&#39; 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 &#39;addons&#39; feature. All gone!
8 years ago
var createReactClass = require('create-react-class');
var TickTock = createReactClass({
mixins: [SetIntervalMixin], // Use the mixin
getInitialState: function() {
return {seconds: 0};
},
componentDidMount: function() {
this.setInterval(this.tick, 1000); // Call a method on the mixin
},
tick: function() {
this.setState({seconds: this.state.seconds + 1});
},
render: function() {
return (
<p>
React has been running for {this.state.seconds} seconds.
</p>
);
}
});
React 18 (#4499) * [18] ReactDOM reference to createRoot/hydrateRoot (#4340) * [18] ReactDOM reference to createRoot/hydrateRoot * Update note about render and hydrate * Match the warning text * s/Render/render * [18] Update ReactDOMClient docs (#4468) * [18] Update ReactDOMClient docs * Remove ReactDOMClient where it&#39;s obvious * Update browser message * Update browser message note * Update based on feedback * Add react-dom/client docs * [18] Upgrade homepage examples (#4469) * [18] Switch code samples to createRoot (#4470) * [18] Switch code samples to createRoot * Feedback fixes * Feedback updates * [18] Use hydrateRoot and root.unmount. (#4473) * [18] Add docs for flushSync (#4474) * [18] Add flushSync to ReactDOM docs * Seb feedback * More Seb feedback * [18] Bump version to 18 (#4478) * [18] Update browser requirements (#4476) * [18] Update browser requirements * Update based on feedback * [18] Add stubs for new API references (#4477) * [18] Add stubs for new API references * Change order/grouping * [18] Redirect outdated Concurrent Mode docs (#4481) * [18] Redirect outdated Concurrent Mode docs * Use Vercel redirects instead * [18] Update versions page (#4482) * [18] Update version page * Fix prettier * [18] Update React.lazy docs (#4483) * [18] Add docs for useSyncExternalStore (#4487) * [18] Add docs for useSyncExternalStore * rm &#34;optional&#34; * [18] Add docs for useInsertionEffect (#4486) * [18] Add docs for useId (#4488) * [18] Add docs for useId * Update based on feedback * Add Strict Effects to Strict Mode (#4362) * Add Strict Effects to Strict Mode * Update with new thinking * [18] Update docs for useEffect timing (#4498) * [18] Add docs for useDeferredValue (#4497) * [18] Update suspense docs for unexpected fallbacks (#4500) * [18] Update suspense docs for unexpected fallbacks * Add inline code block * Feedback fixes * [18] Updated Suspense doc with behavior during SSR and Hydration (#4484) * update wording * wording * update events * Update content/docs/reference-react.md Co-authored-by: Sebastian Silbermann &lt;silbermann.sebastian@gmail.com&gt; * add link to selective hydration * remove some of the implementation details Co-authored-by: Sebastian Silbermann &lt;silbermann.sebastian@gmail.com&gt; * [18] renderToPipeableStream doc (#4485) * new streaming ssr api * add readable stream * code snippets * Rename strict effects / unsafe effects to use the reusable state terminology (#4505) * Add draft of 18 release post * Add links to speaker Twitter profiles * [18] Update upgrade guide * Fix typo in blog title * [18] Blog - add note for react native * [18] Add changelog info to blog posts * Edit Suspense for data fetching section * Update date * [18] Add links * Consistent title case * Update link to merged RFC * [18] Update APIs and links * [18] Add start/useTransition docs (#4479) * [18] Add start/useTransition docs * Updates based on feedback * [18] Generate heading IDs * Add note about Strict Mode * Just frameworks * Reorder, fix content * Typos * Clarify Suspense frameworks section * Revert lost changes that happened when I undo-ed in my editor Co-authored-by: salazarm &lt;salazarm@users.noreply.github.com&gt; Co-authored-by: Sebastian Silbermann &lt;silbermann.sebastian@gmail.com&gt; Co-authored-by: Sebastian Markbåge &lt;sebastian@calyptus.eu&gt; Co-authored-by: Andrew Clark &lt;git@andrewclark.io&gt; Co-authored-by: dan &lt;dan.abramov@gmail.com&gt;
3 years ago
const root = ReactDOM.createRoot(document.getElementById('example'));
root.render(<TickTock />);
```
If a component is using multiple mixins and several mixins define the same lifecycle method (i.e. several mixins want to do some cleanup when the component is destroyed), all of the lifecycle methods are guaranteed to be called. Methods defined on mixins run in the order mixins were listed, followed by a method call on the component.