Transcript from the "Pure Functions Checklist" Lesson
>> So, a couple examples here. On the left, not a function, same input, getting different output there. Anybody know what, is it total, deterministic, side effects? Looks like it's not deterministic, because the same value gets different outputs. And on the right, it is a function, same values, same outputs.
[00:00:25] Or same input, same output. This one's fun. [LAUGH] So we're gonna turn title into a URL friendly slug on the left, but it just throws an error in your face. So, you could debate whether that's a side effect, or that means it's not a total, or whatever else.
[00:00:44] We're just saying, hey, if you end up with the URL that's less than 1, and where just gonna blow up. And on the right, even though it's got a Promise, and it's doing all this stuff, and it still has an error in there, we're not throwing the error, we're returning it as a value.
[00:01:00] And that's perfectly acceptable. We're saying, this function returns a Promise, that returns either an error or the URL. Whereas the other one promised a nice URL, and then it blew up with an error. So that violates the mathematicalness of the function. And this last one, it's kind of a fun example.
[00:01:23] So, sign up on the left, just, devil may care, saves the user into a database. And then we welcome the user in one way or another. We don't even know what it's doing. Can anybody even guess what's happening there? It's very side effecty. And then on the right, we actually return a function that will go do that.
[00:01:45] [LAUGH] So it's totally pure, if I give it the same attributes every time, I get the same function out as my output, that will go do it. And this whole kicking the side effect down the road by returning a function, is a lot of the work arounds we do to keep everything nice and pure, and composable within our app.
[00:02:05] And then we kinda push that under the collar, [LAUGH] you have to deal with the problems [LAUGH]. So, all right. We're gonna play function or no function. So, shout it out, is this a function? Anyone, Hank? [LAUGH]
>> All right, it is not a function. If I gave it the same user more than once, I'm gonna get different outputs, right?
[00:02:32] We're actually mutating the user's age. So, bizarre way to catch their age for the birthday function, but that's fine. All right, how about this one, is this a function?
>> All right. That's right, same output, same input. And, no observable effects, and works for every possible string, I imagine.
[00:02:58] How about this one? Anybody have an idea? So innocent. It's using snake case [LAUGH], that disqualifies it immediately. It's Python. I don't know, anybody?
>> I'm gonna go with no.
>> It's not a function-.
>> It's doing an external call, that's what I'm going for.
>> That's exactly right.
[00:03:23] QuerySelector there is going to go out into the world and try to find this thing. Which, if I call it on a Tuesday at 5 o'clock it might work, and then Wednesday at 1 o'clock it doesn't work, different outputs, the same header_selector. So that will not work. Also, this one, I think there's two more of these.
[00:03:46] [SOUND] [LAUGH] All right, anyone got an idea on this? Pure or impure? Is it a function or not a function?
>> Impure, cuz of the location search.
>> That's right. So, again, different output. If the location search changes, this function, and you can notice there's no argument.
[00:04:10] [LAUGH] So it's pretty. In fact, if I just made location search the argument, this would be perfectly functional, this would be a function if I just passed in the search.
>> So that's something to think about when you're creating functions is, is this function reliable? Or am I just doing things?
[00:04:25] Am I making a mathematical function or not? Here we have a parseQueryString. This one's a trick line, anybody guess? We got vars, we got for loops [LAUGH], it is indeed a function. You don't have to read it, I'll just tell you [LAUGH]. Yeah, there's no, even if, look, we're mutating this thing within here.
[00:04:50] But that's totally fine, the function itself within the boundaries of parseQueryString will always give you the same output with the same input. You got a question?
>> Are we leading into the closure being part of the definition? Whether your function is or isn't function?
>> That's a really good, that's a good question.
[00:05:10] Let me hop over to this for a second. I just kind of mentioned this. So, if I do, my App, and it takes whatever, jQuery, or whatever else. And then, we're defining functions in here like, doThings. And, what's happening here is, and we'll return, doThings. All right, JQuery, the time of this function's definition can never change, right?
[00:05:46] So, even though we're in a closure, it's very much like an object, and I could up here technically say, jQuery is null [LAUGH], and that would break everybody inside me. We're gonna, fast and loosely reasoning is morally correct, is the slogan here. Just define it, in terms of, in this environment can my things change?
[00:06:16] Do I have changing variables, will this give me a different output for input? If it isn't likely, if that's not gonna be a case, then it's a function, don't worry about it [LAUGH]. That was a great question, a lot of people have that, and they're like, what? I think before we had an example where we say something like, the age limit is 18, and then we have a function that uses it.
[00:06:40] And then we change it to 21 later in the future, or something. I mean, again, just use your judgment, if that never changes at the function, if it does, it's not. And you could pass it in, but I don't want you to have to jump through hoops that are unnecessary.