Preview
Video Player
00:00
00:00
Mapping the Component Structure
5:29The 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 state should be.
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