This course has been updated! We now recommend you take the Deep JavaScript Foundations, v3 course.
Transcript from the "Challenge 3: Solution" Lesson
[00:00:00]
>> Kyle Simpson: Okay, let's talk about the solution to exercise 3. If you read the Read Me, you saw that there were two items to address in terms of improvement. One is, were there function expressions, which probably made more sense as function declarations? The other one was could we take advantage of the hoisting and reorder the executable code to the top?
[00:00:20] So if we start out here looking, we notice that we have clearly functions all at the top. And if we scroll all the way to bottom, and this is where I execute accordance starting with these const. So what I would prefer to do, very simply is to take that code and literally just move it to the top.
[00:00:43]
>> Kyle Simpson: Now that it's at the top, my code is easier to read, because if I open this file I just need to look at that stuff at the top. And as soon as I get a little line, I know there's nothing else executable that's gonna show up below it, okay?
[00:00:57] So that's the first thing. The second thing now may have been a little less obvious. But I was kind of hinting here earlier that this function expression, even though I'm doing it with block scoping, which was an example of using block scoping. It really is a separate standalone activity and it's also multiple lines of code.
[00:01:17] Actually it would make a lot more sense for this to just be a stand alone function declaration, so we could promote that out to its own stand alone function. There's nothing in it that's requiring the context around it. So there's no particular reason why it needed to be embedded in the first place.
[00:01:35] Now I could have put it at the bottom of this scope. But again, there's no reason for it to be in that scope, so go ahead and put it at the outermost scope, that way we have. We'll talk about closure next, but we'll have less closure issues in the case of putting things out under their outer scopes.
[00:01:51] So, now I don't need this block scoping stuff at all anyway. And all I really need to do is just reference, submit NewWorkEntry.
>> Speaker 2: Are these instances where we could declare the functions?
>> Kyle Simpson: There was only one other function expression in the code base and it is this one, which is the sort time descending that I have over here.
[00:02:20] That particular function expression is just one line. I didn't find any benefit to making that its own standalone function declaration. That's a short enough function that essentially can be inline just fine. You could have moved it out but there's no particular benefit there.
>> Speaker 2: Sorry, I still don't quite understand
[00:02:41]
>> Speaker 2: When to make the call. To use hosting functions.
>> Kyle Simpson: I'm not sure I understand. Because there are two separate issues that apply, one is do I use the function expression verses the function declaration. That's okay. An independent question from, if I've used the declaration, should I allow it to hoist.
[00:03:06] So which one of those two questions is the one you have?
>> Speaker 2: The first one.
>> Kyle Simpson: The first one.
>> Speaker 2: Yeah.
>> Kyle Simpson: Should I use a function expression versus a function declaration.
>> Speaker 2: Yeah.
>> Kyle Simpson: For me, it's as simple as, this is a really short function
>> Kyle Simpson: This is a really short function, so I'm gonna make it an inline function expression versus this one up here was a lot longer.
[00:03:32] It was 10 or 15 lines of code. I think it needs to be its own declaration. It's just a stylistic preference. My tolerance level is about three to five lines of code in an inline function expression. There's lots of other little nuanced things that you'll have to develop your own style about and probably put into your style guide for your code base.
[00:03:50] But I don't like to nest within nest within nest within nest within nest cuz that's also a lot harder. So to whatever extent possible, if I'm having multiple layers of nesting, I'm gonna try to pull those out to their own function declarations. Generally speaking, I only nest something if there is really a reason to nest it, which one of the main reasons for nesting will be closure which is we're about to talk about.
[00:04:12] If this function needed to reference some variable from inside of this function, we would have needed to nest. And then it would be a question, do I need a function expression or a function declaration that's nested. But because it didn't even in the nest, I could just pull it all the way out to the outer scope.
[00:04:30] As a rule of thumb, I try to put functions at the highest level of the scope that they will behave correctly at, so that I have the least amount of unintended closure.