Mapping the Component Structure

The first step will be to break the app into components. 0:00 Then we'll think about how those components should connect to each other. 0:03 This will give us an idea of where its state should be. 0:06 Remember state is all the data we want to track in an app. 0:08 So when the user does any action, like type in a form, or check a box, 0:12 they are changing the state of the application. 0:17 And those changes will need to be stored as data somewhere. 0:21 As that data changes different components of the app will update what they 0:24 show to the user. 0:29 For example, when the user types a name into the main form of the app, 0:30 the app state changes to contain the string being typed. 0:35 And as that state changes, 0:40 the ghost component below updates itself with those changes. 0:42 So the components of the app need access to this state to perform these changes. 0:47 So we need to plan how they fit together to make this access efficient. 0:51 The best way to understand the component structure will be to look at what parts of 0:56 the app a user interacts with and how the app should respond as its state changes. 1:01 Anything the user will click or type in will likely be a component, 1:07 as well as anything that changes. 1:11 So let's start by looking at the app when it loads. 1:13 And I'll draw rectangles around the different pieces of 1:15 the user interface as we go. 1:19 So first, we know we'll need a component to contain the entire app. 1:21 So let's put a border around the whole thing. 1:25 And the first thing a user will interact with is this form. 1:29 So I'll draw a box around that. 1:31 And the counter is another component because it will need to update 1:35 itself as the state changes. 1:38 For example, when users submit new guests, delete guests, 1:39 check them confirmed and so on. 1:44 And the filter we check to hide unconfirmed guests will 1:46 also be a component. 1:50 And there are some hidden components we still need to find. 1:52 So let's add some names to the list. 1:59 And now we can see there are three new components, the name tiles. 2:03 And inside there are other parts that can change or accept user interaction. 2:07 Each one would contain four components. 2:12 We have the name, confirmed, check box and the two buttons, edit and remove. 2:14 Now it might seem that we've found all of the components now, but 2:19 there are actually a couple more. 2:23 Can you think of what they might be? 2:25 Well if I start typing a new name, there's this, what I like to call a ghost tile 2:27 that shows up indicating that there's a pending name for the list. 2:31 That will be a component too, because it shows or 2:36 hides itself depending on whether there is text in the form above. 2:38 It also updates itself with the text from the form. 2:42 So think about each of these name tiles here. 2:46 They are all really just the same component with different data or 2:49 names inside. 2:55 So we can just reuse one component for each name, but 2:56 to organize them in rows like this, we'll need another component to hold them. 2:59 So I'll draw a box around all these tiles to represent that parent component. 3:05 Now we've mapped out all our components, 3:10 and notice how some components are inside others. 3:12 Well this nesting shows how the components will be nested in our app. 3:15 For example, these purple boxes represent the children of the name tile components. 3:19 And these name tile components are the children of 3:25 the component we'll build to hold them, which is a child of the app itself. 3:28 So I've been color coding these to show you how they are all related to 3:32 each other. 3:36 For example, these orange boxes will be sibling components and 3:36 the green boxes are all these orange boxes' children. 3:41 So now let's think about how state will be shared. 3:45 When a name is typed into the form, the ghost tile here will need to have access 3:49 to that form, so it can know what to display. 3:54 So the name is an example of that state that will be shared by both the form and 3:57 ghost tile components. 4:03 Since these two components will need access to this state, 4:05 we're going to store that state in their closest shared ancestor. 4:08 In this case, that would be the main app. 4:12 The main app is the parent of the form and the grandparent of the ghost tile. 4:14 So that way there's a clear path to the state from both components. 4:19 So let's keep looking at other components to make sure this will work for them too. 4:23 The counter will need to change based on the number of guests in the state, right? 4:28 Well since we're planning on putting the state In the main app, 4:33 the counter will be able to access that from its parent. 4:36 But the counter also needs to know which boxes are checked in the name tiles below. 4:39 So as long as those components are updating the state in the main app, 4:44 the counter will be able to access that information. 4:48 And the more you think about it, any part of this app should just access 4:51 the state in the main component to either update it or read from it. 4:55 For example, 4:59 each of these remove buttons here should be able to remove the guest from a state. 5:00 And editing a name should alter the guest's name in the state. 5:05 So the main component makes the most sense, to hold the state, 5:09 since it's the nearest common ancestor to all these components. 5:13 Right, now that we've worked out a rough idea of our app's component structure and 5:17 where the state will live, 5:21 let's get specific about what we'll store in the state. 5:23 Then we'll set an initial state for the main app component. 5:26