Transcript from the "Introduction to State Management" Lesson
>> Steve Kinney: So, first thing's first. My name is Steve. And by day I am the principle front end engineer at SendGrid. The kind of short version of what SendGrid does, if you've used Twilio, it's like that but for email. So every time you take an Uber or late night order something at eBay and you get that email right back, SendGrid send that to you.
[00:00:29] And so, a lot of large part of that is the API. I actually work on our marketing campaigns product, which is, this is kinda screenshot of it right here. And the reason I'm showing it to you, is kinda I wanna let it wash over you for a second, right?
[00:00:44] It's effectively like a desktop app in the browser for WYSIWYG-creating email clients, including for everyone's favorite Outlook 2010.
>> Steve Kinney: But, I feel like at a certain point in a lot of engineers careers, they find the thing that they become very passionately interested in, right? There are the engineers that are like, deep into trying to figure out how to get every kilobyte out of their bundle size, and get the network download as fast as possible.
[00:01:17] There are engineers who are like passionate about getting performance down. To the fastest possible metric. What I kind of realized is if you look at this app, there's a lot of state in it. There is where they are in the application, whether they're on that Build tab or that Settings tab.
[00:01:35] There's also the content of the Email that they're currently building. Which module they have selected, what the different properties of that email module is. There's a lot of steak\g going on, and I found that for me, the thing that I have kind of become very passionate. I was figuring out like how do we manage a lot of complicated state, in what is effectively a document viewer from the 90s that was never meant to do any of these things.
[00:02:02] So it's a very kind of interesting problem to solve, and not necessarily an easy problem to solve, as we're gonna discover over the next day or two. This is still an emerging kind of field, as we kind of try different approaches and check it out. So we're actually gonna kind of take a tour of a lot of those things, and I'm gonna set the stage for that right now.
>> Steve Kinney: We're talking about state. And, we're gonna actually take a look at a bunch of different approaches to managing state. We're gonna spend a lot of time in code. Looking at different libraries. But, we're actually gonna be spending a little more time think about like, what are the different kinds of state?
[00:02:43] How do we work with state and how do we obstruct it, to a way that's manageable to work with in a large application. A lot examples that we're looking at very small and isolated with a, are meant to kind of pull out problems that I found working in this very large email editor, which is just state, upon state, upon state, upon state.
[00:03:03] To do that, we're actually gonna start at a really basic level. So even if you're kind of new to React and new to managing state, we're going to start there and build it up. And that will be great if you knew it's really important if you have a lot of experience, because the main part of it is kind of build on this idea from the smallest possible and workout to see how those things principles and ideas, kind of escalate when we get to some more advanced approaches.
[00:03:27] So we're gonna start incredibly small, which is with basic React component state. And when I say small, we're gonna start, everyone's first like react out which is a simple counter. Where all the states is encapsulated in that one component. There is no derived state, there is no passing it down to children, there is no getting it from anywhere else.
[00:03:47] It starts out with this one kind of mostly atomic unit of state in React, which is the simple component that manages its own state. From there, we're gonna build up to one of the derived state from other pieces of state. Spoiler alert, it’s going to be an application that actually got used at my old job.
[00:04:06] Before I worked at SendGrid, I was the director of front engineering at the school of software and design. And one of the things you ended up having to do lot was order pizza. And you laugh, cuz it’s like a simple application, but it turns out that it was always very difficult to figure out exactly how much pizza we had to order.
[00:04:23] So I made a pizza calculator, and it gets used a lot to this day. So, but that is thinking about the number of people and the number of slices each person's eating, and then like trying to figure out more state based on that state, but still really simple.
[00:04:35] From there, we're gonna build an application where we start passing down state to child and grandchildren components. And then those events have to come back up. It's still enough that we can wrap our heads around it in a very kind of short period of time, but emblematic of the problems that start to emerge when you do this in larger and larger applications.
[00:04:54] We need to extrapolate that to applications that would take way too long for us to build over the course of two days. Finally, we're gonna build that up to like dealing with a synchronous state, like okay it doesn't happen immediately. We have to talk to a server, or to local storage or index to be, or something along those lines.
[00:05:10] I kind of figured out what new challenges does that introduce. So very systematically building up. Starting first with just the lowly React component state that we all know and love from our very first React tutorials. Form there we're gonna go in a little bit of a chronological order.
[00:05:28] Which is thinking a lot about Flux. Flux is again like Facebook says it's a million times it is not a necessarily a library, but an approach or an idea which is like there are many different Flux libraries, we are actually gonna start with just the core original one.
[00:05:44] And a lot of the reason for that is to think about the pattern. Think about what the actual Flux architecture is, and what some of the decisions and tradeoffs are there. And how stuff like Redox that came after it, which is generally considered to be a Flux implementation, how that derives from Flux so on and so forth.
[00:06:05] So, at that point we arrive at Redox, which is again a interesting take from the Flux architecture mixed with some ides from Elm, and definitely like a different way of thinking about the Flux approach. And at this point, I think we can call it as a wildly popular approach to managing state in react applications.
[00:06:27] And we're gonna approach that in an interesting way, I think a lot of the ways that people learn Redux is directly inside of a React application. So they're in React, they're learning sometimes React and Redux at the same time, or at least they're learning how to use Redux in a React application.
[00:06:45] We're going to start with just hammering away at Redux itself. And kind of understanding it. Because like there's nothing about Redux that has to be tied to React. You can use Redux with angular. You can use redux with backbone if you wanted to. You could use Redux with jQuery if you wanted to.
[00:07:01] So we're gonna hammer at it from just like what is Redux and kind of like poke at the library and get a sense of how it works internally. Sometimes recreate some of the methods inside of redux. And other times just kind of like get a sense of how they actually work outside of React.
[00:07:17] Then we're going to pull it into react and figure out like okay, cuz there's the Redux library, there's the React library. And then there is the React, Redux library. And so what does that give us? That neither one those libraries have separately, how does that work and how does that connect the two of them together?
[00:07:32] So we understand each one of them individually and then look at them together, which in my experience of teaching React and Redux to a junior developers, as well as working with mid level senior developers at SendGrid. Is a much more effective approach, than trying to learn them both together and then tease them out.
[00:07:52] And some of these ideas for this workshop came from that React and Firebase workshop that I did earlier this year, where we kind of looked at Redox and wired that with Firebase in a React application, so we had to have that extra layer in it. That's where a lot of the ideas for this workshop came from.
[00:08:09] Redux however, doesn't necessarily deal with Async. And fun fact about the web, is a lot times we have to work with a synchronous code whether we like it or not, because you can't block the UI and there's a network involved. Redux thunk does not have a cool logo, so I made one just now.
[00:08:30] We’ll print out stickers later, it’ll be great. So a thunk is a way to defer action. So, instead of dispatching an object immediately, we just say, I’m gonna work on this. I’m gonna give you this function that will eventually dispatch the action. So it’s a way to think about a synchronous code.
[00:08:46] And it’s pretty like, easy to wrap our heads around. And very simple, and simple is a double-edged sword. On one hand, simple is great, because you can wrap your head around it fairly quickly. On the other hand, it's on you to build all the future abstractions upon that.
[00:09:02] We're gonna take like a very kind of brief look at Redux-Saga. And the reason for that is, they very large and sophisticated library that does a lot of really cools things with the concurrency and stuff along those lines, that could probably be it's own today workshop. And like, it is only a kind of subtitle of this workshop.
[00:09:22] The main reason we're going to look at it is because it takes the general idea of asynchronous code, and kind of turns it on the head, takes an interesting approach to it. And we wanna look at that idea. We wanna see like, what is using generators? To do with a sig, what does that bring to the table that maybe using thumps or callbacks doesn't.
[00:09:42] And how can we apply that and think of the way we think of managing state. So we're kind of using that as a alternate approach and take. And we will definitely get a chance to work with it, but there will be a lot more under the hood, that you can kinda peel away wit if that is something that like spice you of being really interesting.
[00:09:56] And finally, we're going to take a look at MobX. MobX is really interesting to me because if we think about it we have the Flux architecture and Redux, is kind of an implementation of Flux and Redux thug and Redux saga additions to Redux. MobX is a completely different approach to managing state in our application.
[00:10:20] This is not derived from that same family of state management libraries, but kind of takes more of a traditional object oriented approach. And, I think it's really interesting to look at MobX in the context of a react application, cuz there's been a lot of,
>> Steve Kinney: Functional programming like, focus in React.
[00:10:40] So kind of like, to go back to like some object oriented principles. Which are still, because it's using observable. Very functional under the hood. I think it's an interesting way to like again, add a new layer perspective to the way that we manage state. So we kind of like basically take this tour of a number of approaches.
[00:10:56] And again, we're gonna spend a lot of time in code and playing with these libraries, but the general theme of the workshop was just called like, it's about estate management itself. Touching up on these. Cuz, what my goal, is for this this workshop to be more than just about libraries.
[00:11:12] Cuz, libraries come and go. We can all name seven other Flux implementation libraries, of varying degrees, of popularity these days. I think I said this earlier, and I would probably repeat it about 700 times of the courses workshop, is that this is not a solved problem. And I think a lot of our approaches and solutions are currently evolving.
[00:11:35] Which means the libraries that we use today, may or may not be the ones that are in vogue or the flavor of the month, six months down the road, 12 months down the road. But the perspectives and patterns that we see in like how the approached to the problem, like a lot of these sagas are decades old are decades old.
[00:11:57] These are time tested, well worn solutions to problems that were kind of like bringing to table, saw this new set of like hey, we’re gonna build desktop class applications. Or native mobile class applications in the browser of all places. We end up going for these old patterns, so what I really wanna do is focus on patterns and approaches.
[00:12:19] Rather than the intricacies of any given library, which is kind of why we're doing this like touch on Flux, touch on Redux, touch on Redux spunk, touch on Redux saga. You're likely, you can use spunks and saga in the same application. You can use all of these in the same application, if you don't like your coworkers.
[00:12:34] And wanna keep them on their toes in every code review. You could use all of them, you are likely to use a tiny subset. And the reason and we're taking a tour is again, to focus on what are the patterns and approaches, and how do we think about state?
[00:12:48] What does it mean to manage state, it's kind of the major thing that I really want to get across in our time together. And I kind of already preempted this by saying this I will say this 700 times, I know that there are future slides mid way through, and at the end of this where I kind of rehit on this point.
[00:13:06] This is not a solved problem, all of these have some amount of drawback. Even the fancy newest ones like has some drawback as compared to Redux and also some advantages. So it's not hey, I'm gonna find out what the deemed best library is a master that. It's about what are the tradeoffs you need to make, and what kind of state are you working with?
[00:13:27] Cool. So, again to restate the goals. A goal is to help you think about these patterns, regardless of what the current library is. And that should new libraries come along, likely these patterns that have been in existence for decades, will play a part and then help you to understand new libraries that come along as we go through things.