This course has been updated! We now recommend you take the Ember Octane Fundamentals course.
Transcript from the "Routes as a Hierarchy" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Mike North: So, next, this is what the Ember Router looks like. Much cleaner, and essentially here you're going to have these URL's that are shown to the right in comments. That is what Ember will actually understand. These are example URL's that match each route. So, we can go to slash, which I'm calling an implied index.
[00:00:33] The way to think about that is if you go to frontendmasters.com/ what is the file that comes back? And then some more stuff below that you can start to see how I'm establishing a hierarchy here. What I want you guys to notice, and this is another convention over configuration feature, I don't have to explicitly define the path for anything except the route called post.
[00:01:25] And the reason is, the implication of not defining it is that you should just fall back onto whatever the name of the route is. So posts, it understands that slash post is what I want, I've not superseded the default configuration there. So keeping this in mind, I want you guys to think of, I want to illustrate what's actually happening under the hood here.
[00:01:54] So, hierarchical routing means that there are multiple routes active forming a particular URL. And often times, each route that's active will correspond to some piece of the URL itself.
>> Mike North: I also want you guys to notice that I've got this application node here at the root. That's sort of the overarching route that is always active as soon as the user enters your application, and it never really goes inactive until the user closes their tab.
[00:02:30] But it is not, regardless of URL, application is still sort of the outer wrapper. And when we start seeing parallels between a template that's rendered, and a route that's active, application is sort of the wrapper for your whole app. If you have a nav bar that is always present on the screen at all times, you would put that in the application template.
[00:02:54] Because that's sort of no matter what, that is the outer most wrapper. And you can see on the top right there what I'm illustrating here is what will appear on the screen, which templates will be rendered, and you can see here if I'm going to /, right? Application is active because application is always active.
[00:03:16] Index is active under application because that's sort of like index.html. That is the default. Now if I go to /posts/, what ends up happening is we pivot on application. And you can see that what's rendered changes. So instead of looking at index, which is the root file there, we're looking at posts and then the index within posts.
[00:03:44] So, and I've added a slash to the URL here, which is optional but that's so we understand like, index.hbs, the handlebars follow index, is analogous to index.html. So if we pivot again and go to post /index. Remember that when we define post, we had this route with the dynamic segment in it, it was post slash colon ID.
[00:04:14] And so, here we're actually have the context of an individual record potentially this is one blog post. And then if we decide we want to look at the comments on this post, you can see that the blue, I'm alternating back and forth to show the difference between these two states here, but you can see the blue post template remains active.
[00:04:38] Oops. And the key understanding there, the key thing to understand is that it will not reload it. It will not have to do anything, because all that's changing are its children. And the magic behind this in a template is this handlebars helper called outlet, and when you put outlet in a template that's essentially saying child views go here.
[00:05:23] So if you have a table like a master detail view where you select a record and you see some details, you would want to place like the details view somewhere. So that as you click around, as the URL changing as a result of your clicking, you know you have control over where that surrendered.
[00:05:43]
>> Mike North: So, now we kind of understand that there is the state machine here, it's strongly connected to URLs, and there's parody between the hierarchy of routes and the hierarchy of templates, each of which corresponds to a route. So, actually I should say that the other way around. Each route has a template associated with it, you can have many more templates, but each route has a template associated with it.
[00:06:11] The last thing we need to know before we jump into coding is how do you create links in templates that will, when clicked, trigger transitions between these routes. And you do that with this ember helper called link 2. The reason that we have to do things this way is because if we used an a tag, an anchor tag, the browser will be what is handling that.
[00:06:39] Right. The browser will handle that, and you do not want a pageload to actually happen and to reinterpret your JavaScript. Even if it's cached, it still takes some time. So, this is sort of an Ember specific concept for an internal link to another page within your app. And you can see with these two examples, the top one is going to a static route, right, it's going to just index, going back home.
[00:07:05] That would take you to /, right. And this second example is going to the post.comments route. And that is this here, right, post.comments, that's the way that you describe this particular state here. And we're passing some data to populate this dynamic segment. So this would be, basically, let me see the comments on post 31.
[00:07:37]
>> Speaker 2: Before you had a couple of slides back, you had comments kind of wrapping around posts. And that led me to think that I would see a route called application comments posts, but that's not what I saw.
>> Mike North: Good question. So, I'm going to take you back. You probably want to see this slide here, right?
[00:08:01]
>> Mike North: So, you can't really transition to application. You can't even really, what's the right way to say this, the application route itself does not correspond to a particular URL. It is present for all URL's. So, you don't really refer to it when building links. When I say posts dot comments, the reason I say this is because if we look at what I've define here.
[00:08:36] It is just parent dot child, and when I say child, I mean that author and comments are defined within this function that I passed to post. Does that help add some clarity here?
>> Speaker 2: I think you will later.
>> Mike North: So I want to actually go through some examples and code a little bit for you guys before we get started, just to make sure we hammer this home.
[00:09:07]
>> Speaker 3: Couple questions. They're asking about when you're defining this .route host and in the path. They said that sometimes they see it with a leaning slash, and not a leaning slash, does it matter?
>> Mike North: So we're talking about the link two helper here I guess?
>> Speaker 3: No, the last slide that you were on.
[00:09:24]
>> Mike North: I see. So, I'm not sure, I don't believe it matters.
>> Speaker 3: Okay.
>> Mike North: I would avoid the leading slash just because I don't see that around. And staying aligned with the common use will help you steer clear of annoying little edge cases.
>> Speaker 3: And the the second question is on the plural versus singular on the posts, what's the standard that the ember community is following?
[00:10:01]
>> Mike North: Right, so it would be the way I define it here, and you'll see that there are more important things to pay attention to. Mostly, how do you want to structure your templates? You see that because there's parity between the routes, and thus sort of the URLs, and what's showing up on the screen, you kind of have to understand you know, what should stay on the screen, what's common between these two URLs verses what changes.
[00:10:31] When I'm designing my routes, when I'm figuring out what should be a child of what, that is a stronger influence on how I set things up rather than singular verses plural. That being said, what I have here is, I believe, the advised idiom where you have separate routes for handling a list of posts.
[00:10:47] And then as a sibling, handling a single post, and then as a child of that, everything that relates to that single post. And hopefully, you'll see how that kind of falls through and becomes nice as we jump in.