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.

241 lines
7.4 KiB

---
id: typechecking-with-proptypes
title: Typechecking With PropTypes
permalink: docs/typechecking-with-proptypes.html
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!
8 years ago
redirect_from:
- "docs/react-api.html#typechecking-with-proptypes"
---
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!
8 years ago
> Note:
>
> `React.PropTypes` has moved into a different package since React v15.5. Please use [the `prop-types` library instead](https://www.npmjs.com/package/prop-types).
>
>We provide [a codemod script](/blog/2017/04/07/react-v15.5.0.html#migrating-from-reactproptypes) to automate the conversion.
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!
8 years ago
As your app grows, you can catch a lot of bugs with typechecking. For some applications, you can use JavaScript extensions like [Flow](https://flow.org/) or [TypeScript](https://www.typescriptlang.org/) to typecheck your whole application. But even if you don't use those, React has some built-in typechecking abilities. To run typechecking on the props for a component, you can assign the special `propTypes` property:
```javascript
import PropTypes from 'prop-types';
class Greeting extends React.Component {
render() {
return (
<h1>Hello, {this.props.name}</h1>
);
}
}
Greeting.propTypes = {
name: PropTypes.string
};
```
In this example, we are using a class component, but the same functionality could also be applied to function components, or components created by [`React.memo`](/docs/react-api.html#reactmemo) or [`React.forwardRef`](/docs/react-api.html#reactforwardref).
`PropTypes` exports a range of validators that can be used to make sure the data you receive is valid. In this example, we're using `PropTypes.string`. When an invalid value is provided for a prop, a warning will be shown in the JavaScript console. For performance reasons, `propTypes` is only checked in development mode.
### PropTypes {#proptypes}
Here is an example documenting the different validators provided:
```javascript
import PropTypes from 'prop-types';
MyComponent.propTypes = {
// You can declare that a prop is a specific JS type. By default, these
// are all optional.
optionalArray: PropTypes.array,
optionalBool: PropTypes.bool,
optionalFunc: PropTypes.func,
optionalNumber: PropTypes.number,
optionalObject: PropTypes.object,
optionalString: PropTypes.string,
optionalSymbol: PropTypes.symbol,
// Anything that can be rendered: numbers, strings, elements or an array
// (or fragment) containing these types.
optionalNode: PropTypes.node,
// A React element.
optionalElement: PropTypes.element,
// A React element type (ie. MyComponent).
optionalElementType: PropTypes.elementType,
// You can also declare that a prop is an instance of a class. This uses
// JS's instanceof operator.
optionalMessage: PropTypes.instanceOf(Message),
// You can ensure that your prop is limited to specific values by treating
// it as an enum.
optionalEnum: PropTypes.oneOf(['News', 'Photos']),
// An object that could be one of many types
optionalUnion: PropTypes.oneOfType([
PropTypes.string,
PropTypes.number,
PropTypes.instanceOf(Message)
]),
// An array of a certain type
optionalArrayOf: PropTypes.arrayOf(PropTypes.number),
// An object with property values of a certain type
optionalObjectOf: PropTypes.objectOf(PropTypes.number),
// An object taking on a particular shape
optionalObjectWithShape: PropTypes.shape({
color: PropTypes.string,
fontSize: PropTypes.number
}),
// An object with warnings on extra properties
optionalObjectWithStrictShape: PropTypes.exact({
name: PropTypes.string,
quantity: PropTypes.number
}),
// You can chain any of the above with `isRequired` to make sure a warning
// is shown if the prop isn't provided.
requiredFunc: PropTypes.func.isRequired,
// A required value of any data type
requiredAny: PropTypes.any.isRequired,
// You can also specify a custom validator. It should return an Error
// object if the validation fails. Don't `console.warn` or throw, as this
// won't work inside `oneOfType`.
customProp: function(props, propName, componentName) {
if (!/matchme/.test(props[propName])) {
return new Error(
'Invalid prop `' + propName + '` supplied to' +
' `' + componentName + '`. Validation failed.'
);
}
},
// You can also supply a custom validator to `arrayOf` and `objectOf`.
// It should return an Error object if the validation fails. The validator
// will be called for each key in the array or object. The first two
// arguments of the validator are the array or object itself, and the
// current item's key.
customArrayProp: PropTypes.arrayOf(function(propValue, key, componentName, location, propFullName) {
if (!/matchme/.test(propValue[key])) {
return new Error(
'Invalid prop `' + propFullName + '` supplied to' +
' `' + componentName + '`. Validation failed.'
);
}
})
};
```
### Requiring Single Child {#requiring-single-child}
With `PropTypes.element` you can specify that only a single child can be passed to a component as children.
```javascript
import PropTypes from 'prop-types';
class MyComponent extends React.Component {
render() {
// This must be exactly one element or it will warn.
const children = this.props.children;
return (
<div>
{children}
</div>
);
}
}
MyComponent.propTypes = {
children: PropTypes.element.isRequired
};
```
### Default Prop Values {#default-prop-values}
You can define default values for your `props` by assigning to the special `defaultProps` property:
```javascript
class Greeting extends React.Component {
render() {
return (
<h1>Hello, {this.props.name}</h1>
);
}
}
// Specifies the default values for props:
Greeting.defaultProps = {
name: 'Stranger'
};
// Renders "Hello, Stranger":
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(<Greeting />);
```
Since ES2022 you can also declare `defaultProps` as static property within a React component class. For more information, see the [class public static fields](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Public_class_fields#public_static_fields). This modern syntax will require a compilation step to work within older browsers.
```javascript
class Greeting extends React.Component {
static defaultProps = {
name: 'stranger'
}
render() {
return (
<div>Hello, {this.props.name}</div>
)
}
}
```
The `defaultProps` will be used to ensure that `this.props.name` will have a value if it was not specified by the parent component. The `propTypes` typechecking happens after `defaultProps` are resolved, so typechecking will also apply to the `defaultProps`.
### Function Components {#function-components}
If you are using function components in your regular development, you may want to make some small changes to allow PropTypes to be properly applied.
Let's say you have a component like this:
```javascript
export default function HelloWorldComponent({ name }) {
return (
<div>Hello, {name}</div>
)
}
```
To add PropTypes, you may want to declare the component in a separate function before exporting, like this:
```javascript
function HelloWorldComponent({ name }) {
return (
<div>Hello, {name}</div>
)
}
export default HelloWorldComponent
```
Then, you can add PropTypes directly to the `HelloWorldComponent`:
```javascript
import PropTypes from 'prop-types'
function HelloWorldComponent({ name }) {
return (
<div>Hello, {name}</div>
)
}
HelloWorldComponent.propTypes = {
name: PropTypes.string
}
export default HelloWorldComponent
```