[11.x] Introduce OnQueue and OnConnection attributes for jobs

[cosmastech]

The problem

PHP is weird about traits. If a class uses a trait, then it cannot re-declare properties from the trait with differing values. (Though if another class uses the trait and then you extend that class, you can 🙃)

This is problematic with setting queue/connections, where it would be great if we could just define the $queue and $connection properties.

An example with Queueable

class SyncAthletesJob implements ShouldQueue
{
    use Queueable;
    use Dispatchable;

    public $connection = "redis_medium";  // ❌ this doesn't work, as it differs from the definition in Queueable
}

Setting queue/connection is annoying

My jobs do not need to be dynamic in where they are dispatched. If it's a SyncAthletesJob, it's always on the import queue (and the import queue is always on the redis_medium connection, but that's not a problem solved here).

The two not-so-pretty ways of specifying this

class SyncAthletesJob implements ShouldQueue
{
    use Queueable;
    use Dispatchable;

    public function __construct(private TeamId $teamId)
    {
        $this->onConnection('redis_medium');
        $this->onQueue('import');
    }
}

// or when I call it
SyncAthletesJob::dispatch($teamId)->onQueue('import')->onConnection('redis_medium');

The solution

Introduce OnQueue and OnConnection attributes.

Now the above job can look clean 🧹 and I never have to worry about specifying queue/connection in calling code or inside of the constructor.

#[OnQueue(QueueEnum::IMPORT)]
#[OnConnection(QueueConnectionEnum::REDIS_MEDIUM)]
class SyncAthletesJob implements ShouldQueue
{
    use Queueable;
    use Dispatchable;

    public function __construct(private TeamId $teamId) { }
}

Bonus: when I call dispatch(new SyncAthletesJob($teamId)) I get the same benefit.

Follow ups

• Does this need added for queued event listeners as well? If so, we could share these attributes, but leaving them in Foundation/Bus doesn't really make sense.

• Additional attributes for #[OnDasher], #[OnDancer], #[OnPrancer], #[OnVixen], et cetera

[shaedrich]

An On prefix makes me think, it's an event listener. In would sound more naturally to me.

[cosmastech]

An On prefix makes me think, it's an event listener. In would sound more naturally to me.

But then how would I make my super funny joke about #[OnDasher], #[OnDancer]?

[shaedrich]

I see, touché 😂👍🏻