Normalize Effect Types

[00:00:00]
>> Lastly, shapes. Can anybody name the shape? Just kidding.
>> [LAUGH]
>> [LAUGH] I'm using this to represent a bunch of different effect types. So you have your async and your error handling, and your event streams, and we tend to model these with types like the functors. So you have your task and your either, and your this or that.

[00:00:24]
And at the end of the day, these things don't compose, monads don't compose. And so what happens is, functors compose, mono is compose, and we'll see that. But if you have to use a monad in your application, which is typically the case, these things don't actually compose. So, we focus on normalizing the shape, kind of mashing them into the one thing like the inside of a gobstopper.

[00:00:49]
>> [LAUGH]
>> And then you can combine them, and it's all happy, right? So normalizing the effect types throughout the app is something that you probably want to do. I don't think it's necessarily necessary all the time but, necessarily necessary. It's just good guiding principle to have a normalized shape of your effects so you end up making maybe an app monad, and everything falls into that.

[00:01:17]
And so everything kind of composes. And there's different strategies as we'll see, we'll see free monads, free monoids, that stuff.