Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

Das ResolverInterface im Detail: Context, Field, Args, Value verstehen

Das ResolverInterface im Detail: Context, Field, Args, Value verstehen

~8 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026

Alle bisherigen Kapitel haben resolve() bereits benutzt, ohne jeden Parameter einzeln zu erklären. Dieses letzte Kapitel von Block 3 schließt diese Lücke - solides Verständnis aller vier Parameter ist Voraussetzung für das Veranstaltungen-Projekt ab Block 4.

public function resolve(
    Field $field,
    $context,
    ResolveInfo $info,
    ?array $value = null,
    ?array $args = null
);

Field: die Feldkonfiguration aus dem Schema

$field (\Magento\Framework\GraphQl\Config\Element\Field) repräsentiert die Deklaration des aktuellen Feldes aus schema.graphqls selbst - Name, deklarierter Typ, konfigurierte Direktiven. In der Praxis wird dieser Parameter selten direkt genutzt, meist nur zu Debugging-Zwecken ($field->getName()) oder wenn ein generischer Resolver für mehrere ähnliche Felder wiederverwendet wird und zur Laufzeit wissen muss, welches Feld gerade aufgelöst wird.

Context: wer fragt gerade an?

$context ist eine Instanz von \Magento\GraphQl\Model\Query\ContextInterface, die wiederum \Magento\Authorization\Model\UserContextInterface erweitert. Die wichtigsten Methoden:

  • getUserId(): ?int - die ID des angemeldeten Kunden, oder 0/null für Gäste (Kapitel 17 vertieft das).
  • getUserType(): int - Konstanten aus UserContextInterface, u. a. USER_TYPE_CUSTOMER, USER_TYPE_GUEST, USER_TYPE_ADMIN.
  • getExtensionAttributes() - u. a. getIsCustomer(): bool, getStore() für den aktuellen Store und getCustomerGroupId().
// Typischer Auth-Check innerhalb eines Resolvers (vertieft in Kapitel 17-18):
if (!$context->getExtensionAttributes()->getIsCustomer()) {
    throw new GraphQlAuthorizationException(
        __('The current customer isn\'t authorized.')
    );
}

$customerId = (int) $context->getUserId();

Args: die vom Client übergebenen Argumente

$args ist ein einfaches assoziatives Array mit genau den Argumenten, die im Schema für das aktuelle Feld deklariert sind (Kapitel 5-7) - inklusive aufgelöster Default-Werte, falls der Client das Argument nicht selbst übergeben hat. Verschachtelte Input-Typen (Kapitel 6) landen als verschachtelte Arrays.

Value: die Nutzlast des übergeordneten Feldes

$value ist bei einem Top-Level-Query-Feld (direkt unter Query oder Mutation) immer null - es gibt keinen übergeordneten Resolver. Sobald ein Feld dagegen innerhalb eines anderen Typs liegt (wie mironsoft_badge_text innerhalb von Product in Kapitel 8), enthält $value das Array, das der Resolver des Elternfeldes zurückgegeben hat.

// Elternresolver liefert z. B.:
return [
    'title' => $event->getTitle(),
    'model' => $event,       // wird an Kind-Resolver weitergereicht
];

// Kind-Resolver liest daraus:
$event = $value['model'] ?? null;

Diese Weiterreichung ist reine Konvention, nicht vom Framework erzwungen - jedes Modul entscheidet selbst, welche Schlüssel es im zurückgegebenen Array anbietet. Das Veranstaltungen-Projekt legt in Kapitel 13 selbst fest, welche Schlüssel sein eigener Events-Resolver an nachgelagerte Feld-Resolver weiterreicht.

ResolveInfo: der vollständige Anfragebaum

$info (\Magento\Framework\GraphQl\Schema\Type\ResolveInfo) gibt Zugriff auf den kompletten geparsten Anfragebaum - unter anderem, welche Unterfelder der Client tatsächlich angefragt hat ($info->getFieldSelection()). Das ist der Schlüssel zu einer wichtigen Performance-Optimierung: teure Berechnungen oder zusätzliche Datenbank-Joins nur dann ausführen, wenn das jeweilige Feld überhaupt in der Anfrage vorkommt.

Tipp: Wer unsicher ist, was in $value ankommt, hilft sich am schnellsten mit einem gezielten var_dump($value); exit; während der lokalen Entwicklung (niemals im produktiven Code) - GraphQL-Antworten sind ohnehin nur über den Endpunkt selbst einsehbar, ein xdebug-Breakpoint (bin/xdebug enable) im Resolver funktioniert genauso gut.

Mit Context, Args, Value und ResolveInfo im Werkzeugkasten ist Block 3 abgeschlossen. Block 4 startet das durchgehende Projekt dieser Serie: eine GraphQL-API für Veranstaltungen, von der ersten Projektvorstellung bis zur vollständigen Abfrage.