Alright, take a look at this one. So our homepage loads a welcome view, and if we take a look at that, we have nothing. So imagine you want to check to see if the user is a member. So if they're a subscribed member, then do something. Well very typically you'll do something like if auth()->check(), I don't know, and auth()->user()->subscribed, you know, something like that. And you may find that you're doing this all of the time. So what if instead we could turn that into a custom Blade directive really, really easily? Alright, well in 5.5 we can. So what if we just want to say something like member.

fail. Okay, let's get started. Now I'm going to go to my AppServiceProvider, and we'll put it within our boot method. So after all of the packages have been filtered through and registered in the container, now Laravel is going to filter through your providers and trigger a boot method. So here we're going to say this new one, Blade if, and the keyword we specified is member. So member, and now here we're going to return a boolean. So this, whether I return true or false, determines whether we trigger this logic or that. Okay, so I'll let you take a look at that. Blade if, you give it a directive name, and then you return a boolean.

Okay, so I'll let you take a look at that. Played if, you give it a directive name, and then you return a boolean. So if we switch over to Chrome and give this a refresh, it's still not going to load, and if this ever happens to you, just switch to the terminal and clear your view cache. Okay, let's give that another refresh, and we're all set. You are a subscribed User. However, if we return false, then we're going to see the else. How cool is that? It's so easy, and it took two or three lines of code. So yeah, in real life, you might do something like I said earlier, like return auth()->check().

It's so easy, and it took two or three lines of code. So yeah, in real life, you might do something like I said earlier, like return auth()->check(). If you just want a directive for being signed in, you could do that. So if we come back, we are just a guest, but yeah, if we were to fake that we were signed in, let's do this. Let's just say auth()->loginUsingId(1), just whatever the User of 1 is. So now if we come back and give it a refresh, now we're signed in. Remember, once again, we're just checking if you're signed in in this case. If you want to check that the User is subscribed in your app, then of course, I assume you would know what to do, something like, and the authenticated User is subscribed, whatever.

If you want to check that the User is subscribed in your app, then of course, I assume you would know what to do, something like, and the authenticated User is subscribed, whatever method you have on your User model that determines that. This is a nice way to take that bit of logic, you assign it a name, and now anywhere in your application, you can reference it. So now if you wanted to add another one, and once again, I'm just going to leave that as an auth check. But yeah, maybe you want another one now, like this could be for anything in your system that makes sense. Oh, and by the way, real quick, anything you pass here will then be available as a method.

All right, let's give that one a shot now. So it's basically the inverse of member, isn't it? So we could say if you're a guest, you are a guest, otherwise, you are a member. All right, so let's give that one a shot, we give it a refresh. Of course, both of them return that we are a member, but if we were to just force a log out there, well now we should get the opposite, and we do. All right, so that's all there is to it. You can now register any number of custom application-specific Blade directives in a matter of seconds.