@ -39,7 +39,7 @@ The only method you *must* define in a `React.Component` subclass is called [`re
### The Component Lifecycle {#the-component-lifecycle}
Each component has several "lifecycle methods" that you can override to run code at particular times in the process. **You can use [this lifecycle diagram](http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/) as a cheat sheet.** In the list below, commonly used lifecycle methods are marked as **bold**. The rest of them exist for relatively rare use cases.
Each component has several "lifecycle methods" that you can override to run code at particular times in the process. **You can use [this lifecycle diagram](https://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/) as a cheat sheet.** In the list below, commonly used lifecycle methods are marked as **bold**. The rest of them exist for relatively rare use cases.
#### Mounting {#mounting}
@ -109,7 +109,7 @@ Each component also provides some other APIs:
### Commonly Used Lifecycle Methods {#commonly-used-lifecycle-methods}
The methods in this section cover the vast majority of use cases you'll encounter creating React components. **For a visual reference, check out [this lifecycle diagram](http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/).**
The methods in this section cover the vast majority of use cases you'll encounter creating React components. **For a visual reference, check out [this lifecycle diagram](https://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/).**
### `render()` {#render}
@ -245,7 +245,7 @@ You **should not call `setState()`** in `componentWillUnmount()` because the com
### Rarely Used Lifecycle Methods {#rarely-used-lifecycle-methods}
The methods in this section correspond to uncommon use cases. They're handy once in a while, but most of your components probably don't need any of them. **You can see most of the methods below on [this lifecycle diagram](http://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/) if you click the "Show less common lifecycles" checkbox at the top of it.**
The methods in this section correspond to uncommon use cases. They're handy once in a while, but most of your components probably don't need any of them. **You can see most of the methods below on [this lifecycle diagram](https://projects.wojtekmaj.pl/react-lifecycle-methods-diagram/) if you click the "Show less common lifecycles" checkbox at the top of it.**
This method exists for [rare use cases](/blog/2018/06/07/you-probably-dont-need-derived-state.html#when-to-use-derived-state) where the state depends on changes in props over time. For example, it might be handy for implementing a `<Transition>` component that compares its previous and next children to decide which of them to animate in and out.
Deriving state leads to verbose code and makes your components difficult to think about.
Deriving state leads to verbose code and makes your components difficult to think about.
[Make sure you're familiar with simpler alternatives:](/blog/2018/06/07/you-probably-dont-need-derived-state.html)
* If you need to **perform a side effect** (for example, data fetching or an animation) in response to a change in props, use [`componentDidUpdate`](#componentdidupdate) lifecycle instead.
@ -324,7 +324,7 @@ Only use error boundaries for recovering from unexpected exceptions; **don't try
For more details, see [*Error Handling in React 16*](/blog/2017/07/26/error-handling-in-react-16.html).
> Note
>
>
> Error boundaries only catch errors in the components **below** them in the tree. An error boundary can’t catch an error within itself.
@ -353,7 +353,7 @@ class ErrorBoundary extends React.Component {
return <h1>Something went wrong.</h1>;
}
return this.props.children;
return this.props.children;
}
}
```
@ -408,13 +408,13 @@ class ErrorBoundary extends React.Component {
return <h1>Something went wrong.</h1>;
}
return this.props.children;
return this.props.children;
}
}
```
> Note
>
>
> In the event of an error, you can render a fallback UI with `componentDidCatch()` by calling `setState`, but this will be deprecated in a future release.
> Use `static getDerivedStateFromError()` to handle fallback rendering instead.