Ember's routing layer provides some powerful primitives for making sure our app is URL-driven. We'll build up a mental model for Ember's hierarchy of routes and transitions between them, and quickly move on to more advanced topics like redirecting users and preventing "logged out" users from entering certain parts of the app.
We'll introduce a few of Ember's routing hooks, and use them to ensure that only "logged in" users can make it into the chat portion of the app, and only "logged out" users can make it to the login page.
RoutingNested Routes and URL-driven State
Most apps render different data for different URLs, so it logically follows that Ember's routing layer should be driving data retrieval and providing it to templates for rendering. We'll set up a more complete routing structure for our app, such that URLS such as
/teams/linkedin/channels/generalwill load the appropriate data. Then, we'll pass that data through appropriate components so we can see differences on the screen as we navigate between teams and channels.
Now we're ready to get rid of our hard-coded fixture data, and replace it with data retrieved from API calls. We'll use the isomorphic
ember-fetchpolyfill and demonstrate that, due to Ember's promise-aware route hooks, very little needs to change outside of our routing layer to get back to a working state.
There are some routes in our app that take us into a "half-loaded" state where some content is missing. We'll look at how we can use
transitionTowith Ember's route hooks to ensure that any reasonable URL takes the user to an appropriate place.
RoutingSimulating API responses in Tests
Now that we're really retrieving data, we will want to start mocking HTTP responses so that our tests aren't sensitive to data changes. We'll look at the Pretender library, and how we can use it to set up a fake HTTP server that intercepts fetches before they are made, responding with a prescribed body and status code.