IFFEs & Functional Q&A

[00:00:00]
>> It bears mentioning that this syntax is something useful to know about. Anybody know what this is called, or what this is an instance of, or a couple instances of, actually? There's a term for it in JavaScript. It has an acronym.
>> Iife.
>> It is called an iife, or an I-I-F-E, an immediately invoked function expression.

[00:00:29]
So the syntax is, essentially, instead of declaring this function, essentially with a function expression, a function keyword, or it could also be an arrow function. Then using that name to invoke it later at some other point, so not immediately, we have a function expression that's evaluated to the function itself with the parens and then called or invoked right away.

[00:01:05]
So immediately invoked function expression. And there's a couple of cases where you might need to use this, for example, async and await. Await is something that you, in some contexts in JavaScript, do not have global access to. There's more to be said about that, guess where you can go to find out all the details?

[00:01:33]
>> Our good friend.
>> Our good friend, MDN, exactly. But, for example, if you need to await something but you don't have access to the await keyword, you can put things in an immediately invoked asynchronous function to essentially accomplish the same thing as, Top level awaiting a fetch or what have you.

[00:02:02]
So this is all to say, this syntax, as unintuitive as it might seem, is gonna crop up once in a while. So now you know a fancy jargony term, if you didn't already. Yeah?
>> Do you have to name a function that you define in that way?
>> You do not.

[00:02:20]
>> Yeah, and I don't imagine you can get to it any other way. There's no way to get to it by that name later?
>> Essentially, if all this function does is get invoked, right, just once, then yeah, there's absolutely no reason to name it. There's no reason to have a reference to it.

[00:02:44]
There's no reason to what have you.
>> It'll go out of scope.
>> And yes, exactly, so let's double check. But let's go, when in doubt, to the console. Okay, so I invoked it, I got one thing. Now, bling is not defined, reference error, because, exactly, this was within its own little world [LAUGH].

[00:03:16]
And not, if I had done this this way, essentially what that told JavaScript to do is create a variable called bling in the global scope that points to this function. So when I run that function, or when I tell JavaScript this function expression, and I give JavaScript this command, as it were.

[00:03:43]
Remember this value, it's a function, call it bling, I wanna be able to find it later. JavaScript's like, cool, got you, that function keyword. Yeah, that tells me in my syntax that I'm gonna set this up in the global scope. But when we put these parens around it, and this could be an arrow function as well.

[00:04:10]
In which case it's even more obvious that we don't have to name it because we're not gonna do a const assignment here, it's not allowed. So what we're going to get is, and yeah, this is not purely functional, but that's a whole other problem. So what we're going to get is essentially not a reference to a function, but the function itself.

[00:04:38]
So we have no reference to it, it's just a value. And we can see that little preview down there that we've got a function line. Sorry, it's a function that takes an argument line. But this is just a value, not a named value like with our function expression.

[00:04:59]
And that's fine cuz all we wanted to do was call it, like this. Same as we would call any function, because we got that value with the parens that said, hey, JavaScript, go evaluate this chunk of code. Might have been a variable, might have been some other thing.

[00:05:27]
[LAUGH] A little Easter egg on the, yeah, go looking for those funny memes. Anyway, via the value inside of it, JavaScript doesn't care about how you got to it anymore, all it knows is it has a value. And it can now do whatever you tell it to do only as long as it knows about that value, which is only, in this case, within those parens.

[00:05:54]
Okay, so this is all a little philosophical and whatever, but this, as I said, is a syntax that can be very confusing when you first run into it. But does crop up in production JavaScript sometimes because there are certain intricacies [LAUGH] of the language that don't allow certain things at the global scope.

[00:06:16]
So by scoping ourselves out a new little world, we can get around some things with these iifes. So this is all to say, JavaScript support's doing the same thing lots of different ways. Another way we can refer to that is it's a multi-paradigm language. So to keep with our theme of memes, the meme theme, if you will.

