From 420fc316c5561c72cfea761ec500bc6d9ba64f91 Mon Sep 17 00:00:00 2001 From: Mo Ismat Date: Mon, 9 Mar 2020 20:33:34 +0200 Subject: [PATCH] Update 2018-06-07-you-probably-dont-need-derived-state.md (#1173) Grammar/typo --- content/blog/2018-06-07-you-probably-dont-need-derived-state.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/blog/2018-06-07-you-probably-dont-need-derived-state.md b/content/blog/2018-06-07-you-probably-dont-need-derived-state.md index 6949be3e..6223548e 100644 --- a/content/blog/2018-06-07-you-probably-dont-need-derived-state.md +++ b/content/blog/2018-06-07-you-probably-dont-need-derived-state.md @@ -40,7 +40,7 @@ Problems arise when any of these constraints are changed. This typically comes i A common misconception is that `getDerivedStateFromProps` and `componentWillReceiveProps` are only called when props "change". These lifecycles are called any time a parent component rerenders, regardless of whether the props are "different" from before. Because of this, it has always been unsafe to _unconditionally_ override state using either of these lifecycles. **Doing so will cause state updates to be lost.** -Let’s consider an example to demonstrate the problem. Here is a `EmailInput` component that "mirrors" an email prop in state: +Let’s consider an example to demonstrate the problem. Here is an `EmailInput` component that "mirrors" an email prop in state: ```js class EmailInput extends Component { state = { email: this.props.email };