This course has been updated! We now recommend you take the Deep JavaScript Foundations, v3 course.
Transcript from the "Challenge 5: Module, Part 2" Lesson
[00:00:00]
>> Kyle: All right, let's move on to part 2 and part 2 is the more sophisticated of all three parts. So we're gonna spend more time on this one, and it's okay for you to take some time to try to figure this out. Let me orient you to what part 2 is saying.
[00:00:14] It was a good start for us to make an app module, but that is not really fully embracing what it means to modularize our code. To really improve this code, we really need to separate out the concerns into their different pieces. So we could make the observation that there are at least three different kinds of things happening in this application, three different categories of functions, if you will, or functionality.
[00:00:39] One category is a set of stateless helpers. For example, validateWorkEntry, formatWorkDescription, and formatTime, they don't rely upon any state at all. You pass in some data and you get some data back out. They are stateless helpers. They don't need any states, so they don't need to be collected into any particular module.
[00:01:01] So why don't we make a helper's namespace object for those to live on? And by the way, there are some constants that we have been including in our module definition which actually are stateless as well, they are part of what the helpers do. So those constants could be moved to that namespace object as well.
[00:01:22]
>> Kyle: That's the first part. The second part of part 2, call it 2.b if you will, is that we wanna separate out the UI related, the DOM related code from the data model related code. Right now, they're all conflated together. When you look at a function, it's doing both.
[00:01:40] We wanna create as clean a separation semantically between those as possible, that's the most true definition of abstraction. Abstraction does not mean hide things, abstraction means separate things, so that they're independently reasonable. So we wanna separate out the UI DOM related code from the data model related code.
[00:02:01] I've made suggestions on how to do that. First, we wanna make a function called setup ui, which makes us a ui instance, a ui module instance that has the following methods on it, in it, add project to list, add project selection etc, and then at the one we had before should only keep the stuff that's data model related.
[00:02:24] Now we'll have two separate modules, two separate behaviors, and they can call each other mutually. App can call the UI, UI can call the App, but we keep them in separate modules. So your app module is gonna store stuff like the state of the list of projects and within each of those projects, are the list of each of the work entries, that's the data model oriented state.
[00:02:52] That's what the app module does. The UI module on the other hand, needs to keep track of all the DOM elements that it's creating. So you don't want to store the DOM elements in the data model, and you don't want to store the data model in the DOM elements.
[00:03:07] So I make a suggestion here that in the UI, you wanna track all those DOM elements in a separate list, keyed by the ID of the data model entry that they come from. So the project id, the id that you would look up the DOM element in the project tracking object, same thing for the work elements.
[00:03:29] That's how you keep the data model and the UI model separate, a simple way of doing that, okay? So take some time to make sure you read through part 2, because there's plenty of details here and start working on that part of the project. We are gonna give you extra time, so 15, maybe up to 20, we'll see.
[00:03:47] Give you some time to work on that because this will take a bit more work. You're gonna have to go in to a function, and move some pieces out. You really shouldn't have to rewrite new logic, but there will be functions where in the same function, there's data model and UI stuff, and you're gonna have to separate those out and figure out how that works.
[00:04:05] So this is where the nitty gritty, this is where the rubber meets the road if you will. If you wanna be able to do modules, you have to know how to do this kind of refactoring, okay?