Funcionalidade:
Funcionalidades personalizadas para o schema
Funcionalidades personalizadas para o schema
Diversas funcionalidades propostas para a especificação GraphQL já estão implementadas no Gato GraphQL, então não precisamos esperar.
Namespacing do schema
Se os plugins WooCommerce e Easy Digital Downloads ambos implementassem um tipo Product para a API GraphQL, não poderíamos instalar os dois plugins ao mesmo tempo, pois seus tipos entrariam em conflito.
O namespacing do schema permite evitar conflitos no schema, aplicando um namespace a todos os nomes de tipos. Assim, o tipo Product se tornaria Woo_Product e EDD_Product, respectivamente, e esses tipos poderiam ser adicionados ao mesmo schema.
Esta imagem mostra um schema com namespacing, no qual o prefixo EM_ foi adicionado aos tipos Event e Location para evitar colisão de nomes:
Campos globais
Campos globais são campos acessíveis em todos os tipos do schema GraphQL (sendo definidos apenas uma vez).
O schema GraphQL expõe tipos como Post, User e Comment, e os campos disponíveis para cada tipo, como Post.title, User.name e Comment.responses. Esses campos lidam com "dados", pois recuperam um item específico de dados de uma entidade.
O Gato GraphQL também oferece um tipo diferente de campos: aqueles que fornecem "funcionalidade" em vez de dados.
Alguns exemplos de campos globais:
_not_if_equals_isEmpty_echo_sprintf_arrayItem_arrayAddItem_arrayUnique- e muitos mais
Os campos de funcionalidade são úteis para obter dados armazenados fora do WordPress e para manipular os dados após sua recuperação, permitindo transformar o valor de um campo da forma que for necessária, e nos concedendo poderosas capacidades de importação/exportação de dados.
Os campos de funcionalidade não pertencem a um tipo específico, como Post ou User, mas a todos os tipos do schema. Por isso, eles são tratados de forma distinta no Gato GraphQL, sob o nome de "campos globais".
Field to input
Obtenha o valor de um campo, manipule-o e passe-o como input para outro campo, tudo dentro da mesma query.
query {
posts {
excerpt
# Referencing previous field with name "excerpt"
isEmptyExcerpt: _isEmpty(value: $__excerpt)
# Referencing previous field with alias "isEmptyExcerpt"
isNotEmptyExcerpt: _not(value: $__isEmptyExcerpt)
}
}Directives composáveis
Muitas vezes, uma directive não pode ser aplicada a um campo porque possui um input diferente do output do campo. Por exemplo, a directive @strUpperCase recebe uma string como input, portanto não pode ser aplicada ao campo User.capabilities, que retorna um array de strings.
Com as directives composáveis, uma directive pode potencializar outra directive para modificar seu comportamento ou preencher uma lacuna. Isso elimina a necessidade de duplicar campos ou directives apenas para alterar seus tipos de input ou retorno, evitando inchaço desnecessário.
Nesta query, a directive @underEachArrayItem itera sobre um array de strings e aplica sua directive aninhada @strUpperCase em cada um deles, resolvendo a incompatibilidade de tipos:
query {
users {
capabilities
@underEachArrayItem
@strUpperCase
}
}Directives multi-campo
Aplique directives a múltiplos campos (em vez de apenas um), para melhor desempenho e casos de uso ampliados.
Quando habilitado, um argumento affectAdditionalFieldsUnderPos é adicionado a todas as directives, onde as posições relativas dos campos adicionais aos quais aplicar a directive podem ser especificadas.
Por exemplo, na query a seguir, a directive @strTranslate é aplicada apenas ao campo content:
query {
posts {
excerpt
content @strTranslate
}
}O campo excerpt também pode receber a directive @strTranslate, adicionando o argumento de directive affectAdditionalFieldsUnderPos com o valor [1] (pois 1 é a posição relativa do campo excerpt em relação à directive @strTranslate):
query {
posts {
excerpt
content
@strTranslate(
affectAdditionalFieldsUnderPos: [1]
)
}
}Versionamento por campo e por directive
Versione campos e directives independentemente do schema.
Em vez de evoluir o schema inteiro (o que exige modificar o nome do campo ou directive alterado), podemos:
- Manter diferentes implementações sob o mesmo nome de campo ou directive
- Expor a implementação legada sob uma tag, usando versionamento semântico
- Acessar uma versão específica por meio do argumento de campo/directive
versionConstraint
Feedback proativo
Use a entrada de nível superior extensions para enviar dados referentes a deprecações e avisos na resposta à query.
- Deprecações: As deprecações são retornadas na mesma query que envolve campos deprecados, e não apenas durante a introspecção.
- Avisos: Avisos são problemas que podem ser considerados não bloqueantes, ou seja, aprimoram a query sem interrompê-la.
Por exemplo, a query a seguir exporta dois campos usando o mesmo nome de variável dinâmica "prop", o que gera um aviso:
query {
posts {
excerpt @export(as: "prop")
content @export(as: "prop")
}
}A resposta incluirá a seção warnings (sob extensions) com uma mensagem correspondente:
{
"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>"
}
}
}