From 0587139252d0cdff702ab5c8ff5adaa7fb48d31d Mon Sep 17 00:00:00 2001 From: Scotty Simpson Date: Thu, 27 Apr 2017 16:49:19 -0700 Subject: [PATCH] docs: Update components.md (#1818) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I went with "its", but "our" could work, too. Both, though — hm. Seems silly. --- docs/components.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/components.md b/docs/components.md index 229f1293..4df9dfe4 100644 --- a/docs/components.md +++ b/docs/components.md @@ -316,7 +316,7 @@ var Login = { Normally, in the context of a larger application, a login component like the one above exists alongside components for user registration and password recovery. Imagine that we want to be able to prepopulate the email field when navigating from the login screen to the registration or password recovery screens (or vice versa), so that the user doesn't need to re-type their email if they happened to fill the wrong page (or maybe you want to bump the user to the registration form if a username is not found). -Right away, we see that sharing the `username` and `password` fields from this component to another is difficult. This is because the fat component encapsulates its our state, which by definition makes this state difficult to access from outside. +Right away, we see that sharing the `username` and `password` fields from this component to another is difficult. This is because the fat component encapsulates its state, which by definition makes this state difficult to access from outside. It makes more sense to refactor this component and pull the state code out of the component and into the application's data layer. This can be as simple as creating a new module: