Característica:
Funcionalidades personalizadas para el esquema
Funcionalidades personalizadas para el esquema
Múltiples funcionalidades propuestas para la especificación de GraphQL ya están implementadas en Gato GraphQL, así que no es necesario esperar.
Namespacing del esquema
Si los plugins WooCommerce y Easy Digital Downloads implementaran ambos un tipo Product para la API de GraphQL, no podríamos instalar ambos plugins al mismo tiempo, ya que sus tipos entrarían en conflicto.
El namespacing del esquema permite evitar conflictos en el esquema haciendo que todos los nombres de tipo estén bajo un namespace. Así, el tipo Product se convertiría en Woo_Product y EDD_Product respectivamente, y estos tipos podrían añadirse al mismo esquema.
Esta imagen muestra un esquema con namespacing, en el que a los tipos Event y Location se les añadió el prefijo EM_ para evitar colisiones de nombres:
Campos globales
Los campos globales son campos accesibles desde cualquier tipo del esquema GraphQL (aunque solo se definen una vez).
El esquema GraphQL expone tipos, como Post, User y Comment, y los campos disponibles para cada tipo, como Post.title, User.name y Comment.responses. Estos campos manejan "datos", ya que obtienen una pieza específica de datos de una entidad.
Gato GraphQL, además, también ofrece un tipo de campos distinto: aquellos que proporcionan "funcionalidad" en lugar de datos.
Algunos ejemplos de campos globales son:
_not_if_equals_isEmpty_echo_sprintf_arrayItem_arrayAddItem_arrayUnique- muchos más
Los campos de funcionalidad son útiles para obtener datos almacenados fuera de WordPress y para manipular los datos una vez recuperados, permitiéndonos transformar el valor de un campo de la forma que sea necesario, y otorgándonos potentes capacidades de importación/exportación de datos.
Los campos de funcionalidad no pertenecen a un tipo específico, como Post o User, sino a todos los tipos del esquema. Por eso se manejan de forma distintiva en Gato GraphQL, bajo el nombre de "campos globales".
Field to input
Obtén el valor de un campo, manipúlalo y pásalo como entrada a otro campo, todo dentro de la misma consulta.
query {
posts {
excerpt
# Referencing previous field with name "excerpt"
isEmptyExcerpt: _isEmpty(value: $__excerpt)
# Referencing previous field with alias "isEmptyExcerpt"
isNotEmptyExcerpt: _not(value: $__isEmptyExcerpt)
}
}Directivas componibles
A menudo, una directiva no puede aplicarse a un campo porque tiene una entrada distinta a la salida del campo. Por ejemplo, la directiva @strUpperCase recibe una cadena como entrada, por lo que no puede aplicarse al campo User.capabilities, que devuelve un array de cadenas.
Con las directivas componibles, una directiva puede aumentar a otra directiva para modificar su comportamiento o llenar una carencia. Esto elimina la necesidad de duplicar campos o directivas solo para cambiar sus tipos de entrada o retorno, evitando sobrecarga.
En esta consulta, la directiva @underEachArrayItem itera sobre un array de cadenas y aplica su directiva anidada @strUpperCase a cada una de ellas, resolviendo la incompatibilidad de tipos:
query {
users {
capabilities
@underEachArrayItem
@strUpperCase
}
}Directivas multi-campo
Aplica directivas a varios campos (en lugar de solo uno), para mejorar el rendimiento y ampliar los casos de uso.
Cuando se habilita, se añade un argumento affectAdditionalFieldsUnderPos a todas las directivas, donde se pueden especificar las posiciones relativas de los campos adicionales a los que aplicar la directiva.
Por ejemplo, en la siguiente consulta, la directiva @strTranslate se aplica únicamente al campo content:
query {
posts {
excerpt
content @strTranslate
}
}Al campo excerpt también se le puede aplicar la directiva @strTranslate, añadiendo el argumento de directiva affectAdditionalFieldsUnderPos con valor [1] (ya que 1 es la posición relativa del campo excerpt respecto a la directiva @strTranslate):
query {
posts {
excerpt
content
@strTranslate(
affectAdditionalFieldsUnderPos: [1]
)
}
}Versionado por campo y directiva
Versiona campos y directivas de forma independiente al esquema.
En lugar de evolucionar el esquema completo (lo que obliga a modificar el nombre del campo o directiva modificada), podemos:
- Mantener distintas implementaciones bajo el mismo nombre de campo o directiva
- Exponer la implementación heredada bajo una etiqueta, usando versionado semántico
- Acceder a una versión específica mediante el argumento de campo/directiva
versionConstraint
Feedback proactivo
Usa la entrada de nivel superior extensions para enviar datos sobre deprecaciones y advertencias en la respuesta a la consulta.
- Deprecaciones: Las deprecaciones se devuelven en la misma consulta que involucra a los campos deprecados, y no solo al hacer introspección.
- Advertencias: Las advertencias son problemas que pueden considerarse no bloqueantes, es decir, mejoran la consulta pero no la rompen.
Por ejemplo, la siguiente consulta exporta dos campos usando el mismo nombre de variable dinámica "prop", lo que genera una advertencia:
query {
posts {
excerpt @export(as: "prop")
content @export(as: "prop")
}
}La respuesta incluirá la sección warnings (dentro de extensions) con un mensaje correspondiente:
{
"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>"
}
}
}