When working with Eloquent Fashions, it is not uncommon to faucet into the occasions dispatched via the Fashions lifecycle. There are a number of alternative ways you are able to do this, and on this tutorial, I’ll stroll via them and clarify the advantages and downsides of every one.
I’ll use the identical instance for every method so to see a direct comparability. This instance will assign the mannequin’s UUID property to a UUID in the course of the creation of the mannequin itself.
Our first method makes use of the mannequin’s static boot methodology to register the conduct. This enables us to work instantly on the mannequin and register the callback we wish to run when the mannequin is being created.
1declare(strict_types=1);
2
3namespace AppModels;
4
5use IlluminateDatabaseEloquentModel;
6use IlluminateSupportStr;
7
8class Workplace extends Mannequin
9{
10 public static operate boot(): void
11 {
12 static::creating(fn (Mannequin $mannequin) =>
13 $mannequin->uuid = Str::uuid(),
14 );
15 }
16}
This method is completely high-quality for small and simple reactions to mannequin occasions like including a UUID, as it’s fairly straightforward to grasp, and you may see precisely what’s going on on the mannequin. The largest subject with this method is code repetition, and when you have a number of fashions needing to assign UUIDs, you’ll do the identical factor repeatedly.
This leads us properly onto the second method, utilizing a trait. In Laravel, your fashions can inherit traits and routinely boot them in case you create a technique in your trait that begins with boot and ends with the trait title. Right here is an instance:
1declare(strict_types=1);
2
3namespace AppModelsConcerns;
4
5use IlluminateDatabaseEloquentModel;
6use IlluminateSupportStr;
7
8trait HasUuid
9{
10 public static operate bootHasUuid(): void
11 {
12 static::creating(fn (Mannequin $mannequin) =>
13 $mannequin->uuid = Str::uuid(),
14 );
15 }
16}
Utilizing a trait means that you can add this conduct to every mannequin that requires it and is straightforward to implement. My most important downside is that stacking these behaviors may cause points when a number of traits wish to faucet into the identical mannequin occasion. They start combating for precedence and may get messy fairly shortly.
This leads us to the subsequent choice, Mannequin Observers. Mannequin Observers are a class-based method to reacting to mannequin occasions, the place the strategies correspond to the precise occasions being fired.
1declare(strict_types=1);
2
3namespace AppObservers;
4
5use IlluminateDatabaseEloquentModel;
6use IlluminateSupportStr;
7
8class OfficeObserver
9{
10 public operate creating(Mannequin $mannequin): void
11 {
12 $mannequin->uuid = Str::uuid();
13 }
14}
This class will have to be registered someplace, in a Service Supplier or the Mannequin itself (that is the place I like to recommend it). Registering this observer within the mannequin gives visibility on the mannequin stage to the unwanted effects that change the eloquent conduct. The issue with hiding this away in a Service Supplier is that except everybody is aware of it’s there – it’s exhausting to find out about. The largest downside of this method is its visibility. In my view, this method is implausible when used appropriately.
Yet another manner you may method this drawback is to benefit from the $dispatchesEvents property on the Eloquent Mannequin itself. This can be a property on each Eloquent Mannequin that means that you can checklist the occasions you wish to hear for and a category known as for these occasions.
1declare(strict_types=1);
2
3namespace AppModels;
4
5use IlluminateDatabaseEloquentModel;
6use IlluminateSupportStr;
7
8class Workplace extends Mannequin
9{
10 protected $dispatchesEvents = [
11 'creating' => SetModelUuid::class,
12 ];
13}
The SetModelUuid can be instantiated in the course of the lifecycle of the Eloquent mannequin and is your probability so as to add conduct and properties to the mannequin.
1declare(strict_types=1);
2
3namespace AppModelsEvents;
4
5use IlluminateDatabaseEloquentModel;
6use IlluminateSupportStr;
7
8class SetModelUuid
9{
10 public operate __construct(Mannequin $mannequin)
11 {
12 $mannequin->uuid = Str::uuid();
13 }
14}
This method is without doubt one of the cleanest and best to grasp, as there’s loads of visibility on the mannequin, and you may simply share this class throughout fashions. The largest subject you’ll face is that if it is advisable set off a number of actions on a mannequin occasion.
In conclusion, in all honesty, there isn’t any proper manner to do that. You’ll be able to select any of the above strategies, and they’re going to work, however it’s best to select the one that’s best for you and your particular use case. I wish to see extra choices round this specific performance.
For instance, an observer is an effective choice if it is advisable add a number of properties to a mannequin on mannequin occasions. Nevertheless, is it the most suitable choice? How about if we used the dispatch occasions property to run a customized pipeline for that mannequin?
1declare(strict_types=1);
2
3namespace AppModelsPipelines;
4
5use AppModelsOffice
6
7class OfficeCreatingPipeline
8{
9 public operate __construct(Workplace $mannequin)
10 {
11 app(Pipeline::class)
12 ->ship($mannequin)
13 ->via([
14 ApplyUuidProperty::class,
15 TapCreatedBy::class,
16 ]);
17 }
18}
As you may see, we will begin to use pipelines so as to add a number of behaviors to mannequin occasions. Now, this is not examined, so I have no idea 100% if it will work – however as an idea, it might open up a composable method to reacting to mannequin occasions.
How do you deal with mannequin occasions in your Laravel tasks? Tell us on Twitter!
