Avoiding Cascading Effects

[00:00:00]
>> David Khourshid: I'm excited for the next one because it's very painful. So it is on cascading effects. This is something that is almost inevitable when you get into bigger and bigger projects. What happens is that you have some states, whether it's in use, state, useReducer, wherever, and then you have multiple use effects that are cascading.

[00:00:30]
In fact, I think that this is worse than having a use effect that runs on an infinite loop accidentally, because these are just very hard to track down. I know I've been talking about state machines a lot, but when you have useEffects at cascade, it's more like a Rube Goldberg machine where something is happening.

[00:00:49]
And it touches something else, which triggers something else, and then that touches something else, and then you have this cascade. The side effect of this is that you're not sure where data is updating or when effects are being executed. You're just hoping that if I put everything in the dependency array and then I have a conditional set inside of my useEffect that says only run this effect if this conditional is true.

[00:01:18]
So you're sort of filtering from everything you're putting in that dependency array, it just becomes very confusing, and so bugs become very hard to track down. There have been many times where I have had to myself debug these multiple useEffect hooks, that cascade. And I had to do things like comparing the previous dependency array with the current dependency array to comparing each item and seeing which of those items changed.

[00:01:48]
And then once I identified, hey, this item is causing this effect to run when it shouldn't run, then I would have to backtrack and see, okay, where can this item be possibly changing? And so when you don't have events, you are really having to depend on when data changes, and that just becomes very confusing.

[00:02:10]
So this is an example over here, where we have an effect that triggers when the inputs change. And then we perform the flight search, and then the hotel search is triggered when we select a flight, and then we perform a hotel search. And so this can be, for example, a component that tries to show everything in one page, which is pretty common, but in order to do that, we are just chaining these useEffects together.

[00:02:40]
And even though this looks simple enough, when you add the actual implementation of the useEffect and these dependency arrays grow, it just becomes very confusing. So the way that we could do that, or, sorry, the way that we could avoid this problem of these multiple chained useEffects, is by, well, reducing the number of use effects and using a reducer.

[00:03:07]
And this also gets closer to our idea of declarative effects too. So when you have a reducer, you could basically say that if we for instance have flight updated. We could have a single use effect that manages whenever this date changes, I need to do the appropriate effect for that state.

[00:03:30]
So this is the end result of doing things in an events driven approach. But how do we actually get there? So what we want to do is actually work backwards, look at all of our use effects and also observe the running application and see when are things actually happening.

[00:03:49]
So what data is changing? And can that change of data instead be represented by an event rather than it just changing in the use state? And then that's triggering a use effect. And so if it can, we could refactor to using an event and then just executing effects based on the state.