Extracting Impurity

[00:00:00]
>> Kyle Simpson: Okay, so if a function is not pure for any of a variety of reasons, what are our options? One option, the obvious one is leave it impure and that's just how it is, right? It's got a right to the database. There's no way around it. Database rights are an impurity.

[00:00:21]
They are a side effect. They have to happen in our apps, there's no way to get around that. We can certainly be obvious about it. We can name that function so that it is clear, actually we can name that procedure, so that it is clear that it's gonna do something like write to the database.

[00:00:39]
We can even put a comment there like, there be dragons, side effects beware, right? We can put them in a file called side effects.js. We can be obvious about our side effects, and we said earlier the reason for being obvious is so that we make it easier to maintain this code.

[00:00:59]
>> Kyle Simpson: But we do want to reduce them as much as possible. And one of the key techniques for doing that is to take a function that may have a side effect in it, and ask, is there some way for me to rearrange the way this function works, and extract out the impurity, leaving just a pure function in place?

[00:01:21]
That does not mean to remove that impure functionality. I do not mean to take that out of the app. You have to write to the database or whatever. What I mean is it doesn't have to belong right there. If I have this set of code that's doing a very important set of computations on some kind of inputs, and then it's gonna write it to the database.

[00:01:46]
The functional programmer says, well, that could be two separate entities. That could be a function that does all the computation, and it could be a procedure that does the single side effect. So what we're talking about is to extract the impurity, to bring it to the edge, to bring it to the outer shell.

[00:02:06]
That is one way of making side effects more obvious. Instead of hiding it inside of the definition of this thing that looks like a function but it's actually a procedure, we bring it to the surface. And we make it more obvious. Example, here's an add comment, which is going to construct an object and put some values into it and then it's going to append it to the DOM.

[00:02:32]
It's an impure function, right? That is line 11 is an impure function call because we create a side effect with it, which is that we modify the state of the DOM in the page. But there are some interesting and useful stuff happening here that is separate from the side effects.

[00:02:50]
Matter of fact, not only is there the side effect of adding to the DOM, but you might not have spotted this side effect line three generating a unique ID. That's also a side effect. So, is it possible for me to extract out the impurity and make that be at the edge, make it be on the shell, and not be obvious?

[00:03:13]
Sure it is. How about if we change this code to look like that? We now have a, not procedure called addComment, but a function called newComment, whose only job is to make a new comment object.
>> Kyle Simpson: But you'll notice now that it receives the commentID as an input.

[00:03:37]
We take commentID, the unique ID generation, and we pass it in as an argument. And then instead of mutating the DOM inside of newComment we return back the DOM element. We return back the thing that is the DOM element and elsewhere we do the appending to the DOM.

[00:04:00]
Now that doesn't get rid of the side effect, it just extracts it to leave pure function wherever possible. That's what a functional programmer means by making pure functions and then having side effects on the outer shell. Wherever possible look for an opportunity to extract out the impurity, leaving a pure function in place.

[00:04:26]
That will not always be practical. It will not always be practical to do that, but wherever possible this is better than leaving something as an impure function.