Transcript
  • Meteor

Routes and Controllers

Next, let's look at how routing and controllers help us to decide which template and layout to render to the page. Right now we're on the root URL. So up here in the browser on the root URL there's nothing after. And we're somehow deciding to render this template and this layout into the page. And the way that we're able to do that is by using iron router. So on the left in our code, I've opened up the routes dot js file. And let me talk you through this.

So notice first of all that we're in the app directory in the lib directory. And the reason for that is because the lib folder will run on both the client and the servers. So this JavaScript file is going to be available to us on the server and it will also be in the browser. It'll be available to us on the client. That way the browser and the server both know about all of our routes. And if we need to go to the server for a particular page, we can do that. Otherwise we can just stay in the browser without going back to the server.

So this routes js file was created for us by the iron tool. And up top, we're configuring the router with a couple of options, like the default layout to use. And notice this is set to the master layout template that we were just working on. And then we have two other default templates here for loading and not found, which we'll use a bit later.

Then down below we've declared our first route, which we didn't do, but the iron tool did for us. And what this is saying is for the root URL, use these options. And the options are we can refer to this route by name in our links by using this name home. And for this route, we're going to use an instance of the home controller, which is going to be in the controller's folder.

And on that home controller, we're going to call this function action. That's going to be a main function that gets called for this route here. And that this route should work on the client and not on the server. And this'll be the default. So by default, our routes work on the client. Now let me clear this up and we'll go take a look at the controller file.

Now, all the controllers go under this controller's folder, again in the lib directory so that they're available on the client and server. And if we click on it, I'll show you around this file. Now first off, controllers are intended to help us organize our applications. So as your app grows, it helps us to figure out where the logic in the app is going.

And the primary purpose of a controller is to take some data and combine it with a template to form the page. So it gives us a place to tie together the templates and data for the app. The way that you create a controller is by extending route controller. So we're going to use inheritance here. And we're going to inherit from this base class called route controller. So we call extend and we pass in an object of options, which will become methods or options on our home controller.

Now, the first option you might note here is layout template. So for a particular controller, we can specify that it use a layout for all of its actions. And so we're saying we want this controller, any actions or any routes they use this controller to use the master layout. The next option here is called subscriptions. And that's where we can subscribe to data. And we'll do that when we get to the collections and data part.

Then down below we have a function called action. And this is the default function that will get called for a route that uses this controller. And notice in our routes file we have the action specifically set to the action function. But this will be the default, so we don't even need to set this option here. Sometimes you'll have one controller that services multiple actions and that's why you're allowed to specify.

So this is the main function. This is the function that's going to decide what we render to the page, what kind of logic we execute, and so on. And what this is doing right now is just rendering the home template to the body. And it's doing that in combination with the layout, which is provided up here. And so this says render the home template into the master layout.

Now, one of the most important things to note about this action function is that it's reactive. And that means if we have some kind of reactive data sourcing here, if it changes, this function will re-run and we can choose to execute or render a certain template depending upon the state of our app. So for example, if the user's logged in, we might render one template, and if they're not logged in we render another one.

So to show you how this works, let me console log just the word action. And you should see that printed in the console over on the right when the app refreshes. So you can see this function has been run once. I'm going to do a little bit of trickery here with the depths package so that we can create a dependency that will be global.

So I'm going to say depth is equal to a new tracker dependency. And then I'll add a dependency here so that we can invalidate this computation. All right, if I say depth dot changed, notice the action function will run again. So what I've just done is made this reactive to this tracker dependency and shown that this action function can re-run multiple times.

Now, normally you wouldn't use tracker dependencies directly like this. Instead you might be using something like meteor dot user or grabbing a particular item with a collection. And all these will add reactive dependencies to this function and potentially cause it to run multiple times if the dependency changes.

So we'll have multiple controllers in this folder, one for each kind of major resource in our application. And we'll be creating more of those over time. And so controllers, again, provide us a way to organize our application and have all the logic for the page mostly in one place.