Check out a free preview of the full Production-Grade Angular course

The "Effects" Lesson is part of the full, Production-Grade Angular course featured in this preview video. Here's what you'd learn in this lesson:

Lukas explains that most of the business logic in a given application exists within effects. Effects are asynchronous models that offer observable streams.


Transcript from the "Effects" Lesson

>> Now, the last piece And this is where I believe the rails go off for most people doing NgRx or any kind of state management. It's in effects the reason being is that this is typically where you want to put your business logic. Secondly, your effects are asynchronous.

And the reason why people struggle with. Asynchronous data flows is because they, especially with observable streams is because, and I say this respectfully, most individuals do not understand or truly grasp observable streams. And so the reason why asynchronous or affects our heart is because they're asynchronous. A synchronous data is hard because we haven't trained ourselves in a lot of cases to think in an asynchronous observable stream world.

And I will reduce this down to one single switch that you need to flip in order for this to work. We are used to existing in an input output world. Every one of us understands that I can call a function. I can give it input and I get output.

So all my friends that I could see in the Zoom chat nod your head if this makes sense. You call a function, you give it input, you get output. You are essentially dictating that event and you're pulling that data to you. In an observable world we have to switch from input to output, to flip it, to think about output to input.

And when in your mind, make that switch and really make that switch all of a sudden, observable streams. In reactive programming, just clicks and adjust makes sense. And how I can say this is that there are things that are happening is that you have an initial output of data.

You want to capture that initial output in your job. Is to just figure out where you want to input it into your application in what shape you want it to be in when it gets there. So, think of it as a garden hose. If somebody walks over and turns that knob, I have an output of data.

My job is not to say, give me water. It's coming it's a stream. I have to figure out where I want to put that. Am I going to put it in the flower bed? Am I going to put it in the pool? And what shape do I need it to be when it gets there?

And a really great way to think about this is in terms of dom events, that any time you move, just take your mouse and move it over the browser. You've just fired off hundreds of dom events. Your browser is a continual stream of events that you can capture and turn those, turn that into an observable string and do some really, really interesting things.

For instance, I can do drag and drop in about five lines of code. How do I do that? I want to listen for it when the mouse goes down. Start the stream I wanna capture the stream as my mouse is moving and the minute I take my mouse off, stop the stream, until I put my mouse back down.

And so, the reason why I'm saying this in terms of UI is cuz there's things that are happening. There's this initial output that we need to capture and we need to figure out where we want to put it. In the shape that we want it to be in and this is NgRx and defects in a nutshell is that we have some form of output in the form of an action coming in, which is, in this case right here.

And then, provided this is successful, we're just allowing that stream to continue. And all of the logic here, is happening in the widgets service. And so we're saying, we have a trigger event, which is your initial output, some asynchronous thing. And it doesn't have to be asynchronous. Like I would put logic in here just because I like this idea of, here's a trigger event.

Here's some unit of work, and then you have your completion event. Which is either success or failure with the payload. And so this right here of your initial output in the form of an action object like this thing happened, like it's happening no matter what you can't choose.

If it happens or not, or the effect can't choose, it's coming in. Then you need to figure out what you want to do with it. And you want to figure out, where do I want to put it? Which fun fact, you can actually chain effects together and create a really neat sequence of events.

And so, do this asynchronous thing, do the asynchronous thing, do the asynchronous thing. And so I would use this pattern even outside of NgRx, simply because it gives me the ability to sequence these events in a way that is composable. Which that's the other upside for effects. And Feeney, that completes my monologue on how it's a supervillain.

I will take over the world with state management. Now, please check out the branch and I would say methodically walk through this with the appropriate emphasis being played on the complex pieces, and understanding why they're complex. Actions are simple, reducers are simple, Selectors are simple. Where it gets tricky is in the effect.

And I think really when you understand that and you do fine grained units, that it becomes very manageable. And so I think of it just as like, we would have no problem saying this dot HTTP dot, get do something. We've been kind of playing around with that all day.

Just think of it as you have a trigger event at the beginning and a completion event at the end. And so all you're doing is you're just using if you think of it as a train that I think of the actual unit of logic is like the box car.

And then your actions are like what actually string them together.

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