[12.x] Deferred Events

[dbpolito]

This introduces a new concept: Deferred Events.

Use Cases

When we need to listen do a model event that creates child records, let's think of the following scenario:

$parent = Parent::create();
$parent->children()->create();

Parent::created(function ($model) {
    $parent->children()->count(); // 0
});

Currently if you listen for Parent::created, the child will not be available yet, we would need to dispatch a event after the child is created, or dispatch a job and have after commit enabled.

With the new idea:

Event::defer(function () {
    $parent = Parent::create();
    $parent->children()->create();
});

Parent::created(function ($model) {
    $parent->children()->count(); // 1
});

This allows us to defer the execution of the events to after the callback is executed, ensuring that all related records are available.

This also might open a lot of other possibilities.

Thoughts?

[taylorotwell]

Thanks!

[donnysim]

I like the idea, but doesn't this create a situation where Model creating event will not be fired? there's a lot of situations where attributes are added or modified on creating, updating etc., and should fire no matter what, so Model wise these deferred events bring a lot of unforeseen problems. Am I missing something or is this unforeseen side of the feature?

[dbpolito]

True... i think there are situations where it may create some weird behaviors... but i think it feels clear what's going on... you're deferring all events... So use where it makes sense... But i do think it opens a lot of possibilities in several places.

[dbpolito]

@donnysim on second thought, this gave me the idea of adding a way to whitelist events to defer, which is implemented at #56566

Let's see how this one goes...