Another nifty new feature is the ability to resolve a service directly from your Blade view. That's a little weird. Let me show you what I mean. Imagine that, I don't know, imagine that you have some kind of class in your system that just shows statistics. For example, at Laracast, I have a class that just returns to me the total number of lessons on the site, the total hours of content, and things like that. So maybe we have a class called Stats, and I'll set the namespace for that, and class Stats. Okay, let's use that Laracast idea, the statistics for the number of lessons, and maybe this would perform some kind of DB query. I'll just hard code 450. All right, so we have our little service class here, and I will auto-format. Now, let's imagine that we want to use this within our Vue.

All right, so we have our little service class here, and I will auto-format. Now, let's imagine that we want to use this within our Vue. We know fresh out of the box we have that welcome view, so why don't we start there. And down here at the bottom, to simulate somewhat of a real project, maybe you include stats wherever you want to pull that in. Okay, so resources/views/stats.blade.php, and we'll just say stats, and then I'm going to echo out some kind of stats object, and then we want to call the lessons method on it. Great, so the only remaining step is, from our routes file, we could inject our stats, and then pass that through. So if I now put up a server and view this in the browser, and there we go, here's our output.

and then pass that through. So if I now put up a server and view this in the browser, and there we go, here's our output. Okay, so pretty basic stuff, right? Nothing new here. But now, imagine that there's some other area of your system where you also want to pull in those stats. So Route::get, other, and then run a function, and once again, return a view called other. Okay, so if we create that one, other.blade.php, I'll just hard code some full HTML in here, and once again, I want to pull in the stats. Okay, well, you see where I'm going here. If we now try to go to that other page, well, of course, it's not going to work,

Well, you end up in this situation where you keep having to inject this little service class just to pass it through to one specific view that requires it. Okay, so if you have any experience with Laravel, you know that one solution is to create a view composer. And it's just a way to say, when you're composing this view, or this view partial, I want to make sure that it has that set of data, like this. Maybe this is in a service provider. View::composer, and we're going to give it the name of the view that we import. And that's why it's really smart for things like this to extract them to their own partials. That way, you can bind directly to the view name, like this.

that page still works, and the homepage works. Okay, but still, we haven't touched upon anything new here. ViewComposer should be a refresh, if you have any experience with Laravel. But now, you might fall into this situation, where you create a ViewComposer specifically for the purpose of, kind of like this, just passing through some data. So, in these situations, well, yeah, you could create a ViewComposer, and create a ServiceProvider if you need to, and all of that work. Or, we could just inject the Service directly into your view. And in many situations, this is a smart idea.

Or, we could just inject the service directly into your view. And in many situations, this is a smart idea. Lots of people will tell you it's dangerous and a terrible idea. But you know what? We're all adults here, right? And we're smart enough to know when injecting something into a view really makes no difference whatsoever, and when it is appropriate to create a dedicated composer file. So, if I remove that, just for sanity check, this is going to fail. Okay, now, let's inject it into our view, like this.

So, if I remove that, just for sanity check, this is going to fail. Okay, now, let's inject it into our view, like this. Within my stats file, we're going to use this new symbol here, inject. And as the first argument, we're going to give the, basically what you want the object name to be, stats. Next, what is the class path that we will resolve out of the IOC container? App\Stats. And we're done, we have it. So, if I were to come back to Chrome, give that a refresh,

And we're done, we have it. So, if I were to come back to Chrome, give that a refresh, it works. And if I go to other, of course it works as well, because we've bound this stats variable directly into this view. So, anywhere you require it, well, this partial will have access to a stats object. And really, everybody, there's nothing more to it than that.