Managed effects and Elm
One really neat thing about Elm is that Elm has managed effects. What does this mean? When you want to perform an action that would cause an effect somewhere (ie: calling out to an http server, reading or setting local storage, etc) you have to ask Elm to do it for you. Let’s have an example.
How about we make a function to bake a cookie. Obviously baking a cookie has some effects, namely the act of baking a cookie. We could go about this in one of two ways:
Normal Effects
We want to bake a cookie. We encounter an instruction and we go out and do it. First we need to get some flour, so we drop everything and get the flour. Then we see we need to get sugar, better drop everything and go do that too. In other words, for every step we go and do it in real time.
Managed Effects
Another way we could do it is by writing down a recipe to follow later. Now you may say, “Recipes don’t make cookies, people make cookies!” and you are right! In this paradigm, we write down a list of instructions and have some one else do all the dirty work for us. In other words, we describe a task and someone else does it on their own time.
So why would we ever want to go about life with managed effects?
It is easier to change the recipe.
If we get all way through the cookie baking process and realize that we forgot salt, it would make a pretty bland cookie. With managed effects, we can change our description of a task at any time. We do this via mapping, chaining, and other functional tools at our disposal. This gives us huge degrees of flexibility.
It is easier to reason about the recipe.
In the first scenario where we manually and immediately perform every action, things can get quite scary. Imagine if we had a function named fetchChocolate only later to realize that this ordinary sounding function spent our entire budget on chocolate. When effects are immediately and implicitly executed, there is no real safe guard against this type of behavior. With managed effects, everything is explicitly stated and executed later. By looking at a function signature we can tell if a simple sounding function is going to cause chaos. But really, with managed effects they wont cause chaos.
It is easier to test the recipe.
How do we test the first method? Well, there are a number of things to test, primarily we need to make sure the instructions and execution are both working correctly. For example, the execution of sifting the flour, as well as the amount of flour could both be wrong. With managed effects, we are only testing the recipe itself. Since the recipe is data, testing this can be incredibly simple.
We can get free optimizations.
When we are manually executing effects, we are responsible for the implementation of how things are executed. Since Elm has managed effects, we simply give a list of instructions to the Elm runtime and it will do them for us. Elm can then optimize things under the hood to jump between tasks, wait for opportune times, and much more. Imagine the virtual DOM. We don’t want to care how things are inserted, updated, or removed from the DOM. All we want to care about is describing how the DOM should look like. This is one such optimization Elm can do for us. Back to the important bits, who knows what type of Pastry Chef is baking our cookies, all I know is they can do it worlds better than I could.
I hope this sheds a little bit of light into yet another exciting aspect of Elm.
