React.Component
Components 使你将UI分离为单独地、 可复用的碎块,并且独立考虑每个单独地碎块. React.Component 由 React 提供。
概述
React.Component 是个抽象的基类, 所以它不直接指向 React.Component .然而，你需要继承它，并至少定义 render()方法.
你需要把 react componet 定义为一个JavaScript class
class Greeting extends React.Component {
render() {
return <h1>Hello, {this.props.name}</h1>;
}
}组件生命周期
每个组件有若干个“生命周期方法”，你可以重写它以至于在某些特殊的时间执行某些特殊的代码。以will 前缀的方法会在某个事情发生前的那个瞬间执行，而以 did 前缀的方法会在某个事情发生后的那个瞬间执行。
实例化
这些方法会在组件的一个实例已经创建并且插入到DOM的时候调用：
constructor()static getDerivedStateFromProps()componentWillMount()/UNSAFE_componentWillMount()render()componentDidMount()
存在期
可以由props或state的变化引起的更新。 这些方法会在组件正在被重新渲染时调用:
componentWillReceiveProps()/UNSAFE_componentWillReceiveProps()static getDerivedStateFromProps()shouldComponentUpdate()componentWillUpdate()/UNSAFE_componentWillUpdate()render()getSnapshotBeforeUpdate()componentDidUpdate()
销毁
该方法会在组件正在被移除DOM时调用:
错误处理
该方法会在当组件及其子组件发生错误时被调用.
其它 API
每个组件提供了其它一些API :
类属性
实例属性
Reference
render()
render()
这个 render() 方法是必须的。
When called, it should examine this.props and this.state and return one of the following types:
当它被调用时，它需要检查this.props 和 this.state 并且返回以下类型当中的一种:
- React elements. 通常通过JSX来创建。 可以是原生DOM组件(
<div />)，也可以是用户自定义的复合组件(<MyComponent />). - String and numbers. 这些会在DOM中被当做text node 来渲染.
- Portals. 通过
ReactDOM.createPortal 来创建。 null. 不渲染.- Booleans. Render nothing. (Mostly exists to support
return test && <Child />pattern, wheretestis boolean.)不渲染。（Boolean出现的理由是,当test时boolean是，支持return test && <Child />这种写法）
当返回 null 或者 false时，ReactDOM.findDOMNode(this) 方法会返回null.
render() 函数应该是‘干净’的，也就是说，它不应该修改组件状态、每次被调用时都得返回相同的结果，并且，不应该直接与浏览器交互。 如果想要跟浏览器交互，可以在 componentDidMount()或者其它生命周期方法中完成。 保持‘干净’的 render() 会更好理解。
提示
如果
shouldComponentUpdate()方法返回false,render()不会被调用
代码片段
你可以用一个数组让 render() 返回多个元素:
render() {
return [
<li key="A">First item</li>,
<li key="B">Second item</li>,
<li key="C">Third item</li>,
];
}
提示:
不要忘了在代码里给元素添加key, 否则会有警告。
自从 React 16.2.0, 同样可以用 fragments 来实现了，这样就不需要给静态元素添加key了:
render() {
return (
<React.Fragment>
<li>First item</li>
<li>Second item</li>
<li>Third item</li>
</React.Fragment>
);
}
constructor()
constructor(props)
The constructor for a React component is called before it is mounted. When implementing the constructor for a React.Component subclass, you should call super(props) before any other statement. Otherwise, this.props will be undefined in the constructor, which can lead to bugs.
Avoid introducing any side-effects or subscriptions in the constructor. For those use cases, use componentDidMount() instead.
The constructor is the right place to initialize state. To do so, just assign an object to this.state; don’t try to call setState() from the constructor. The constructor is also often used to bind event handlers to the class instance.
If you don’t initialize state and you don’t bind methods, you don’t need to implement a constructor for your React component.
In rare cases, it’s okay to initialize state based on props. This effectively “forks” the props and sets the state with the initial props. Here’s an example of a valid React.Component subclass constructor:
constructor(props) {
super(props);
this.state = {
color: props.initialColor
};
}
Beware of this pattern, as state won’t be up-to-date with any props update. Instead of syncing props to state, you often want to lift the state up instead.
If you “fork” props by using them for state, you might also want to implement getDerivedStateFromProps() to keep the state up-to-date with them. But lifting state up is often easier and less bug-prone.
static getDerivedStateFromProps()
static getDerivedStateFromProps(nextProps, prevState)
getDerivedStateFromProps is invoked after a component is instantiated as well as when it receives new props. It should return an object to update state, or null to indicate that the new props do not require any state updates.
Note that if a parent component causes your component to re-render, this method will be called even if props have not changed. You may want to compare new and previous values if you only want to handle changes.
Calling this.setState() generally doesn’t trigger getDerivedStateFromProps().
UNSAFE_componentWillMount()
UNSAFE_componentWillMount()
UNSAFE_componentWillMount() is invoked just before mounting occurs. It is called before render(), therefore calling setState() synchronously in this method will not trigger an extra rendering. Generally, we recommend using the constructor() instead for initializing state.
Avoid introducing any side-effects or subscriptions in this method. For those use cases, use componentDidMount() instead.
This is the only lifecycle hook called on server rendering.
Note
This lifecycle was previously named
componentWillMount. That name will continue to work until version 17. Use therename-unsafe-lifecyclescodemod to automatically update your components.
componentDidMount()
componentDidMount()
componentDidMount() is invoked immediately after a component is mounted. Initialization that requires DOM nodes should go here. If you need to load data from a remote endpoint, this is a good place to instantiate the network request.
This method is a good place to set up any subscriptions. If you do that, don’t forget to unsubscribe in componentWillUnmount().
Calling setState() in this method will trigger an extra rendering, but it will happen before the browser updates the screen. This guarantees that even though the render() will be called twice in this case, the user won’t see the intermediate state. Use this pattern with caution because it often causes performance issues. It can, however, be necessary for cases like modals and tooltips when you need to measure a DOM node before rendering something that depends on its size or position.
UNSAFE_componentWillReceiveProps()
UNSAFE_componentWillReceiveProps(nextProps)
Note
It is recommended that you use the static
getDerivedStateFromPropslifecycle instead ofUNSAFE_componentWillReceiveProps. Learn more about this recommendation here.
UNSAFE_componentWillReceiveProps() is invoked before a mounted component receives new props. If you need to update the state in response to prop changes (for example, to reset it), you may compare this.props and nextProps and perform state transitions using this.setState() in this method.
Note that if a parent component causes your component to re-render, this method will be called even if props have not changed. Make sure to compare the current and next values if you only want to handle changes.
React doesn’t call UNSAFE_componentWillReceiveProps() with initial props during mounting. It only calls this method if some of component’s props may update. Calling this.setState()generally doesn’t trigger UNSAFE_componentWillReceiveProps().
Note
This lifecycle was previously named
componentWillReceiveProps. That name will continue to work until version 17. Use therename-unsafe-lifecyclescodemod to automatically update your components.
shouldComponentUpdate()
shouldComponentUpdate(nextProps, nextState)
Use shouldComponentUpdate() to let React know if a component’s output is not affected by the current change in state or props. The default behavior is to re-render on every state change, and in the vast majority of cases you should rely on the default behavior.
shouldComponentUpdate() is invoked before rendering when new props or state are being received. Defaults to true. This method is not called for the initial render or when forceUpdate() is used.
Returning false does not prevent child components from re-rendering when their state changes.
Currently, if shouldComponentUpdate() returns false, then UNSAFE_componentWillUpdate(), render(), and componentDidUpdate() will not be invoked. Note that in the future React may treat shouldComponentUpdate() as a hint rather than a strict directive, and returning false may still result in a re-rendering of the component.
If you determine a specific component is slow after profiling, you may change it to inherit from React.PureComponent which implements shouldComponentUpdate() with a shallow prop and state comparison. If you are confident you want to write it by hand, you may compare this.props with nextProps and this.state with nextState and return false to tell React the update can be skipped.
We do not recommend doing deep equality checks or using JSON.stringify() in shouldComponentUpdate(). It is very inefficient and will harm performance.
UNSAFE_componentWillUpdate()
UNSAFE_componentWillUpdate(nextProps, nextState)
UNSAFE_componentWillUpdate() is invoked just before rendering when new props or state are being received. Use this as an opportunity to perform preparation before an update occurs. This method is not called for the initial render.
Note that you cannot call this.setState() here; nor should you do anything else (e.g. dispatch a Redux action) that would trigger an update to a React component before UNSAFE_componentWillUpdate() returns.
If you need to update state in response to props changes, use getDerivedStateFromProps() instead.
Note
This lifecycle was previously named
componentWillUpdate. That name will continue to work until version 17. Use therename-unsafe-lifecyclescodemod to automatically update your components.
Note
UNSAFE_componentWillUpdate()will not be invoked ifshouldComponentUpdate()returns false.
getSnapshotBeforeUpdate()
getSnapshotBeforeUpdate() is invoked right before the most recently rendered output is committed to e.g. the DOM. It enables your component to capture current values (e.g. scroll position) before they are potentially changed. Any value returned by this lifecycle will be passed as a parameter to componentDidUpdate().
For example:
class ScrollingList extends React.Component {
constructor(props) {
super(props);
this.listRef = React.createRef();
}
getSnapshotBeforeUpdate(prevProps, prevState) {
// Are we adding new items to the list?
// Capture the scroll position so we can adjust scroll later.
if (prevProps.list.length < this.props.list.length) {
const list = this.listRef.current;
return list.scrollHeight - list.scrollTop;
}
return null;
}
componentDidUpdate(prevProps, prevState, snapshot) {
// If we have a snapshot value, we've just added new items.
// Adjust scroll so these new items don't push the old ones out of view.
// (snapshot here is the value returned from getSnapshotBeforeUpdate)
if (snapshot !== null) {
const list = this.listRef.current;
list.scrollTop = list.scrollHeight - snapshot;
}
}
render() {
return (
<div ref={this.listRef}>{/* ...contents... */}</div>
);
}
}
In the above examples, it is important to read the scrollHeight property in getSnapshotBeforeUpdate rather than componentWillUpdate in order to support async rendering. With async rendering, there may be delays between “render” phase lifecycles (like componentWillUpdate and render) and “commit” phase lifecycles (like getSnapshotBeforeUpdate and componentDidUpdate). If a user does something like resize the browser during this time, a scrollHeight value read from componentWillUpdate will be stale.
componentDidUpdate()
componentDidUpdate(prevProps, prevState, snapshot)
componentDidUpdate() is invoked immediately after updating occurs. This method is not called for the initial render.
Use this as an opportunity to operate on the DOM when the component has been updated. This is also a good place to do network requests as long as you compare the current props to previous props (e.g. a network request may not be necessary if the props have not changed).
If your component implements the getSnapshotBeforeUpdate() lifecycle, the value it returns will be passed as a third “snapshot” parameter to componentDidUpdate(). (Otherwise this parameter will be undefined.)
Note
componentDidUpdate()will not be invoked ifshouldComponentUpdate()returns false.
componentWillUnmount()
componentWillUnmount()
componentWillUnmount() is invoked immediately before a component is unmounted and destroyed. Perform any necessary cleanup in this method, such as invalidating timers, canceling network requests, or cleaning up any subscriptions that were created in componentDidMount().
componentDidCatch()
componentDidCatch(error, info)
Error boundaries are React components that catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI instead of the component tree that crashed. Error boundaries catch errors during rendering, in lifecycle methods, and in constructors of the whole tree below them.
A class component becomes an error boundary if it defines this lifecycle method. Calling setState() in it lets you capture an unhandled JavaScript error in the below tree and display a fallback UI. Only use error boundaries for recovering from unexpected exceptions; don’t try to use them for control flow.
For more details, see Error Handling in React 16.
Note
Error boundaries only catch errors in the components below them in the tree. An error boundary can’t catch an error within itself.
setState()
setState(updater[, callback])
setState() enqueues changes to the component state and tells React that this component and its children need to be re-rendered with the updated state. This is the primary method you use to update the user interface in response to event handlers and server responses.
Think of setState() as a request rather than an immediate command to update the component. For better perceived performance, React may delay it, and then update several components in a single pass. React does not guarantee that the state changes are applied immediately.
setState() does not always immediately update the component. It may batch or defer the update until later. This makes reading this.state right after calling setState() a potential pitfall. Instead, use componentDidUpdate or a setState callback (setState(updater, callback)), either of which are guaranteed to fire after the update has been applied. If you need to set the state based on the previous state, read about the updater argument below.
setState() will always lead to a re-render unless shouldComponentUpdate() returns false. If mutable objects are being used and conditional rendering logic cannot be implemented in shouldComponentUpdate(), calling setState() only when the new state differs from the previous state will avoid unnecessary re-renders.
The first argument is an updater function with the signature:
(prevState, props) => stateChange
prevState is a reference to the previous state. It should not be directly mutated. Instead, changes should be represented by building a new object based on the input from prevStateand props. For instance, suppose we wanted to increment a value in state by props.step:
this.setState((prevState, props) => {
return {counter: prevState.counter + props.step};
});
Both prevState and props received by the updater function are guaranteed to be up-to-date. The output of the updater is shallowly merged with prevState.
The second parameter to setState() is an optional callback function that will be executed once setState is completed and the component is re-rendered. Generally we recommend using componentDidUpdate() for such logic instead.
You may optionally pass an object as the first argument to setState() instead of a function:
setState(stateChange[, callback])
This performs a shallow merge of stateChange into the new state, e.g., to adjust a shopping cart item quantity:
this.setState({quantity: 2})
This form of setState() is also asynchronous, and multiple calls during the same cycle may be batched together. For example, if you attempt to increment an item quantity more than once in the same cycle, that will result in the equivalent of:
Object.assign(
previousState,
{quantity: state.quantity + 1},
{quantity: state.quantity + 1},
...
)
Subsequent calls will override values from previous calls in the same cycle, so the quantity will only be incremented once. If the next state depends on the previous state, we recommend using the updater function form, instead:
this.setState((prevState) => {
return {quantity: prevState.quantity + 1};
});
For more detail, see:
- State and Lifecycle guide
- In depth: When and why are
setState()calls batched? - In depth: Why isn’t
this.stateupdated immediately?
forceUpdate()
component.forceUpdate(callback)
By default, when your component’s state or props change, your component will re-render. If your render() method depends on some other data, you can tell React that the component needs re-rendering by calling forceUpdate().
Calling forceUpdate() will cause render() to be called on the component, skipping shouldComponentUpdate(). This will trigger the normal lifecycle methods for child components, including the shouldComponentUpdate() method of each child. React will still only update the DOM if the markup changes.
Normally you should try to avoid all uses of forceUpdate() and only read from this.propsand this.state in render().
Class Properties
defaultProps
defaultProps can be defined as a property on the component class itself, to set the default props for the class. This is used for undefined props, but not for null props. For example:
class CustomButton extends React.Component {
// ...
}
CustomButton.defaultProps = {
color: 'blue'
};
If props.color is not provided, it will be set by default to 'blue':
render() {
return <CustomButton /> ; // props.color will be set to blue
}
If props.color is set to null, it will remain null:
render() {
return <CustomButton color={null} /> ; // props.color will remain null
}
displayName
The displayName string is used in debugging messages. Usually, you don’t need to set it explicitly because it’s inferred from the name of the function or class that defines the component. You might want to set it explicitly if you want to display a different name for debugging purposes or when you create a higher-order component, see Wrap the Display Name for Easy Debugging for details.
Instance Properties
props
this.props contains the props that were defined by the caller of this component. See Components and Props for an introduction to props.
In particular, this.props.children is a special prop, typically defined by the child tags in the JSX expression rather than in the tag itself.
state
The state contains data specific to this component that may change over time. The state is user-defined, and it should be a plain JavaScript object.
If some value isn’t used for rendering or data flow (for example, a timer ID), you don’t have to put it in the state. Such values can be defined as fields on the component instance.
See State and Lifecycle for more information about the state.
Never mutate this.state directly, as calling setState() afterwards may replace the mutation you made. Treat this.state as if it were immutable.
参考： https://reactjs.org/docs/react-component.html#the-component-lifecycle
372
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
