Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
by
FREELessons:16Length:1.8 hours

Next lesson playing in 5 seconds

Cancel
  • Overview
  • Transcript

3.3 Wiring Up More of Our Modules

We've got a number of different modules now, but not all of them are being used. Let's continue to build up the functionality of our to-do app and start using the remaining modules.

3.3 Wiring Up More of Our Modules

Hey there. In this lesson, we're gonna continue wiring up some of the modules that we haven't made use of yet. We'll start out by wiring up the two buttons in our app's header. The first button is the button to create a new list, which by default is disabled. So let's get that working first of all. So to do this, we're going to need to update the list view model. [BLANK_AUDIO] So now we need to enable the button whenever the user types into the first text input. So we'll need to add a value binding to the input in the view. [BLANK_AUDIO] So then in the app view model, we can add a new observable for this property. [BLANK_AUDIO] And we'll just set that to an empty string to start with. So now we need to link the enabledness of the button to the value of the input using a Knockout computed observable. [BLANK_AUDIO] So all we do is check whether the list name property is an empty string. If it's not, we enable the button. And if it is, we disable it. We can pass the value for this into the computed method as the second argument. And this will be an instance of the view model. So inside the computed function, we can refer to this without losing track of it. Great, so now we need to set up the list view model. This module, which is list.js in the view_models folder, will also need to use Knockout and the the ui_strings' module, so let's add these as dependencies first. [BLANK_AUDIO] So now we can add a constructor for the listViewModel. [BLANK_AUDIO] As before, we can add a few basic properties to it. [BLANK_AUDIO] We'll also want to do some similar things in the listViewModel that we did in the appViewModel, like disabling the add task button until the task name input has had text entered into it. [BLANK_AUDIO] And lastly, we can return the constructor once again. [BLANK_AUDIO] Okay, so the list view model will be a property of the app view model. So back in the app.js file, we'll need to load the listViewModel module. [BLANK_AUDIO] So now we can add a couple of bindings to the list view that references the listViewModel via the appViewModel. [BLANK_AUDIO] This should allow us to display the name of the list in the lists heading. So now we just need to render the list, which should happen when the add list button is clicked. We can add a click binding to the button that gets the name for the list and passes it to the method in the listViewModel to create a new list. We can do this in the view model for the app since the button is an app-level control. We'll need the list_manager, the list view and the renderer modules here so we can load these dependencies also. [BLANK_AUDIO] So first of all, we want to add the main button method, which will be a plain function, not a computed observable or any other Knockout construct. [BLANK_AUDIO] So all we do is create a new list and a new listViewModel. We can then set some properties of the view model, including setting the listName observable to the list.id, and storing a reference to the list in the list property. We can also clear the listName input and then render the view to the container with our renderer module. You'll notice that we're using this rather a lot inside the addList function to refer to the appViewModel. But if we're inside a plain function like this, the value of this will change and will no longer refer to the appViewModel. Rather than having to create a self variable at the top of the appViewModel and then use this extra variable inside the event handler, we can use JavaScript's bind method to set the value of this inside the handler function to what we want, which is the appViewModel. This is the perfect use for bind because we can carry on referring to this as we have done throughout the view model and know exactly what it refers to. And this way, the addList method does all the work, but we won't bind to it from the app directly. Instead, we can create another property of view model, which will contain the function returned by the bind method. [BLANK_AUDIO] From the app view, we can then bind to the addList handler method. [BLANK_AUDIO] So now we can add the placeholder text for the new task input placeholder and the labels to use as the button text for the two buttons in the list view to our ui_strings module. [BLANK_AUDIO] And lastly, we can add the bindings that we need to the list view. [BLANK_AUDIO] So notice how we reference the view model for the list via a property of the appViewModel. Pretty neat, huh? So at this point, provided we set everything up correctly, we should be able to visit the page, enter a name in the inputs. And when we hit the button, we should see the listViewModel appear on the page. And if we enter some text into the new task input, the add task button should become enabled. [BLANK_AUDIO] So we should probably provide a way to remove the list again. The easiest thing to do is just overwrite the existing list with a new list if the Create list button is used a second time. So we can add a simple removal method to our appViewModel. [BLANK_AUDIO] So this method receives the list container as an argument, and inside, we just need to use Knockout's cleanNode method, passing it the container. This will remove the bindings on the existing list. And we then set the inner HTML property of the container to an empty string. So we can call this method in the addList method just after where we select the container from the page. [BLANK_AUDIO] So it's been a slightly long lesson this time due to the amount of wiring up that we've had to do and we still have to do in fact. While we haven't focused on anything particularly Require-based, we have continued to build up our AMD modules. As the code base grows, I'm sure you, you'll agree that the modular structure of the source files keeps our code organized. And this is a valuable lesson in itself. Thanks for watching.

Back to the top