-
-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Concept: Configurable behavior on event dispatching #145
Comments
1. Love global jobs connectionAdd return [
// ...other config fields
'jobs_connection' => null,
]; Right now its fine because we have only 2 listeners, but later it might be an issue when only some jobs will require to work synchronously. Pros:
Cons:
|
2. Queue options in configAdd return [
// ...other config fields
'jobs' => [
Cog\Laravel\Love\Reactant\Jobs\IncrementAggregatesJob => [
'connection' => 'custom_connection_name',
'queue' => 'custom_queue_name',
'timeout' => 60,
'delay' => 90,
],
Cog\Laravel\Love\Reactant\Jobs\DecrementAggregatesJob => [
'connection' => 'custom_connection_name',
'queue' => 'custom_queue_name',
'timeout' => 60,
'delay' => 90,
],
],
]; Pros:
Cons:
|
3. Love jobs config registryAdd return [
// ...other config fields
'jobs' => [
Cog\Laravel\Love\Reactant\Jobs\IncrementAggregatesJob::class => App\Jobs\Love\ReactantIncrementAggregatesJob,
Cog\Laravel\Love\Reactant\Jobs\DecrementAggregatesJob::class => App\Jobs\Love\ReactantDecrementAggregatesJob,
],
] or return [
// ...other config fields
'jobs' => [
'reactant_increment_aggregates' => Cog\Laravel\Love\Reactant\Jobs\IncrementAggregatesJob::class,
'reactant_decrement_aggregates' => Cog\Laravel\Love\Reactant\Jobs\DecrementAggregatesJob::class,
],
] or return [
// ...other config fields
'jobs' => [
'reactant' => [
'increment_aggregates' => Cog\Laravel\Love\Reactant\Jobs\IncrementAggregatesJob::class,
'decrement_aggregates' => Cog\Laravel\Love\Reactant\Jobs\DecrementAggregatesJob::class,
],
],
] Pros:
Cons:
|
4. Love event service providerIntroduce final class LoveEventServiceProvider extends ServiceProvider
{
public function boot(): void
{
Event::listen(ReactionHasBeenAdded::class, IncrementAggregates::class);
Event::listen(ReactionHasBeenRemoved::class, DecrementAggregates::class);
}
} For example if you want to update reactant counters synchronously you could follow 3 easy steps.
"extra": {
"laravel": {
"dont-discover": [
"cybercog/laravel-love"
]
}
},
$this->app->register(\Cog\Laravel\Love\LoveServiceProvider::class);
IncrementAggregatesJob::dispatch()->onConnection('sync'); Pros:
Cons:
|
How could we override what will happen on Love event will be dispatched?
This question was raised many times before. Each time I've returned to it a new ideas come into my mind but all of them have their pros and cons. Finally I've got all pieces together and ready to share with my vision.
Thanks to Pavel Volkov @volkv for helping me out with better solution.
First, we should encapsulate increment & decrement logic in jobs. Because we will be able to run those jobs from any place in any time without dispatching an event (which may be listened by many listeners at moment). Listeners will become very simple and synchronous but they will dispatch queued jobs.
Second, we should have more control over the queue. Because developers should be able to choose if they want to use stock package behavior or they want to modify it to their application requirements.
I've designed 4 different implementations of the second part. Each implementation will be described in separate comment.
Spoiler: 4th solution will be implemented #145 (comment)
The text was updated successfully, but these errors were encountered: