Funzionalità:
Funzionalità personalizzate per lo schema
Funzionalità personalizzate per lo schema
Numerose funzionalità proposte per la specifica GraphQL sono già implementate in Gato GraphQL, quindi non è necessario aspettare.
Namespacing dello schema
Se i plugin WooCommerce e Easy Digital Downloads implementassero entrambi un tipo Product per l'API GraphQL, non potremmo installare entrambi i plugin contemporaneamente, poiché i loro tipi andrebbero in conflitto.
Il namespacing dello schema consente di evitare conflitti nello schema applicando un namespace a tutti i nomi dei tipi. Così, il tipo Product diventerebbe rispettivamente Woo_Product e EDD_Product, e questi tipi potrebbero essere aggiunti allo stesso schema.
Questa immagine mostra uno schema con namespacing, in cui il prefisso EM_ è stato aggiunto ai tipi Event e Location per evitare collisioni di nomi:
Campi globali
I campi globali sono campi accessibili da qualsiasi tipo dello schema GraphQL (pur essendo definiti una sola volta).
Lo schema GraphQL espone tipi come Post, User e Comment, e i campi disponibili per ogni tipo, come Post.title, User.name e Comment.responses. Questi campi trattano i "dati", in quanto recuperano un elemento specifico di dati da un'entità.
Gato GraphQL offre inoltre un altro tipo di campi: quelli che forniscono "funzionalità" invece di dati.
Alcuni esempi di campi globali:
_not_if_equals_isEmpty_echo_sprintf_arrayItem_arrayAddItem_arrayUnique- e molti altri
I campi di funzionalità sono utili per ottenere dati memorizzati al di fuori di WordPress e per manipolare i dati una volta recuperati, consentendoci di trasformare il valore di un campo nel modo richiesto, e offrendoci potenti capacità di importazione/esportazione dei dati.
I campi di funzionalità non appartengono a un tipo specifico, come Post o User, ma a tutti i tipi dello schema. Per questo motivo vengono gestiti in modo distintivo in Gato GraphQL, sotto il nome di "campi globali".
Field to input
Ottieni il valore di un campo, manipolalo e passalo come input a un altro campo, tutto all'interno della stessa query.
query {
posts {
excerpt
# Referencing previous field with name "excerpt"
isEmptyExcerpt: _isEmpty(value: $__excerpt)
# Referencing previous field with alias "isEmptyExcerpt"
isNotEmptyExcerpt: _not(value: $__isEmptyExcerpt)
}
}Direttive componibili
Spesso una direttiva non può essere applicata a un campo perché ha un input diverso dall'output del campo. Ad esempio, la direttiva @strUpperCase riceve una stringa come input, quindi non può essere applicata al campo User.capabilities, che restituisce un array di stringhe.
Con le direttive componibili, una direttiva può potenziare un'altra direttiva per modificarne il comportamento o colmare una lacuna. Questo elimina la necessità di duplicare campi o direttive solo per cambiare i loro tipi di input o di ritorno, evitando un inutile aumento delle dimensioni.
In questa query, la direttiva @underEachArrayItem itera su un array di stringhe e applica la sua direttiva annidata @strUpperCase a ciascuna di esse, risolvendo l'incompatibilità di tipi:
query {
users {
capabilities
@underEachArrayItem
@strUpperCase
}
}Direttive multi-campo
Applica le direttive a più campi (invece di uno solo), per migliorare le prestazioni e ampliare i casi d'uso.
Quando abilitata, viene aggiunto un argomento affectAdditionalFieldsUnderPos a tutte le direttive, che consente di specificare le posizioni relative dei campi aggiuntivi a cui applicare la direttiva.
Ad esempio, nella seguente query, la direttiva @strTranslate viene applicata solo al campo content:
query {
posts {
excerpt
content @strTranslate
}
}Il campo excerpt può anch'esso ricevere la direttiva @strTranslate, aggiungendo l'argomento della direttiva affectAdditionalFieldsUnderPos con il valore [1] (poiché 1 è la posizione relativa del campo excerpt rispetto alla direttiva @strTranslate):
query {
posts {
excerpt
content
@strTranslate(
affectAdditionalFieldsUnderPos: [1]
)
}
}Versionamento per campo e per direttiva
Versiona i campi e le direttive indipendentemente dallo schema.
Invece di far evolvere l'intero schema (il che richiede di modificare il nome del campo o della direttiva modificata), possiamo:
- Mantenere implementazioni diverse sotto lo stesso nome di campo o direttiva
- Esporre l'implementazione legacy sotto un tag, utilizzando il versionamento semantico
- Accedere a una versione specifica tramite l'argomento di campo/direttiva
versionConstraint
Feedback proattivo
Utilizza la voce di primo livello extensions per inviare dati relativi a deprecazioni e avvertimenti nella risposta alla query.
- Deprecazioni: Le deprecazioni vengono restituite nella stessa query che coinvolge i campi deprecati, e non solo durante l'introspezione.
- Avvertimenti: Gli avvertimenti sono problemi che possono essere considerati non bloccanti, ovvero migliorano la query senza interromperla.
Ad esempio, la seguente query esporta due campi utilizzando lo stesso nome di variabile dinamica "prop", il che genera un avvertimento:
query {
posts {
excerpt @export(as: "prop")
content @export(as: "prop")
}
}La risposta includerà la sezione warnings (sotto extensions) con un messaggio corrispondente:
{
"extensions": {
"warnings": [
{
"message": "Dynamic variable with name 'props' had already been set, had its value overridden",
"locations": [
{
"line": 4,
"column": 25
}
]
}
]
},
"data": {
"posts": {
"excerpt": "Hello world!",
"Content": "<p>Hello world!</p>"
}
}
}