this Exercise Solution

[00:00:00]
>> Kyle Simpson: All right, well, we're back to talk about the solution to this this-heavy exercise. Hopefully your fingers are not too worn out from typing this dot and .bind all over the place. So as the read me indicated, what we wanna do is we wanna reorient from the define workshop function making our object, and define our own objects.

[00:00:23]
So in a way, we really just need to copy all of these functions that exist down here. We need to copy all of them, and put them into an object literal. So I'll just start doing that. I'll say deepJS = an object literal. And then I'll just put all of my functions directly in here.

[00:00:40]
And in addition to that, I'm going to turn all of these into the concise method form, because I don't wanna do property assignments. So give me just a moment while I wire all these up. There's a lot of functions here, aren't there?
>> Kyle Simpson: All right, so we're gonna need commas in between all of them, so don't forget that.

[00:01:13]
>> Kyle Simpson: That is one nice part about the class syntax, is not having to deal with the commas everywhere. I will give them that, that was a good decision. All right, so let's take out function. And I'm just gonna do that with a replace.
>> Kyle Simpson: Put that one back.

[00:01:42]
>> Kyle Simpson: [COUGH] Okay, now we need to put the properties currentEnrollment and studentRecords, we need to put those on there. So we'll have currentEnrollment,
>> Kyle Simpson: Is an empty array. And studentRecords is an empty array. And now we need to start throwing in all our this dots everywhere. So anyplace that we reference a property that we were referencing lexically as a variable, or when we reference a function that's now a method, it needs a this dot in front of it.

[00:02:16]
So I'm just gonna write a lot of this dots over and over and over again. this.currentEnrollment. And then this.printRecords, with this.currentEnrollment. And this.currentEnrollment. And this.paidStudents. And this.print. And this.remind. And this.currentEnrollment. And this.studentRecords. matchId is an actual function in here, it doesn't need a this dot. this.getsStudentFromId. And then this dot, nope, not records, but this.sortByNameAsc and this.printRecord.

[00:02:58]
And none of those needed this dot, none of those. And this dot, and this dot, and this.getStudentId. And this.currentEnrollment. And this.currentEnrollment. Anybody tired of typing and seeing this dot in front of everything? This is a very verbose style of coding. [COUGH] We need this.notYetPaid. And this.printRecords. And this.getStudentFromId.

[00:03:36]
Now we need to take care of any places where we have method references that need to be hardbound. So let's go back through and find any methods that are getting passed in as callbacks. That's not a method that's a property, so that's fine. That's fine, that's fine, that one's fine.

[00:03:55]
That one's okay. Here we go, this.getStudentFromId, that's a method. So it's gonna lose its this binding, so we need a dot bind this.
>> Kyle Simpson: And then same thing here, sorting with the sortByName and then printing with printRecord. Those need to be bound. And then another one, needToEnroll needs to be bound.

[00:04:24]
And getStudentId needs to be bound, and,
>> Kyle Simpson: notYetPaid needs to be bound. And that should be it. Okay, so let's get rid of that factory function, cuz we're very much done with that now.
>> Kyle Simpson: Now that we have this deepJS object, these calls should basically be the same.

[00:04:56]
So if we were to run this code, we should still end up getting the same printout. So this was just an implementation change, not an outside change. So let's just try,
>> Kyle Simpson: Running over here in our RunJS environment.
>> Kyle Simpson: Uh-oh, I made a mistake, where did I call?

[00:05:27]
Yeah, I forgot, can't call defineWorkshop like that, oops. So let me go back.
>> Kyle Simpson: Have to take that out and put a semicolon there.
>> Kyle Simpson: Now let's see if that works.
>> Kyle Simpson: And there we go, there's our printout.
>> Kyle Simpson: So questions on our refactoring to that this aware style of coding, this namespace pattern?

[00:06:11]
>> Speaker 2: I guess given the kind of object design, object create pattern, would you pragmatically expect to have namespaced objects with this many methods in your own practice? Or would you try to break it down further?
>> Kyle Simpson: Yeah, I mean, generally speaking, if I'm gonna create an object, like a namespaced kind of a thing, the only reason I'm gonna go that approach instead of going the module approach is because I know I have two or three objects that I want to link through a prototype chain and have them work with each other.

[00:06:47]
So I'm gonna try to have those objects have their properly separated out behaviors rather than having one giant thing with the kitchen sink of everything in it. I'm gonna try these three separate objects that each do their own thing and they virtually compose through that call context. Okay, well, that hopefully was a bit enlightening on the this-aware coding, and some of the problems that you can run into.

[00:07:15]
They're not just with asynchronous callbacks and event handlers, even those callbacks that you pass into things like array.map, you have to worry about the this binding. So you need to be careful. I would say on the whole the amount of bind usage that I had to do here was on the borderline to where I would have said, this style of coding is not useful.

[00:07:37]
It certainly was very verbose to put this dot in front of everything. And I probably would have favored the module pattern for this particular kind of code, yes?
>> Speaker 3: What's the rule for binding this? Cuz sometimes it's using it and sometimes it isn't.
>> Kyle Simpson: Yeah, that's actually a good question.

[00:07:53]
So there's a couple of places. I'm glad you brought that up, there's a couple of places I should have gone back and said, do we actually need it? So for example, the sortByName, we don't need it because it doesn't make a reference to a this dot in front of it.

[00:08:06]
So here, that was actually unnecessary, and the same thing with printRecord. It was unnecessary there because we don't have any this references in it. So in order words, the answer to your question is, you only need to bind this if the method is a this-aware function. We have a few functions on here that are on the namespace but are not this-aware, and so they don't need a binding.