QueueableJob Naming Convention

[yasalkhatib]

Problem:

Currently, when creating a queueable job using the command:
make:job --queue LogUserSearch user
The job class name will be as follows: LogUserSearchJob

Suggestion:

I would suggest changing the naming convention of queueable jobs to something like QueueableJob or QJob (LogUserSearchQueueableJob, or LogUserSearchQJob).
By this, the code will be more readable and clear. In addition, the developers will be aware that this job is queuable and hence it will run asynchronously.

[Mulkave]

Good idea! Will trt to collect some votes on this from our Slack workspace and move this to Ideas issue board.

[haralddoderer]

How about Prefix "Queueable" or "Queue"?
Or maybe put into a folder like QueueJobs?

I would certainly organize these types of jobs into a separate folder anyway to avoid mixing things or accidentally editing the wrong file.

[yasalkhatib]

Hello, Thank you for your response.

Distinguishing the job from a queuable job by name convention is a good idea. However, why do we need to let the job itself decide whether it is queuable or not?

Why not make every job as a queuable job and let the feature decide whether it should run this job in a queue or synchronously?

For example:
LogUserSearchJob
It could be run from a feature in the queue like $this->runInQueue(LogUserSearchJob::class);
And also it could be run synchronously like $this->run(LogUserSearchJob::class);

By this, you can have a job that can be run in a queue or synchronously, and the decision of that is made by the feature. In addition, it would be clear, readable, and predictable.

[yasalkhatib]

And of course, I would be happy to contribute to this awesome project.

[haralddoderer]

Hello, Thank you for your response.

Distinguishing the job from a queuable job by name convention is a good idea. However, why do we need to let the job itself decide whether it is queuable or not?

Why not make every job as a queuable job and let the feature decide whether it should run this job in a queue or synchronously?

For example:
LogUserSearchJob
It could be run from a feature in the queue like $this->runInQueue(LogUserSearchJob::class);
And also it could be run synchronously like $this->run(LogUserSearchJob::class);

By this, you can have a job that can be run in a queue or synchronously, and the decision of that is made by the feature. In addition, it would be clear, readable, and predictable.

I like that idea. That might give all Jobs some extra functionality.