Check out a free preview of the full State Management with Redux & MobX course

The "Introduction" Lesson is part of the full, State Management with Redux & MobX course featured in this preview video. Here's what you'd learn in this lesson:

Steve Kinney introduces the course on Redux & MobX by giving an overview of what the course will cover and argues for the value in improving the state management of an application.


Transcript from the "Introduction" Lesson

>> Steve Kinney: Hello, so we're gonna talk about Redux MobX. And it's gonna be great. Both of these are libraries that help us manage state in sophisticated react applications. Like we act as a bunch of really great ways to manage state but these are like kinda alternate solutions and yeah, there are additional libraries above and beyond plain old react but I would argue that they bring some of their own benefit to the table.

So throughout this course, we'll be able to kind of see how they're used. See haw to kinda extend them and kind of like evaluate the merits and tradeoffs and I think we'll be really cool. My name is Steve and I am a Senior Principal Engineer at Twilio SendGrid, which is a mouthful.

And I work primarily on our drag and drop email editor. I'll show you in a second. We're gonna talk a little bit about managing state today, which for me, it's definitely the trickiest part of any kind of large client-side application. I think, at certain times the jQuery would get made fun of turning into spaghetti code, and stuff along those lines.

It's usually cuz you're storing all your states in the dump and keeping your head around that became really difficult. And so, it argued that what makes a code base unmaintainable and hard to iterate on is when you get state management wrong. And so I think that there's great value in to thinking through these things, we'll talk a little bit more about that.

We're gonna start at the very basics and work our way up, and I feel really strongly about this. Prior to working at Twilio SendGrid, I was Director of the front end engineering program at the Turing School of Software and Design. And we started the front end program. Originally it was a rails development training program.

And then we also built their front end program. And I got to teach a lot of React and then Redux. And I made a lot of mistakes teaching Redux. And I think they're really common mistakes, which is one, trying to teach Redux and React at the same time.

Cuz not only does Redux have a lot of concepts, Redux is actually incredibly simple. Go like, yeah, cool. I promise you, like under the hood is actually incredibly simple and the React Redux library also simple but when you try to learn the both like simultaneously along with like Just all the other learning curve of React.

It just becomes a little bit too much and frustrating. So what we'll do is we'll look at Redux completely agnostic of React. Redux and React are a common pairing but there's no particular reason why they have to be. You can use Redux in an Ember and Angular app if you want to.

So we look at the library like completely separate from react, then we will actually hook it up to react. And we'll talk about how the way you structure your state manages, matters probably, arguably more than whatever library is. And for a lot of this, like when we talk about the normalizing estate, like how to normalize your status structure, the data structure, even if you decide, hey, I'm not gonna use Redux, I'm just gonna use pure React, a lot of that still applies.

A lot of this is just how, it's a strategy for structuring a state in a client's application that again, is effectively library or framework agnostic and a good idea most of the time. And then we'll talk a little bit about how the way we manage state can negatively impact your performance and how to go about fixing that.

We'll talk a little bit about middleware kind of in the beginning when we're exploring Redux, and we'll use some middleware. We'll try it 1,2,3 Redux dunk, Redux itself doesn't have any way of managing asynchronous code. So we have to use middleware for that. So we use once Redux thunk.

We will kind of crack open the doors of Redux observable or Redux observable is Redux bindings for RXJS which is like a topic in and of itself. So we'll kind of like learn just enough RXJS to be dangerous. But that is definitely like an avenue of further exploration.

And then we're actually gonna look at a completely different library called MobX which takes some of these reactive programming concepts. And then strangely like reactive programing with a lot to think about like functional programing kinda ties it in to a very like more traditional, like object oriented way of thinking about our state and like, is incredibly like powerful and convenient.

I think a really cool way to like think about state differently than what we normally think about in the react paradigm. So I guess that like. One of the reasons I think this managing state is really important is because doing a massive refactor of this later on is like fraught with peril.

The bugs that you could introduce like it's a fundamental shift in your application. So thinking about it and making some really great like decisions around it, like benefit you like long term for the maintainability of your app for the performance of your app, everything along those lines. And like, effectively if your code is maintainable and it's easy to shoot new features, that tends to make you happy and if [LAUGH] every ticket you come across on like the good old JIRA board is terrible.

