In this video, learn the fundamentals of the Laravel service provider stack, one of the most powerful tools Laravel gives you to customize each Laravel application and make it your own.
- [Instructor] A service container is Laravel's fancy and unique way to do dependency injection. What is dependency injection? It's the ability for us to inject or provide a class, or a dependency, into another class so that we can make it available for use. We'll build out an example to explain these concepts, so don't have any fear if that didn't quite make sense yet. First, we're going to see what a service provider is and how to use it. Laravel lists our available service providers in the App Providers directory. You'll see here that it provides a list of different service providers, including App, Auth, Broadcast, Event, and Route. The AppServiceProvider is the ability for us to provide services to the application. Inside of this file, there's two separate methods, register and boot. Register is used to register those classes that you want to make available inside of your Laravel application that are not dependent upon any other classes. Boot, on the other hand, allows you to define classes and make those classes available across your Laravel application that do depend on other classes for information. Again, that might not have made a lot of sense at this point, but we'll dive into some examples, and it should clarify itself. Let's create a new generic class that is going to send our notifications to our users for their upcoming reservations, using our console command. First, we're going to create a new directory in our app folder called libraries. After that, we'll create a new file in there labelled Notifications.php. We'll create the file like we do with all PHP files with our opening PHP tags. We'll add our namespace to it with namespace App\Libraries. We'll start defining our class on line four with class Notifications. And on line six, we'll add a very simple function with public function send(). Send will take no parameters, and all we'll have it do is simply run var_dump('notify'), just to verify that our function actually did something. We'll save this file now. So, we have a class that we can call, and we can envision this class as some notifications class that is actually going to call out to either our SMS library or our email library to actually send the notification. Now we want to be able to use this class inside of our email reservation command. We'll open that up with app, Console, Commands, EmailReservationsCommand. Now, let's not worry about trying to make this available at this point, let's just try using it. So, where do we want to use this? Well, if we scroll down to our handle method, we want to replace line 61 where we call this error line, with instead calling our notify class and calling the send method. So I replace line 61 and instead do this->notify->send(). So notify is going to be our notifications class and we'll just call the method send on it. Now, making this class available. There's a couple of different ways that we could go about this process. In Laravel, however, we can do this very simply using our app service provider. Let's open up that now in app, providers, AppServiceProvider.php. Remember, our register method allows us to register a service that isn't dependent on any other class. Our notifications class is a great example of this. So, how do we do this? What we're going to do is we're going to add, on line 16, $this->app->bind, we'll pass in a string, which would be the namespace path to our class with App\Libraries\Notifications, then we'll pass in a second parameter. This second parameter is where it's going to say we are going to bind that class path, App\Libraries\Notifications, to some particular class. We do that using a closure. This closure is going to be function, it will take a property called $app, and inside of this we just return a new instance of our notifications class directly. So, line 17 will just read as return new \App\Libraries\Notifications, our parentheses, and then a semicolon. This is a little bit of overkill for what we need in this case, but this is the basic use case of using a service provider and registering a class to be binded to a particular namespace path inside of our application. Now what do we do? We go to our command, we'll scroll up to our __construct method, and here on our __construct method, in the parameters list, we'll add in the path that we want to include. In this case \App\Libraries\Notifications, and we'll name this variable $notify. On line 32 we'll add $this->notify is going to be equal to the property notify. So, what we did is we set up a new notifications class, we told AppServiceProvider to bind any time that our Laravel application asks for a particular namespace path to return our instance of that notifications class. And here in our email reservations command, we're actually consuming that namespace path to our notifications class, and our service provider will provide that instance of notifications to us. Now let's try this out. We'll go to our terminal application and we'll run the command php artisan reservations:notify, and you'll see that we run our var_dump notify command out. At this point we've just started to scratch the surface of Laravel's service providers and its container, but now you should be able to inject some classes into your objects without needing to write instantiation code all over the place.
- Saving and viewing files
- Displaying validation errors
- Console commands, outputs, arguments, and inputs
- Building a Laravel route that has multiple parameters
- Working with the Laravel authentication system
- Preparing for deployment