IIFE Pattern

[00:00:00]
>> Kyle: So then you get to thinking, well, if i can put a variable, if i can put an expression inside of those parentheses and then immediately run that expression, why couldn't i just take the another teacher function and put it as an expression? Why do I have to make it into a variable and put the variable in?

[00:00:22]
Why don't I just take that function and put it right there? So here we're going to replace the variable with the function expression. Now inside of that first set of parentheses, we still have the second set of parentheses down here to execute it. We have a function expression that is then immediately invoked.

[00:00:45]
And being the terribly creative bunch that we are in JavaScript, back in 2010 we coined the phrase immediately invoked function expression, a.k.a IIFE. That's where this comes from, using a function expression to create a scope, immediately invoking it. It's a sort of ephemeral thing, we only need it for that moment, just so we can have a scope.

[00:01:08]
So it runs once and then it kinda goes away. It's not like a regular function that we might need to call multiple times. It's a once and done sort of thing, and that's why we use the IIFE pattern. Why is this not a function declaration?
>> Speaker 2: Some sort of parentheses.

[00:01:30]
>> Kyle: Because the word function is not the first thing in the statement. In other words, those parentheses are there literally for no other purpose than to syntactically turn that into an expression instead of a declaration. There are a variety of other syntactic ways to turn a function into an expression.

[00:01:51]
For example, instead of the first surrounding parentheses set, we could have put a unary operator, like a plus or a negate or a minus or a tilde. We could have even used the lesser known but still important delete or void operators. Anyone of those unary operators would have had the effect of turning that from a function declaration into a function expression, and it would have then been able to execute.

[00:02:16]
We'd like to not have to, it would be nice if we could conceptually just make a function declaration that executes, but then think about it, even if we could do that, the function declaration would still have the effect of polluting the enclosing scope. So what we really need here is a function that we can run, and not pollute the enclosing scope.

[00:02:36]
And by turning it into a function expression, we accomplish that. So the name another teacher doesn't show up. Now you've almost certainly seen your IIFEs as anonymous. You've almost certainly seen those IIFEs without any name there, like you see here on line 4, because of our love affair with anonymous function expressions.

[00:02:57]
Recall my recommendation from earlier? Never, ever, ever should you have anonymous function expressions, and that includes your IFFIEs. If you are making an IIFE, there's some purpose for it. In my silly example here where we're talking about a teacher, there's not a lot of purpose. It's not very easy to figure out.

[00:03:19]
You could still call it another teacher or give it some other name to describe the purpose of that particular scope.
>> Kyle: And if you really are just stuck and you can't come up with any name to describe the need for some particular scope.
>> Kyle: Then just use the word IIFE.

[00:03:40]
IIFE, in capital letters. And it's gonna show up in your stack trace, you're gonna know it's coming from an IIFE. That's still better than seeing an anonymous function, and having no idea where it came from, or what it was for.
>> Kyle: What's nice about these IIFEs, whether they're anonymous or not, is that they are just functions, which means we can pass in values.

[00:04:01]
So here, I was able to eliminate, didn't even need to make any assignments. I can just pass in a value to a parameter.
>> Kyle: By the way, another usage for IIFE, it may be a little less common, but another usage for IIFE is for turning things that are statements into expressions, because and IIFE is an expression.

[00:04:23]
There are sometimes places where it would be convenient to have a statement be in an expression position. One of those examples, which I have run into on many occasions, is I would like to be able to make an assignment to a variable and then have that assignment expression include a try, catch.

[00:04:43]
For example, I often will do something like teacher equals fetchteacher and that function might be able to throw exception. So it would be nice if I would wrap that in a try catch then have a fall back. Well, the down side is the try catch is a statement so it doesn't work in an expression position.

[00:05:01]
That's an unfortunate nuance of our grammar. And so the next best hack is that we just make a variable and then assign to it twice, like we're doing here. And a lot of you probably do this, and I certainly have as well. But I would like to be able to make it clearer especially if there was gonna be more lines of code than just the three or four.

[00:05:22]
I'd like to make it clear to the reader of my code, that teacher only gets assigned once. That's not terribly obvious from this code. You have to sort of figure out, okay, I'm only getting one of the two values. And I'd like to make it obvious that teacher gets assigned once.

[00:05:38]
So, if I use an IIFE, I can accomplish that a little bit more clearly, I can make a try catch statement into an expression by wrapping a function expression around it. Not very common, but I'm just pointing out that IIFEs can be used any place that you need an expression, and any time you need a statement or a scope in an expression position, the IIFE accomplishes that task.