6.7 Using Route Guards

Hi folks, in this lesson we're going to take a look at route guards. Route guards are incredibly useful for testing whether or not a route can be loaded or unloaded, and this is exactly what we need right now. At the moment, as you might have noticed while we have been testing, one big problem that we have is that we can navigate straight to the game component without going to the start component first. So, we are currently on the start component. And if we click the button without entering a name, the validation will stop us navigating to the game component. But if we come up to the URL here, and if we just try to navigate straight to the game component, that works and we get an error in the console, so that's not great. It would be much better if users couldn't go to the game component if they haven't come from the start component. This is exactly the kind of thing that route guards are for. Let's see how we can use one to fix our current predicament. There are a number of different types of guards that we can use including CanActivate, CanDeactivate, CanActivateChild and CanLoad. We can use the CanActivate guard. Let's get started. Guards are typically implemented as services that we can inject into other services or components. Let's generate one now. We can put the new service in the _services folder because technically it is a service. We could create an _guards folder or similar if we were going to have a lot of them, but we aren't. So let's just put it in the generic services folder. We'll need to import the actual guard that we want to use. And in this case that's going to be the CanActivate guard. We'll also need the PlayerService here. The PlayerGuardService class will need to implement the CanActivate interface. Great, now, in order to implement the CanActivate interface correctly, the class should have a CanActivate method. We should also inject the PlayerService into the constructor. So Angular will invoke the CanActivate method to check whether or not the route can be activated. And the method should return either truth if the route can be activated or false if it cannot. We can just check the length of the players array in the PlayerService. If it's less than 2, we know the game component has not been accessed correctly. So now to use our new guard, first of all, we'll need to import the guard into our route module. And we can then add the service to the providers array. Now we need to add the guard to our root configuration, which is in app.routes.ts. Again, we'll need to import the guard service first. Route objects have a property called CanActivate, they have properties for all of the different guards. So, we can add our guard using this property and we want to add it to the game route The value of the canActivate guard property is an array. Okay, so let's test things out. So we're currently on the start screen. Let's see if we can navigate directly to the game screen. We can't go straight to the game screen now. The browser just stops loading at the root of the site. Good, so the guard is working. We can no longer go straight to the game component. We just need to arrange things so that the user is redirected to the start component instead of just hanging with nothing loaded in the home component. We can do this in the guard itself. We'll need to bring in the router to use the navigate method. So now before we return folks from the guard, we can navigate back to the start route. So let's try it out in the browser. So we're back on the Start screen. And if we try to go straight to the game component without first starting a game correctly, we'll just get navigated back to the start component again, awesome. So one point to note is that the guard we've built today is a synchronous guard, it doesn't need to do any additional processing or make any Ajax requests or anything else asynchronous. Guards often will need to be asynchronous, especially the CanActivate guard. Like when it is used to check, for example, that a user is logged in or something like that. In this scenario, instead of returning a boolean, the guard can return an observable instead. Routes can then subscribe to the observable to be notified when the guard does finally signal that the route can be activated or not. We still specified this type of guard in our route definition in the same way. We don't have to do anything special. So creating an asynchronous guard is almost just as easy as creating a regular synchronous one, like we have today. So, in this lesson, we saw how we can implement guards on routes, so that routes can only be accessed in certain situations. We saw that a route guard is really just a simple service which implements one of the guard interfaces. We saw that we should return true if the route may be accessed, or false if it should not. And we saw how to redirect the user to another part of the application in the case that the route cannot be activated. And we learned that we can also use asynchronous guards, we just need to return an observable instead of a boolean. Thanks for watching.