diff --git a/content/blog/2018-06-07-when-to-use-derived-state.md b/content/blog/2018-06-07-when-to-use-derived-state.md
index 070de583..677c032a 100644
--- a/content/blog/2018-06-07-when-to-use-derived-state.md
+++ b/content/blog/2018-06-07-when-to-use-derived-state.md
@@ -117,7 +117,7 @@ The reason for this is that `props.email` never actually changed in the above sc
 
 This problem could manifest itself even without a "reset" button. For example, imagine a password manager app using the above input component. When navigating between details for two accounts with the same initial email, the input would fail to reset because the prop value passed to the component would be the same! This would be a surprise to the user, as a draft change to one account would appear to affect other accounts that happened to share the same email.
 
-This design is fundamentally flawed, but it's also an easy mistake to make. [I've made it myself.](https://twitter.com/brian_d_vaughn/status/959600888242307072) Fortunately there are two alternatives that work better. The key to both is that **for any piece of state, you need to pick a single component that owns it as the source of truth, and avoid duplicating it in other components.** Let's take a look at each.
+This design is fundamentally flawed, but it's also an easy mistake to make. [I've made it myself.](https://twitter.com/brian_d_vaughn/status/959600888242307072) Fortunately there are two alternatives that work better. The key to both is that **for any piece of state, you need to pick a single component that owns it as the source of truth, and avoid duplicating it in other components.** Let's take a look at each of the alternatives.
 
 #### Alternative 1: Fully controlled component