[00:06:42]
The handshake is like yeah, object-oriented programming, functional programming, what do they have in common? JavaScript, and a whole bunch of other stuff, but that's [LAUGH] beside the point. So this is not a programming paradigms course, although I do love talking about programming paradigms. This is not a functional programming or even a specifically object-oriented programming course.

[00:07:02]
But this is all to say that one of the things I think that makes life in the JavaScript universe, I was gonna say difficult, but maybe I just wanted to, richer and more complex and interesting. [LAUGH] Is that there are lots of different ways to do similar things, and there are lots of extremely different ways to conceive of doing different things in JavaScript.

[00:07:28]
JavaScript supports all kinds of different, well, especially these two different paradigms, and so the code you'll find out there might look totally different from the code you're used to writing. And it helps to know that both of these are kind of possible. This is all to say, what do you think, does JavaScript pick a side, objects or functions?

[00:07:53]
>> I mean, you said everything in JavaScripts and objects. So I'd like to say object. [LAUGH]
>> [LAUGH] What does co-pilot think? No, just kidding. [LAUGH]
>> [LAUGH]
>> And indeed, yeah, as you might have seen in a little preview Easter egg when we were talking about the heap earlier, it was all full of objects.

[00:08:12]
And yeah, that function value that came back, [SOUND] that's an object that's under the hood. No matter what we look at in JavaScript, if we pull its mask off, because we're meddling kids, we'll find an object. They're all different objects, but in JavaScript, pretty much all data is thought of as an object.

[00:08:37]
And that brings us to the OOP side of the coin. And yeah, speaking of accessibility, this isn't the best on this GIF here, but in other words, life is a prototype in JavaScript, it's true. Kind of everything comes down to prototypes. I just wanna check if we need a break for anything, or if anybody has questions?

[00:09:02]
Also on the interwebs, yeah?
>> Just a quick question about the paradigm styles. Which style would be preferred when we would write a pure function, functional or object-oriented?
>> So kind of the concept of pure functions is a big deal in functional programming, which if you are interested in programming paradigms, I do have another course about functional programming specifically.

[00:09:25]
But suffice it to say that in JavaScript, we're not usually doing the purest stuff. Now, what do I mean when I'm talking about pure functions? Well, a pure function is something that, first of all, does absolutely nothing else in the world than return a value. No logging to the console, no setting no timeouts, no none of this fetching data from the outside world and then posting to some other API, whatever.

[00:10:03]
None of that, all a peer function can do is return a value. And, to make matters even more constrained, all it can do to compute that value is look at the arguments that it gets. So that means, every time it gets the same arguments, it doesn't matter what the weather is, what date.now says it is, whether somebody's user agent has a problem with its dependent, whatever.

[00:10:33]
None of that matters, it's always going to return the same value if you give it the same inputs. In other word, it's deterministic. So when we're talking about functions in JavaScript, for example, this function that we just looked at here, Or this one even, which I [LAUGH] put the label functional programming on this slide, and the functional programmers among us will be like [SOUND] horrified because this is not a pure function, if we're using this to do something that logs to the console or what have you.

[00:11:20]
But that's why in this version we're using console log, and in this version we're just returning a string, which if we're entering this code in the console, we get the string out either way, so it's all good. But in JavaScript we're often writing functions with the function keyword or the arrow syntax that do stuff other than return things.

[00:11:41]
Sometimes we don't even have the return keyword because we're not trying to return anything, we're just trying to execute a bunch of instructions one after the other, do some imperative stuff. And those are all side effects, so then we're now not in the realm of functional programming. So if you wanna learn more about that stuff, there are resources, you can check out my other Frontend Masters courses, which have links to a whole bunch of other resources.

[00:12:04]
But in general, to go back to the question, if we're trying to write a pure function in JavaScript, we would be in the functional programming world. And even sometimes in what's called functional programming, like this little bling guy here that's logging into the console, not a peer function.

[00:12:25]
So we can have functional-ish programming in JavaScript and sometimes call it functional programming.