DI and actions

There are three equivalent entry points, and all of them run the same code:

• The Approvals facade — the shortest form and the recommended default.
• The manager, RoundlyConsulting\Approvals\ApprovalsManager — the facade root. Inject it through the constructor for the same API as an explicit dependency, with no static calls.
• Actions in RoundlyConsulting\Approvals\Actions — single-purpose classes with execute(), for composing into your own actions, jobs and commands.

Injecting the manager

use RoundlyConsulting\Approvals\ApprovalsManager;

final class ApproveInvoice
{
    public function __construct(private ApprovalsManager $approvals) {}

    public function __invoke(Invoice $invoice, User $user): void
    {
        $this->approvals->for($invoice)->as($user)->approve();
    }
}

Approvals::fake() swaps in a subtype of ApprovalsManager for the facade and for injected managers alike, so code written this way is recorded in tests too.

Calling an action

use RoundlyConsulting\Approvals\Actions\ApproveAction;
use RoundlyConsulting\Approvals\Actions\OpenApprovalRequestAction;
use RoundlyConsulting\Approvals\DataTransferObjects\ApprovalRequestData;
use RoundlyConsulting\Approvals\DataTransferObjects\DecisionData;
use RoundlyConsulting\Approvals\Enums\ApprovalRule;

app(OpenApprovalRequestAction::class)->execute(
    new ApprovalRequestData($invoice, [$a, $b, $c], ApprovalRule::Quorum, quorum: 2),
);

app(ApproveAction::class)->execute($user, $invoice, DecisionData::approved('LGTM'));

The manager resolves every action from the container too, so a binding you register for an action applies to the facade path as well.

Facade method → action

Every execute() signature and the DTOs the actions take are listed under Actions & DTOs.