Added more Code Sandbox demo links

content/blog/2018-06-07-you-probably-dont-need-derived-state.md

@@ -120,9 +120,9 @@ We've just made a big improvement. Now our component will no longer erase what w
 
 There is still one subtle problem though, and it's probably easiest to illustrate with an example. Let's say our `EmailInput` component is used inside of an "edit profile" form. The first time the form is rendered, the component will display our email address. Let's say we edited the form (including our email address) but then changed our mind and clicked a "reset" button. At this point, we would expect all form fields to return to their initial values— but the `EmailInput` component **will not be reset**. Do you know why?
 
-The reason for this is that "committed" `props.email` never actually changed in the above scenario. (We never clicked "save".) So when the edit form re-rendered the input, it passed the same email address via props.
+The reason for this is that "committed" `props.email` never actually changed in the above scenario. (We never clicked "save".) So when the edit form re-rendered the input, it passed the same email address via props. ([See demo here.](https://codesandbox.io/s/mz5w04xpz9))
 
-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 email, the input would fail to reset. This is because the prop value passed to the component would be the same for both accounts! 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 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 email, the input would fail to reset. This is because the prop value passed to the component would be the same for both accounts! 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. ([See demo here.](https://codesandbox.io/s/mz2lnkjkrx))
 
 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 data, 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.