Promisify, Flux, & Redux Patterns

[00:00:00]
>> Maximiliano Firtman: Patterns about data and state management. And also typically this is useful or more useful when you have large-scale applications. So let's start with some, I'm just going to tell you about some design patterns. There are a lot, and maybe I can link to one of the examples that we have already done in some cases.

[00:00:22]
For example this one, promisify data, what is this? Also, the term is weird. The problem is that data management tends to change in the future. I mean, I have a list of something and in the future, that list will change. The source of the list will change. So when working with a static, hardcoded data, is difficult to move later to an async call.

[00:00:47]
For example, I have our list of commands. It's a hardcoded list. Okay, that's one example, the data that we have in our to-do list was a set. It was a synchronous set. Well, we have a problem there. We don't know that we had a problem, but we have a problem in the future, if we wanna get.

[00:01:16]
So let me show you the problem in the code. Let me load again the to-do masters. So I'm talking about this. The actually items, I guess is a problem. I'm returning the data synchronously. What if tomorrow the items are coming from a database or from the network? Yeah, well, I need to change this to an async function, but also I need to change every consumer of that.

[00:01:52]
Do you realize that we were using this in a lot of places, and we have already coded that tested that we are late to the party if you wanna change that. So the promisified data design pattern says that we should from start create an async. So instead of doing that, I should, even if it's a set, it doesn't matter, I should already, from the beginning, create something like this.

[00:02:20]
getItems, not using a property now, getItems. And I'm going to return a promise, even if it's not async. So for now, I can return a Promise.. And I can directly resolve the promise with that data. From scratch, so from scratch, every data that you have, even if it's hardcoded or if it's a synchronous data, just always return a promise.

[00:02:50]
So now consumers are forced to wait for this, to use, to consume a promise. So you can use promises with synchronous information as well, like in this case. So in the future, if I change the implementation, and now the sync data becomes async because it's coming from the network, it's coming from hardware that I have somewhere or whatever.

[00:03:15]
And now I don't need to change all the consumers. I just change the implementation, okay? Make sense? You have any question on that?
>> Maximiliano Firtman: Just even if you are returning a value here, I know you have a maxAmount of and you say, it's 5, okay, return 5. No, don't return 5, return Promise-resolve(5).

[00:03:43]
So force yourself to return always a promise when you think that maybe in the future that data can be coming from an async source. That's kind of the idea, okay? Okay, that's promisified data, that was actually what we're explaining here. So right here, have an example on how to do that.

[00:04:08]
So before we were returning the data, now we just return Promise.resolve and that's all. But that will make things easier in the future, if that changes. Flux, have you heard about the Flux term? No, design pattern? We have one yes.
>> Student: Redux is based on, right?
>> Maximiliano Firtman: Exactly, probably you have heard about Redux.

[00:04:32]
Well, Flux is the theory behind Redux. Actually, Redux is a shorter implementation of the Flux design pattern. So the problem to solve is that in large scale applications, managing the state of an app becomes too complex and unpredictable that anyone can change the data. And what happens is that data should update something, and then I change the data, but I'm forgetting to update the data and the database.

[00:05:00]
So, it becomes really unmanageable. So the Flux design pattern uses unidirectional data flow, simplifying the architecture and predictability of state changes. If you have never played with this, I'm not expecting you to understand fully the design pattern just in two minutes. That I'm going to mention that. But it's just a trigger for you to go and get more later.

[00:05:28]
But some use cases is data storage, form-intense applications where everything is a form in several steps, things like that, e-commerce, content management systems, and so on. And I will show you now a very common animation. It's from the official Redux website that shows this case is Redux that it's not 100% following the Flux design pattern, but it's kind of going on that way.

[00:05:54]
So, it's simpler to understand if you know Redux, the difference is the Flux animation, except that's more than one store, which is not part of Redux, actually. Redux has only one store. But actually, you separate this in a store. What's a store? An object with your data. For example, our to-do items, that's a store.

[00:06:16]
Our set of to-do items, that's a store. Then we have the view. What's the view? HTML, so HTML, the domain API, that's the view. The view is the, why is it called the view and not HTML? Because the pattern is agnostic to the platform. You can use Redux on mobile apps, on desktop native apps.

[00:06:36]
It's not for web apps, okay? Yeah, we are using it on web apps, but you can use it on any piece of software. So that's a view. Actions are actually similar to the commands idea, the commands that we created, so things that happen over the system. And then we have middleware, dispatcher, let's get out that for a second, and reducers, those are the most important part here, there are functions that receives the action that has just been dispatched.

[00:07:07]
For example, someone has just added the to-do. Reducers will receive that action and will make a decision about if they need to change or not the store. I'm simplifying this, and again, this is a two-minute expansion of this. But here you have the animation. So let's say that there is an event in the view, you click a button and action is dispatched.

[00:07:29]
Then that action goes to all the reducers. The reducers are making a change in the state. And because you change the store, you change the state something has changing the view. So I'm adding a new to-do, okay? So think about it. I'm adding a new to-do. You press the button, then it creates an action, the add action.

[00:07:49]
Let's go there the action. The add action goes there. One reducer says, yeah, I can take that. I need to add that to my set, and because the state has changed, I'm updating the view. It's unidirectional. That's the idea, okay? That's a design pattern that you can implement with your own ideas or you probably will going to use the library for that, such as Redux.

[00:08:13]
There are other Flux-related design patterns or libraries that are based on design patterns as well.
>> Student: And just to know, we have a couple of courses on, we have a Redux fundamentals course, and then a Redux that goes into Redux Toolkit, taught by Steve Kinney.
>> Maximiliano Firtman: Okay, cool yeah, it's a big topic.

[00:08:35]
Okay, so, and by the way, it's a design pattern, so that means that you don't need to implement that, always. In fact, there was a wave, I think that it was four years ago, five years ago, where everyone said, I need to use Redux. If you're not using Redux, you are doing something wrong.

[00:08:50]
And then that era has already passed, but that's because we were not thinking on design patterns. We were thinking that it's the cool library of the moment. It is a design pattern, so, you need to see if it applies to your problem, and if it applies to your context.

[00:09:08]
We need to remember those ideas from a design pattern.