A couple days ago at the time of this recording, I was talking with a few friends on Twitter about invokable classes, and it occurred to me we've never even once covered it at Laracast. So let's fix that, even though you won't reach for these too often, I'll warn you ahead of time, but it's a good tool to have in your belt for those one-off occasions where it makes good sense for your project. Okay, so an invokable class is very simple. It's a class, we'll give it Example, and we're going to add a magic method here called __invoke. Now, any time you try to interact with an object as if it were a function, so you create an instance of Example, like this, and we'll save that. Now, if I try to interact with that instance as if it were a function, well, if you define an __invoke magic method, it will be triggered automatically by PHP. So if I were to say hello world, and we return that, if we run this in the browser, we should see hello world. Let's

invoke magic method, it will be triggered automatically by php. So if I were to say hello world, and we return that, if we run this in the browser, we should see hello world. Let's switch over, and there we go. It works. So really, it's very, very simple. Once again, you want to interact with an object as if it were a function, well, you need to define an invoke magic method here. Otherwise, everything's going to blow up, of course. So this means if you want, you could take advantage of Laravel's automatic dependency injection. You could do something like that. So now, behind the scenes, Laravel will automatically instantiate example, and then once again, we will interact with it as if it were a function, and that works. So often, a use case for this is people like invocable classes when they don't necessarily want to add a generic method name on it. So if you've ever seen things like a class that has

So often, a use case for this is people like invocable classes when they don't necessarily want to add a generic method name on it. So if you've ever seen things like a class that has a get method or a fire method or a run method, well, before you would instantiate it and then say example->run(), and this will get the same thing, of course. But some people, it's just a preference thing. Some people, if they find themselves reaching for that generic name, they will instead make it invocable and then just interact with it like so. And we've already proven that this does work. All right, does that all make sense? So a few use cases you might consider. We could say routes, let's clean this up, and we're going to give it a HomeController here. Now, this doesn't exist, so let's go very quickly and create that. Make me a controller called HomeController. And, oh, whoops, it's squawking because that doesn't yet exist. Okay, so bring

Now, this doesn't exist, so let's go very quickly and create that. Make me a controller called HomeController. And, oh, whoops, it's squawking because that doesn't yet exist. Okay, so bring that back, get rid of our example, and if I now switch over to HomeController, we're going to have the exact same thing. So we're going to add an invoke method here, return HomeController. Yeah, so a lot of people, I will warn you, I'm not the biggest of fans of this, but a lot of people like the idea of having a single class per controller action. So if you have an action that you want to respond to, they will upgrade that to its own class. So once again, just a preference thing. I'm not a huge fan of it, but if you do find a situation where it really fits your application, then this is something you could very much do. So let's give that a run, refresh, HomeController action. So once again, we pass a string here with no action name,

application, then this is something you could very much do. So let's give that a run, refresh, HomeController action. So once again, we pass a string here with no action name, and Laravel will pick up on that, and we will invoke the class. Once again, this is a good use case if you have a single use controller. There's only ever going to be one action on it. Yeah, that's something you might consider. Now, another option that we were discussing on Twitter would be for things like query objects. So if you're not familiar with a query object, think of it as a first class citizen for a database query. So for example, let's go into our app directory, and let's set up a new queries. And the example I used was FeaturedCollectionsQuery. Just something specific to your application where the query's a little complex, and you don't want it in the controller. You don't want to put it as a method on your model. So we will upgrade

query. Just something specific to your application where the query's a little complex, and you don't want it in the controller. You don't want to put it as a method on your model. So we will upgrade it to a first class citizen and give it a nice name that we can use anywhere we want. So let's set this up, namespace app\queries, and FeaturedCollectionsQuery. Now, this is another example where you often create a method like get or run, and then here's where you would perform your complex query. I'm just going to dd(running the complex query) since we don't have anything really for this example app. All right, and that's a query object. So a class that wraps a single database query that has a nice name. Okay, so we're going to come back here, and we'll say return, and let's do this. Let's resolve FeaturedCollectionsQuery, and we will now run it like so. So let's come back, give that a refresh, and now we get running the complex query.