Transcript from the "Router" Lesson
>> Speaker 1: The router is an area of the app that few people have trouble with, but also few people understand deeply enough to take advantage of its true potential. So there's one router per app. Until we get engines, there's just one router per app. And the purpose of the router is to manage transitions between URLs.
[00:00:29] You can think of this as a finite state machine where essentially you're going from URL A to URL B and it will, based on the intent of the user to get between these two states, it will take you through a series of logical steps where you can do some important things.
[00:00:49] Most of your work will be basically filling in the blank for the router, which is that mapping of URLs to states. An additional need to get into it might be if you want to instrument page views in a single page app. Obviously pasting it in a Google Analytics snipit is not gonna fly because, technically, there is one page view for a single page app, and that's when you first enter it and load the page.
[00:01:15] So the router is what you would listen to monitor and beacon out information about that state. And there's a micro library at the core. This is one of those micro libraries that we went over, and it's called router.js. So you can think of it this way. The Ember.Router builds on router.js, and at its core is route-recognizer.
[00:01:40] I'm explaining this to you because when we start thinking about testing, we're gonna look at something else that also depends on toute-recognizer, and I wanna make sure you guys get the parallels between them. So here's how route-recognizer works, and there are some key takeaways here. One is how do we define paths, and these are an abstraction of a URL, right?
[00:02:04] So you see I've got things called route handlers and we will give it, we will give this route handler a name. Ember actually calls them routes as opposed to routers. And it's something that deals with being in that state or transitioning through that state. So in this case /posts/:id/comments.
[00:02:30] You can fill in that blank. You can fill in that ID with just about anything except a forward slash. So post/37/comments. That fits this first route handler. That matches it. You can have route handlers for static paths that don't have this blank to fill in. If I say dynamic segment that's what I mean.
[00:02:55] ID is a dynamic segment. And then finally we can use what we call a star segment, and this is another often overlooked and unappreciated feature of being able to work with the router. The differences between the star segment and the segment starting with a colon is that forward slash will be matched when you use this last one.
[00:03:22] And the use case here would be a 404 page, where you want, essentially, a catchall as the lowest priority route. If you make it through all of your routes, and they are prioritized in terms of the order in which you define them. So, if you're lowest priority catchall is something like this, potentially exactly like this, /startpath, and you say that goes to not found, then you've given Ember some way to handle everything, ultimately, if it makes it all the way down.
[00:04:04] So, and this is basically all route-recognizer does, you give it URL, it will return the first available handler. And again, order matters, it'll return the first available handler. So, higher up in the file is higher priority. What router.js adds to this is it makes the handler more specific and it builds it into this, it adds this concept of the state machine.
[00:04:36] It is super, super simple, and all I want you to really look at is most of this top left, we'll come back to this slide, but here I'm saying, if you give me post/id, which could be post/37, I want to deal with this by going to a route handler called showPost.
[00:04:58] And there is some mechanism for actually doing something with that information.