This course contains good reference material, but does not reflect our current quality standards.
Transcript from the "Task #3 - Refactoring Details & Carousel" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Kyle Simpson: Let's look at step three. I want you to observe something, again, we're kind of trying to take a higher level view of what's happening here in this code. Okay, so don't get too much focused on the syntax and let's think more about conceptuals. What does the details js, what does the details module signify to you?
[00:00:26] What is its job?
>> Speaker 2: To display details.
>> Kyle Simpson: Display details, but really more just to manage the details page, right? What is the carousel modules job?
>> Speaker 3: Manage the carousel.
>> Kyle Simpson: Manage the carousel, right? So, would you consider it to be kind of a weird code organization if the carousel module had details specific code inside of it?
[00:00:54]
>> Speaker 3: Yes.
>> Kyle Simpson: That would look weird to have, if we're going to all the trouble to have separate modules, we want them to be independent, right? Same question, if I had carousel specific code inside of my details module, that would equally seem not appropriate. Would seem like too much mixture of the two, right?
[00:01:14] If we're properly structuring our modules we want to put code where it belongs, is the point I'm making. So, let's go back to our code and see the current state of things. Do you see anything inside of the details folder that looks like it's directly related to the carousel?
[00:01:33]
>> Speaker 3: We're searching for the-
>> Speaker 2: Items.
>> Kyle Simpson: Basically all of init. [LAUGH]
>> Speaker 3: Yes.
>> Kyle Simpson: Most or, these two lines, two of the three lines in init are related to the carousel, but we're dealing with them inside of the details module. The point I'm making is that even though this function, even though this code is functional, it gets the job done, it's kind of not organized well.
[00:01:59] It would be better if we could figure out a way to take the carousel specific code and keep it entirely within the carousel module, and keep the details code entirely within the details module. So, this next step of task three is to observe that that code belongs over in the carousel module.
[00:02:18] So the first thing I'm just going to do, is take those two pieces of code, I'm going to copy them, delete them, and I'm going to move over the carousel module and I'm going to put them in here, down here at the bottom. Just my first step of figuring out how to organize, because this is really where those belong, okay.
[00:02:39] Now, one thing right off the bat that I'll notice, which actually should have been a good clue to us. Remember I just moved in this items variable? We already have one, we're already getting the items variable. So we don't need this items variable anymore at all. That one is superfluous and unnecessary, which is a clue to us that it was not in the right place to begin with, if we had to do that that look up twice.
[00:03:03] Does everybody see that? So that should have jumped out at us before. But now that we're focusing on the right things, now we'll look at this and say, okay, so that stuff, I didn't even need it, but I do use the items thing to make my click handler.
[00:03:18] Now, I do have this problem, which is that the loadPerson function doesn't exist in this module. Where does it exist?
>> Speaker 3: Details.
>> Kyle Simpson: It exists in details, right. All right, now let's look inside of details and see, is any of this code related to the carousel, and any of the stuff inside of loadPerson, is that related to the carousel?
[00:03:46]
>> Kyle Simpson: I would suggest that line four is pretty heavily related to the carousel. Because we're looking specifically at a rel attribute of an item that sits inside of the carousel. So, everybody see that?
>> Kyle Simpson: So line four also looks to me to be a line that should move out.
[00:04:05] So I'm going to take it out for right now, okay? And I want to put it over here in the carousel, and I got to figure out where am I going to put it? Well, I need a function to go in place of loadPerson. So, why don't I call this one clickPerson?
[00:04:22] And the name here is important, because I'm suggesting that the carousel module does not actually care what happens after you click the person. That capability, that concern, belongs to the details module. The carousel just says, I just need you to be able to click something, I don't care what you do with it after that.
[00:04:44] Does everybody see that concept that I'm trying to get at? So let's call it clickPerson, because that actually signifies more directly what it's supposed to do. It is an event handler, clickPerson is an event handler, and that line of code needs to go right here. So everybody with me on that?
[00:05:06] And let's take that named function and use that in place, so we've got it now in place of loadPerson.
>> Kyle Simpson: Now, if we just left the code like this, nothing would happen, right? We'd pull out the ID, but nothing would happen over there in that other module. The details module wouldn't actually do the loading.
[00:05:29] So, let's consider what's happening over here in the details module. There's no more event, so this is not an event handler anymore.
>> Kyle Simpson: But what does this function primarily depend upon? There's one piece of information that it needs.
>> Speaker 3: ID.
>> Kyle Simpson: Everybody see that? It needs an ID.
[00:05:50] We've taken things where previously we had two different concerns packed together in the same function. We've now split them out into two separate functions, and separated them into two entirely different modules. That's a process that we call abstraction in programming, okay? So here, I have a loadPerson function that I should be able to call with any ID.
[00:06:13] It doesn't matter where the ID comes from, does it? I mean I could just call loadPerson three, and I would want it to load up the third person. So, from the perspective of the details module, he doesn't care at all where it comes from. And from the perspective of the carousel, he doesn't care at all what you do with the click.
[00:06:34] So, we can simply delegate that behavior by putting loadPerson on our public API. So if I put loadPerson on the public API for the details module, it means I'm not dealing with an event handler at all. I don't care where the loadPerson call comes from. It could come from a click event, it could come from an ajax, I don't care.
[00:07:00] It just comes from somewhere. So you just call loadPerson, that's my perspective in the details module. In the carousel module, I only care that you should load a person, but I don't care how that happens. I don't care about any of those details. So here, what am I going to do?
[00:07:15] I'm going to call Details.loadPerson. And what do I need to pass to it?
>> Speaker 3: The ID.
>> Kyle Simpson: The ID that I calculated.
>> Kyle Simpson: Way more important than the syntax of what I just did, is the concept of what I just did.
>> Kyle Simpson: Looking at a piece of code and analyzing, is this piece of code in the correct location?
[00:07:47] Maybe one of the most important skills that you can have as a developer in any language, but definitely in JavaScript. Looking at a piece of code and identifying, is this properly organized? Does it make sense for that piece of code to go here? It might be and here listen to me, it might be easier for it to be there but it might be conceptually wrong for it to be there.
[00:08:12] In fact, I would suggest in my career, been at this about 15 years, far more often than it ought to be, the easy spot is the wrong spot. Being able to look at a piece of code and think critically, does it make sense conceptually for that thing to be here?
[00:08:29] That's the organization skill that we're talking about. So what did I use to my advantage? Well, I used the idea that I know how to declare a function. I used the idea that I know how to call a function. And, importantly to our discussion, I used the idea that I know how easy it is to expose something on my public API.
[00:08:54]
>> Speaker 4: Just one thing, on line 14, we don't need items anymore. And details. Right? It's not used anywhere.
>> Kyle Simpson: That's correct. Yes, we're not using items anymore, so I can take that diversion out. Good catch. All right, just to make sure I didn't mess something up, let's test it.
[00:09:13] Test our code. We're not adding any new functionality, we're just improving the organization. Should still be able to click these and load them.
>> Kyle Simpson: [COUGH] This is a rabbit hole that could go way deeper in a normal application. I set this up that that's the end of the rabbit hole in that particular case.
[00:09:39] Because we've done basically the practical amount of refactoring that's necessary. You could do more refactoring, but you're not going to get as much of a payoff for it as we just saw there, the moving. So, I artificially constructed this problem so that you could see the solution and why the solution is useful, but it's way more important that you understand how I did that than what I did.
[00:10:01] How I thought about it, the questions that I asked, the tools that I pulled out of my tool box to make that happen. Maybe the most important thing I teach you all day long is that thinking, okay?