|
A Quick Detour: State’ing the Obvious
Every React application – well, any nontrivial application anyway – is going to need some
sort of state, as was discussed in Chapters
3
and
4
. Exactly how you maintain this state is
a topic of much debate in the React community. I mentioned Redux in Chapter
3
. Redux
is a way to have a centralized state object that all the components in the application
share. It’s a popular approach, but it’s just one of many. And you don’t need to look
outside of React itself if you don’t want to because React offers the notion of state by
default, and that’s what I did with MailBag. The trick, though, is that to have components
sharing that state, you have to push it up the component tree as far as needed.
In other words, recall that React always constructs a component tree. Any tree has a
single element at the top with children beneath it, and those children can have children,
and so on. So, where you place your state object becomes a question, and you answer
it by determining which components in the tree need access to it. You simply find the
highest component in the tree that is a parent to all that need it, and that’s where you put
your state.
Chapter 9 Delivering the gooDs: MailBag, the Client
232
In MailBag, you’re going to find that we have a single component, BaseLayout, that is
a parent to all the rest. This is the most logical place to place state then.
However, what is state in MailBag, exactly? Well, state in React is nothing but a
JavaScript object. You could define it directly within the BaseLayout.tsx code file, but
I wanted to have it be separate, just to organize the code a little cleaner. That’s what the
state.ts file is all about. It defines an object that BaseLayout will include, and it’s where
all state for the application will live, along with the methods needed to mutate state.
But it’s not quite as simple as defining an object. We have to play some games in order to
make this work, which is why this file’s code begins in not quite the way you might expect:
export function createState(inParentComponent) {
Rather than just exporting a literal object, we have a function. This function takes in a
reference to the component that contains it, BaseLayout, in our case, for reasons that will
become apparent shortly. Then, this function simply returns an object, our state object:
return {
pleaseWaitVisible : false,
Our state consists of a series of properties in the object, starting with
pleaseWaitVisible. This is a flag that will tell our code whether a “please wait” popup,
which we’ll show every time we call the server, is visible or not. More on this later!
We also need to maintain a list of contacts that the user has created, and that’s where
the contacts array property comes in:
contacts : [ ],
Similarly, a list of mailboxes is needed:
mailboxes : [ ],
And, assuming a mailbox has been selected, we need the list of messages within it:
messages : [ ],
When the user clicks a mailbox or clicks the NEW MESSAGE or NEW CONTACT
button or clicks a contact in the list, what they see in the middle of the screen changes.
This we refer to as the “view,” and what view is current must be known for React to
render the correct content:
currentView : "welcome",
Chapter 9 Delivering the gooDs: MailBag, the Client
233
It starts out with the "welcome" view and then changes to one of "welcome",
"message" (when viewing a message), "compose" (when creating a message), "contact"
(when viewing a contact), and "contactAdd" (when adding a contact). How this changes
the view is something you’ll see later.
Earlier, I mentioned the array of messages in the currently selected mailbox, but how
do we know what the current mailbox is? As it happens, we have a property for that:
currentMailbox : null,
Then, we must think about what state is necessary when either viewing or creating a
message. For that, we have a series of properties:
messageID : null,
messageDate : null,
messageFrom : null,
messageTo : null,
messageSubject : null,
messageBody : null,
I’d imagine those are all obvious. Note that messageID would only ever be populated
when viewing an existing message, and it’s the ID of the message on the server.
Similar, when viewing or creating a contact, we’ll need some state too:
contactID : null,
contactName : null,
contactEmail : null,
The state object also contains a collection of methods that the remainder of the
application code calls on to mutate state in various ways. These are termed “state
mutator methods,” and I’m going to introduce each of those methods as they are first
encountered.
So, to wrap this up in a bow, what will happen is that this createState() function
will be called at some point inside BaseLayout, and the state object will be returned.
That object will then be a member of BaseLayout, and we’re good to go.
Well, mostly… but we’ll get to a small problem next!
Chapter 9 Delivering the gooDs: MailBag, the Client
234
Do'stlaringiz bilan baham: |