It starts to like weigh on your like soul. So having good state management, you just get code out the door quickly inspires joy, which means you don't have to throw it out. Cool. So like I said, we dealt with this a little bit where we're still kind of in production right now, but soon to be deprecated in about a month, version of our application was kind of, I mean this as nicely as possible.

It was for the kinda small team that started out on it in the beginning, their very first react application, and as it was explained to me when I started, we use the flux pattern but not really cuz we didn't really understand the flux pattern. So it's flux like.

And we had some major architecture shifts on the back end, which meant that we had to like completely overhaul the front end application. But it was also at the point where shipping relatively easy things, you'd touch one part of the code base and something would pop out weird on the other end.

And it was getting really hard to confidently ship new features. So along with a larger kind of change in how we were approaching stuff, we kinda took the time to think really deeply about the state of our application. Like, this sounds very, like big tech company-ish. But we had meetings about how we're gonna structure our state.

And like, I don't regret a single one of those meetings. I think right now, I think one of things I'm really proud of is that a brand new kind of junior developer on our team can ship code and be productive in their first week. And can get up to speed even though we do use some like Redux is pretty standard.

Redux observable a little bit more like wild. But we can get people to productive very quickly, and we're constantly ahead o schedule which is typically not a thing in software. And so it's really interesting for me to see how some poor decisions that we made the first time around flowed us down like we were walking through molasses and good decisions the second time around made us over incredibly productive and fast.

So we'll kinda talk about some of those approaches in this course. We're not gonna cover too much of React itself but it is impossible to talk about state management libraries that plug into React without touching, there's some amount of react. And there are things we'll talk about, like, does everything need to go and Redux?

Does everything need to go on MobX? My argument is no. So we'll kind of like explore those boundaries a little bit. We'll talk about Redux. And we'll look at, Redux is really great. I like greatly enjoy it for managing state. But one thing that Redux is not bring to the table at all is any ability to make API calls or any kind of like side effects, which is a thing.

So we're gonna need to use some kinda middleware in order to do that. Redux thunk does not have a logo. So I've just made them one. You're welcome, everyone. Then there is Redux observable. It's three ducks. Yeah, the one on the website spins which is also really cool.

And finally, we will look at my books. So we're gonna build a few different applications to kind of get our hands dirty and kind of actually be able to exploit these libraries. One is just like the kinda basic counter. I think it's really good for like, seeing some of the concepts in isolation.

We'll build a conbon board, which has got enough complexity. We'll hopefully see Redux shine a little bit. And I'll give us enough cases where like, we do do needless rerenders and need to fix them and stuff along those lines. And then we'll have a kind of simple app which is effectively like if you tilt your head, it's a Kanban board kinda now vertical instead that we'll use with MobX and then we'll do some asynchronous calls.

We will implement an auto-complete. First, we're doing Redux thunk and that eventually in Redux observable, which will bring us some really cool things, like the ability to cancel an AJAX request, like, okay, cool. They typed another character. I don't care about the network request for the first thing I only care about the second thing.

In the server itself, we'll add some entropy in there, which is like, I'll randomly delay stuff so it gets all weird and funky, and we'll see how like. Redux observable kinda cleans that up. And then we'll also like bring in some like live tweets using Duncan observable, as well.

What I wanna point out is that, yeah, we're talking about a bunch of libraries in this course, but it's not all about the libraries, because a lot of these concepts like normalizing your state, immediately changing objects is effectively like library agnostic, a new library could come out tomorrow and a lot of these concepts will still apply.

And so they'll come and go. I think at this point, we are in somewhat of a steady state. We did the first version of this course a year and a half ago, and most of the libraries are still around and still popular. We use Redux, we use MobX, so on and so forth, and like in the JavaScript world is nice to see stuff stabilize a little bit and not have to like completely like, all right, no more Marionette.

We're switching to Angular one. All right, angular two is different. [LAUGH] All right, now, like, we don't have to do that as much anymore, which is great. So these patterns and approaches stick around. So my suspicion is a lot of these libraries will still stick around for the long term but I think that these patterns and approaches, for a lot of them, are stolen from the 70s and 80s.

[LAUGH] Which I think is really cool. And like new things will come along but, yeah, my suspicion is that when we kinda figure out some of these things will work out really well. So my goal is to help you think about these patterns. And we'll do it in the context of these libraries.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now