The first step will be to break the app into components.

Then we'll think about how those components should connect to each other.

This will give us an idea of where its state should be.

Remember state is all the data we want to track in an app.

So when the user does any action, like type in a form, or check a box,

they are changing the state of the application.

And those changes will need to be stored as data somewhere.

As that data changes different components of the app will update what they

show to the user.

For example, when the user types a name into the main form of the app,

the app state changes to contain the string being typed.

And as that state changes,

the ghost component below updates itself with those changes.

So the components of the app need access to this state to perform these changes.

So we need to plan how they fit together to make this access efficient.

The best way to understand the component structure will be to look at what parts of

the app a user interacts with and how the app should respond as its state changes.

Anything the user will click or type in will likely be a component,

as well as anything that changes.

So let's start by looking at the app when it loads.

And I'll draw rectangles around the different pieces of

the user interface as we go.

So first, we know we'll need a component to contain the entire app.

So let's put a border around the whole thing.

And the first thing a user will interact with is this form.

So I'll draw a box around that.

And the counter is another component because it will need to update

itself as the state changes.

For example, when users submit new guests, delete guests,

check them confirmed and so on.

And the filter we check to hide unconfirmed guests will

also be a component.

And there are some hidden components we still need to find.

So let's add some names to the list.

And now we can see there are three new components, the name tiles.

And inside there are other parts that can change or accept user interaction.

Each one would contain four components.

We have the name, confirmed, check box and the two buttons, edit and remove.

Now it might seem that we've found all of the components now, but

there are actually a couple more.

Can you think of what they might be?

Well if I start typing a new name, there's this, what I like to call a ghost tile

that shows up indicating that there's a pending name for the list.

That will be a component too, because it shows or

hides itself depending on whether there is text in the form above.

It also updates itself with the text from the form.

So think about each of these name tiles here.

They are all really just the same component with different data or

names inside.

So we can just reuse one component for each name, but

to organize them in rows like this, we'll need another component to hold them.

So I'll draw a box around all these tiles to represent that parent component.

Now we've mapped out all our components,

and notice how some components are inside others.

Well this nesting shows how the components will be nested in our app.

For example, these purple boxes represent the children of the name tile components.

And these name tile components are the children of

the component we'll build to hold them, which is a child of the app itself.

So I've been color coding these to show you how they are all related to

each other.

For example, these orange boxes will be sibling components and

the green boxes are all these orange boxes' children.

So now let's think about how state will be shared.

When a name is typed into the form, the ghost tile here will need to have access

to that form, so it can know what to display.

So the name is an example of that state that will be shared by both the form and

ghost tile components.

Since these two components will need access to this state,

we're going to store that state in their closest shared ancestor.

In this case, that would be the main app.

The main app is the parent of the form and the grandparent of the ghost tile.

So that way there's a clear path to the state from both components.

So let's keep looking at other components to make sure this will work for them too.

The counter will need to change based on the number of guests in the state, right?

Well since we're planning on putting the state In the main app,

the counter will be able to access that from its parent.

But the counter also needs to know which boxes are checked in the name tiles below.

So as long as those components are updating the state in the main app,

the counter will be able to access that information.

And the more you think about it, any part of this app should just access

the state in the main component to either update it or read from it.

For example,

each of these remove buttons here should be able to remove the guest from a state.

And editing a name should alter the guest's name in the state.

So the main component makes the most sense, to hold the state,

since it's the nearest common ancestor to all these components.

Right, now that we've worked out a rough idea of our app's component structure and

where the state will live,

let's get specific about what we'll store in the state.

Then we'll set an initial state for the main app component.