Laravel Actions
This episode is for members only

Sign up to access "Laravel Actions" right now.

Get started
Already a member? Sign in to continue
Playing
03. Resolving actions from the container

Episodes

0%
Your progress
  • Total: 1h 2m
  • Played: 0m
  • Remaining: 1h 2m
Join or sign in to track your progress

Transcript

00:00
One of the benefits of actions that we've already spoken about is that they're easier to test. So even if you did want to use them in the controller like this, or in a controller like this,
00:10
that's absolutely fine. But there's one way that we can grab these out of the container, which makes a little bit more sense, and it tends to read a little bit better as well. So let's go ahead and do this just to tidy this up,
00:22
and we're going to go ahead and take createPost, we're going to inject it into here instead, give it a name, and then use that to run the action. So a very, very simple change, but something that makes a little bit more sense in terms of passing particularly dependencies
00:38
down to other classes where you are going to be using actions within other classes. So what we're going to do here is we're just going to go ahead and reference createPost, and we're going to call this createPost. Now the naming convention I tend to use here is give this the exact name
00:54
of the action you have created, because then createPost is very, very clear here. So we're just going to swap this out here with createPost, and we're just going to invoke run inside of here. Now doing this in a controller is fine,
01:08
because we would probably test the controller at the controller level to check validation, check that this was created. But if you were passing through the createPost dependency to another class, or if you were retrieving this from the container from within another class,
01:25
then it makes a lot more sense to pass these into a kind of constructor or invoke. So let's head over really quickly and just say post to create this out, and of course it works in exactly the same way, and we have that post created inside of here.
01:40
Of course what you could also do if you needed is apply this to the constructor. So you could take this if you had other methods within a controller, for example, that made use of creating a post. You could just go ahead and either say public createPost or protected getPost,
01:57
depending on the PHP version you're using, or inject that in and then go ahead and assign it with this and createPost like so. Again, depending on the PHP version you're using. I'm just going to go ahead and use construct a property promotion
02:12
to apply the visibility I want to see. I don't need to define this as a property now, and that's now going to be available. So what we could now do is say this createPost,
02:20
and that's going to work in exactly the same way. So if we come over here and just say post three, sure enough, as you probably already guessed, this works in exactly the same way.

Episode summary

In this episode, we take a closer look at how to resolve (or grab) action classes from the container, rather than creating them directly in your controllers. This is a small tweak but it brings a lot more clarity and maintainability to your code, especially when your project starts growing.

We'll start by showing how you might typically use an action straight inside a controller, but then we refactor it to inject the action—like CreatePost—directly from the container instead. This approach not only tidies up how dependencies are managed, but also sets us up for cleaner and more testable code.

We discuss some naming conventions to keep your code readable (naming the injected action exactly what it is), and you'll see how this pattern shines if you need to use the action in multiple places, like inside a class constructor, or if you're grabbing it for another service.

Lastly, we walk through updating the controller to use constructor property promotion (if your PHP version supports it) to make dependency injection even cleaner. Everything still works as before, but now the code reads better, is easier to test, and sets up a solid pattern for future development.

Episode discussion

No comments, yet. Be the first!