Parece uma ideia interessante, pois deve funcionar independentemente da fonte. Definitivamente funcionaria para o meu caso de uso.
Embora eu esteja bastante confiante sobre campos simples, estou me perguntando como isso funcionaria para ativos.

Boa pergunta sobre ativos. Acho que, para ativos, a maioria das fontes de dados os representa como uma string com um URL ou caminho para o ativo. O instantâneo do esquema representaria apenas o tipo como uma string com a URL / caminho ou um objeto de ativo que tem uma propriedade de string com a URL / caminho.

Parece uma ideia interessante, mas por que não pular a indireção extra de um instantâneo e definir o esquema completamente? Como se estivéssemos decidindo e fazendo um exemplo de dados totalmente completo, não parece muito mais trabalhoso especificar diretamente o esquema gql e, ao mesmo tempo, ser mais claro?

@jquense é o que estou pensando. Você poderia tanto executar um comando para "fazer um instantâneo" do esquema gerado dinamicamente, que escreveria um arquivo com o esquema na forma normal do graphql, ou você mesmo poderia escrever diretamente o mesmo formulário.

Sim, definitivamente gosto da ideia de mantê-lo aberto para escrever seu esquema do zero junto com o recurso "instantâneo". Os benefícios que vejo com o recurso "instantâneo" são a capacidade de aprender facilmente a sintaxe do esquema GraphQL e reduzir a quantidade de código clichê necessária para colocar o Gatsby e qualquer plug-in de origem em funcionamento.

No momento, estou examinando os aspectos internos do esquema de Gatsby, inferindo a lógica em ..
https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby/src/schema
E familiarizando-se com a forma como os esquemas GraphQL são definidos. Tentarei criar uma prova sobre o conceito de RP em breve.

Eu entendo perfeitamente como facilitar os usuários para algo novo, mas acho que os plug-ins são um pouco diferentes. Em geral, espera-se que os autores já entendam o gql e os usuários geralmente não precisam se preocupar com nada além de consultas ao consumir um plugin de origem.

Dito isso, embora a linguagem do esquema para definir o esquema seja provavelmente menos complicada do que a consulta, em termos de atualização. Acho que seria melhor gastar um tempo permitindo que os autores do plug-in forneçam um arquivo .graphql do que trabalhando em um instantâneo de um objeto de dados abrangente, o que pode nem ser suficiente para definir adequadamente o esquema completo.

Eu gostaria de mencionar que definir manualmente o esquema é _already_ possível e suportado por meio da API gatsby, embora com o graphql-js não a linguagem de esquema terser.

Eu entendo que os autores do plugin já devem conhecer o gql e os usuários
não deve precisar mexer com esquemas. Mas o problema é que o esquema
produzido a partir de inferência dos dados de origem é muitas vezes incompleto com base
sobre o estado atual dos dados de origem (consulte os problemas que mencionei no
abertura desta edição). Então, a meu ver, é para que os usuários não
realmente mexer em ter que escrever o esquema do zero, eles
poderia configurar os dados de origem para completar, tirar um instantâneo do esquema e
então faça Gatsby usar esse instantâneo daqui para frente. Desta forma, o usuário evita
ter que escrever esquemas do zero para resolver dados vazios / indefinidos
fazendo com que as consultas do Graphql falhem.

Você também poderia explicar um pouco mais sobre como "Acho que seria a hora melhor
gasto permitindo que os autores do plugin forneçam um .graphql ... "funcionaria?

Em Qui, 28 de dezembro de 2017 às 8:27 Jason Quense [email protected]
escrevi:

Eu entendo perfeitamente como levar os usuários a algo novo, mas acho
os plug-ins são um pouco diferentes. Em geral, espera-se que os autores entendam
gql já e os usuários geralmente não devem ter que mexer com qualquer outra coisa
do que consultar ao consumir um plugin de origem.

Dito isso, embora a linguagem do esquema para definir esse esquema seja provavelmente
menos complicado do que consultar, em termos de atualização. eu acho que
seria um tempo melhor gasto permitindo que os autores do plugin forneçam um .graphql
arquivo do que trabalhar em um instantâneo de um objeto de dados abrangente, que pode
nem mesmo é o suficiente para definir adequadamente o esquema por completo.

Eu gostaria de mencionar que definir manualmente o esquema já está
possível e suportado por meio da API gatsby, embora com graphql-js não o
linguagem de esquema terser.

-
Você está recebendo isso porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/gatsbyjs/gatsby/issues/3344#issuecomment-354288169 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAuc_6X_eEWEf281KUspXxB1NuPZPeC4ks5tE5clgaJpZM4RNLJn
.

Portanto, acho que estamos perdendo um ao outro sobre onde isso deve ser resolvido :) no exemplo do WordPress, acho que em vez de o plug-in confiar completamente na inferência do esquema, ele deve especificar totalmente os campos que podem existir, por exemplo, todos os campos anuláveis. Então, o usuário não terá nenhum problema, porque gatsby terá um esquema completo para a fonte de dados.

Nos casos em que o autor do plug-in não pode saber quais são todos os campos, ainda acho que, embora seja mais uma curva de aprendizado, acabará sendo mais preciso e menos sujeito a erros para o usuário fornecer o esquema bruto versus o falso dados a serem inferidos como um esquema. Sim, você precisa aprender mais com antecedência (e devemos fornecer uma boa documentação para isso), mas evita que os usuários precisem entender o funcionamento interno de como o gatsby infere os esquemas. Por exemplo, se um usuário deseja especificar um campo de data, é (eu acho) mais simples aprender a especificar diretamente uma data do que saber fornecer uma string compatível com iso que será inferida como uma data. Além de muitos outros recursos, como conectar dois nós de dados ou especificar nulabilidade, só é possível com uma definição de esquema versus um objeto de dados

Que tal 2 plug-ins diferentes? Um que nos permite especificar facilmente o esquema em um arquivo e outro para gerar esse arquivo a partir de uma fonte específica.
Portanto, a fonte pode ser diferente ... Por exemplo, um espaço de conteúdo onde todos os campos estão completos pode ser a fonte para gerar o esquema. Então, o esquema pode ser usado em qualquer espaço de conteúdo que tenha a mesma arquitetura. E, claro, ainda podemos ajustar o esquema manualmente, se necessário.
Em qualquer caso, parece que o plugin no1 é o primeiro passo. Ainda podemos decidir quando terminar o que fazer a seguir.
@jquense existe em algum lugar um exemplo de esquema definido manualmente? Eu não sabia que era possível.

Gosto da ideia de dois plug-ins. Acho que a API @jquense está falando
é https://www.gatsbyjs.org/docs/node-apis/#setFieldsOnGraphQLNodeType. Mas
Acho que só permite adicionar campos a um esquema certo? E não sobrescrever
o que foi inferido.

Na quinta-feira, 28 de dezembro de 2017 às 10h06, M4rrc0 [email protected] escreveu:

Que tal 2 plug-ins diferentes? Um que nos permite especificar facilmente o
esquema em um arquivo e outro para gerar esse arquivo a partir de um
fonte.
Portanto, a fonte pode ser diferente ... Por exemplo, um espaço de conteúdo onde
cada campo está completo pode ser a fonte para gerar o esquema. Então
o esquema pode ser usado em qualquer espaço de conteúdo que tenha o mesmo
arquitetura. E, claro, ainda podemos ajustar o esquema manualmente se
necessário.
Em qualquer caso, parece que o plugin no1 é o primeiro passo. Ainda podemos
decidir quando terminar o que fazer a seguir.
@jquense https://github.com/jquense existe em algum lugar um exemplo de um
esquema definido manualmente? Eu não sabia que era possível.

-
Você está recebendo isso porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/gatsbyjs/gatsby/issues/3344#issuecomment-354302287 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAuc_4fqrocUXxBPkFsK2tFn2VVDduv3ks5tE66AgaJpZM4RNLJn
.

Sim, acho que você está certo, nem tudo sobrescrevendo: /

Em geral, sou a favor de plug-ins para resolver problemas, mas acho que esse tipo de coisa pode precisar ser tratada na API principal para obter as notas de usabilidade corretas (posso estar totalmente errado, embora). Na minha cabeça, a api ideal seria apenas apontar o gatsby para um arquivo .graphql e ele faz o resto, mas isso pode não ser tão bom quanto eu imagino. Acho que provavelmente vale a pena explorar os plug-ins, se possível, antes de mudar para o núcleo ... É claro que adio o que Kyle pensa, já que ele é o chefe :)

Ok, legal, vou explorar o primeiro plugin para definir
esquemas como arquivos .graphql. Também estou interessado em ouvir a opinião de Kyle :)
Obrigado a todos pela ótima discussão!

Na quinta-feira, 28 de dezembro de 2017 às 10:31 Jason Quense [email protected]
escrevi:

Sim, acho que você está certo, nem tudo sobrescrevendo: /

Geralmente sou a favor de plug-ins para resolver problemas, mas acho que esse tipo de
algo pode precisar ser tratado na API principal para encontrar a usabilidade correta
notas (eu poderia estar totalmente errado tho). Na minha cabeça, a api ideal seria
apenas apontar gatsby para um arquivo .graphql e ele faz o resto, mas isso pode
não tão bom quanto eu imagino. Acho que provavelmente vale a pena explorar
plugins tho se possível antes de possivelmente mover para o núcleo ... eu, claro
adiar o que Kyle pensa, já que ele é o chefe :)

-
Você está recebendo isso porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/gatsbyjs/gatsby/issues/3344#issuecomment-354306088 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAuc_6wNLHfte9zCZ2OqgirIMRadX609ks5tE7RTgaJpZM4RNLJn
.

@ jsanchez034 você olhou mais para isso? Provavelmente tentarei trabalhar nisso na próxima semana e estou interessado se você fez alguma pesquisa e pode compartilhar suas descobertas

Ei, Michal, eu fiz algumas pesquisas e tenho alguns próximos passos em mente. Vou postar
minhas descobertas quando eu voltar para minha máquina em algumas horas.

Na sexta-feira, 5 de janeiro de 2018 às 19h16, Michal Piechowiak [email protected]
escrevi:

@ jsanchez034 https://github.com/jsanchez034 você olhou mais para ele?
Provavelmente tentarei trabalhar nisso na próxima semana e estou interessado se você fez
alguma pesquisa e pode compartilhar suas descobertas

-
Você está recebendo isso porque foi mencionado.

Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/gatsbyjs/gatsby/issues/3344#issuecomment-355699899 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAuc_3w7px_NJjL2EKl8G5TP1GJgQFVWks5tHrtNgaJpZM4RNLJn
.

Ei @pieh , comecei a pesquisar como podemos injetar esquemas totalmente novos no esquema que Gatsby infere dos dados de origem. Portanto, imaginei que um plugin poderia ser criado para adicionar esquemas ao Gatsby. Abaixo estão minhas notas para este plugin ...

Plugin de escritor de esquema

O que o plugin deve fazer?

• Pegue um esquema e um resolvedor e o esquema resultante deve ser agrupado no esquema principal de Gatsby
  
  
  
  • Procura pastas em src/schema , cada pasta tem um esquema e um arquivo de resolução
  
  
  • O plug-in pegará todos os arquivos e os executará em makeExecutableSchema do pacote graphql-tool npm
  
  
  • Crie uma nova função de API do Gatsby Node chamada algo como mergeSchema que é chamada antes desta linha no arquivo de criação de esquema que usa graphql-tool Costura de esquema | src/schema
  
  
• Deve definir alguns dados de amostra fictícios para o novo esquema usando createNode
  
  
  
  • Use sourceNodes no arquivo gatsby-node.js do plugin
  
  

Essas são minhas notas preliminares sobre um plug-in de escritor de esquema. O outro plugin que @MarcCoet mencionou seria aquele onde você poderia apontar o plugin para endpoints em um domínio onde os dados são configurados para estarem em um estado completo, então os esquemas seriam gerados e salvos em src/schema .

Nota: os esquemas seriam definidos usando a linguagem do tipo GraphQL

Infelizmente, não acho que graphql-tools funcionará aqui, pois foi criado para mesclar esquemas completos (ou seja, definições e dados / resolvedores) e adicionar links entre esses esquemas.

Da documentação da função mergeSchemas (https://www.apollographql.com/docs/graphql-tools/schema-stitching.html#mergeSchemas) sobre esquemas passados ​​para mesclar:

schemas é uma matriz de objetos GraphQLSchema ou strings. Para strings, apenas declarações de tipo extend serão usadas. A passagem de strings é útil para adicionar campos a tipos existentes para vincular esquemas, conforme descrito no exemplo acima.

Preferiríamos usar a opção string, já que GraphQLSchema exigem definir pelo menos 1 consulta (ou gera um erro), mas estender o tipo não permite sobrescrever o tipo de campo. Ocorre um erro ao tentar sobrescrever o campo existente (a função de resolução de conflito não é chamada, portanto, nada que possamos fazer a respeito, infelizmente):

Field "frontmatter.title" already exists in the schema. It cannot also be defined in this type extension

Quanto à segunda opção (usando GraphQLSchema ), "hackeado" para funcionar adicionando uma consulta fictícia, mas o problema inicial é que não posso usar tipos do esquema "principal" - não podemos simplesmente fazer isso:

type frontmatter {
  featuredImage: File
  title: String
}

porque o arquivo não está definido neste esquema adicional. Provavelmente poderíamos anexar tipos internos para que funcionasse, mas sinto que tentar "enganar" essa ferramenta para fazer coisas que ela não foi projetada para fazer (pelo menos neste momento) não é o caminho a percorrer.

Vou tentar avaliar 2 outras abordagens:

• procure ou faça uma ferramenta projetada para modificar o esquema já existente (que seria uma ferramenta graphql mais genérica)
• ou forçar os tipos definidos pelo usuário / plug-in nos campos ao criar o esquema (isso seria específico do gatsby)

Eu fiz alguns progressos. Decidi usar a abordagem específica do gatsby por enquanto (adicionando suporte para "tipos forçados" em https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby/src/schema), pois achei mais fácil trabalhar com do que brincar com objetos de esquema Graphql. Vou tentar limpar meu código um pouco para que fique mais legível e criar uma solicitação de pull esta semana para discuti-lo mais adiante.

Apenas uma pequena amostra dos resultados (imo, bastante promissor):
Eu usei https://github.com/gatsbyjs/gatsby-starter-blog e usei frontmatter em postagens para emular alguns problemas que podem causar erros de compilação causados ​​por consultas que não correspondem ao esquema:

// post #1
---
title: Hello World
date: "2015-05-01T22:12:03.284Z"
featuredImage: "sasalty_egg.jpg" // badly formatted value that wouldn't allow to make this File type 
test: "some string" // incompatible value type with other posts (in other posts test field is object) - it would be skipped in schema
---

// post #2
---
title: My Second Post!
date: "2015-05-06T23:46:37.121Z"
test:
  floatField: 5.5
  intField: 99
  arrayOfStringsField:
    - "it"
    - "works"
---

// post #3
---
title: New Beginnings
date: "2015-05-28T22:40:32.169Z"
test:
  stringField: "string"
  boolField: true
---

Definições de tipo usadas:

type MarkdownRemark {
  frontmatter: frontmatter_forced_type
}

type frontmatter_forced_type {
  featuredImage: File
  title: ImageSharp
  test: TotallyCustomType
}

type TotallyCustomType {
  stringField: String
  floatField: Float
  intField: Int
  boolField: Boolean
  arrayOfStringsField: [String]
}

_Observação: _ essas não precisam ser definições de tipo completas (por exemplo, na definição de MarkdownRemark, eu apenas forço o tipo de campo de frontmatter a não depender da nomenclatura automática de tipo)

Esta é a aparência do frontmatter antes de usar minhas alterações (sem campo test , tipo "ruim" de campo featuredImage ):

E depois:

Olá @pieh! Obrigado por aceitar isso, sua solução parece muito promissora! Desculpe, não pude contribuir mais para este problema nas últimas semanas, não tive tempo para me aprofundar nisso. Avise-me se houver algo em que eu possa ajudar.

Se alguém estiver interessado, você pode ver minhas alterações de código https://github.com/gatsbyjs/gatsby/compare/master...pieh : schema_wip (depois de deletar algum código morto e refatorar algumas coisas que eu tinha ontem, é muito menos código do que eu pensamento :) ).

Não tenho tempo para colocar PR para comentários com boa descrição e repositório de site usado para teste, então decidi apenas compartilhar meu código por enquanto. Se alguém quiser brincar com ele - coloque gatsby-schema.gql arquivo com definição de esquema no diretório raiz do seu projeto (junto com gatsby-node.js , etc.).

Alguma chance de isso virar um PR?
Muitas pessoas ficariam felizes em ter isso, eu acho.

@MarcCoet mais eu

Portanto, atualmente a criação do esquema se parece com isto:

A implementação é duplicada para cada fonte de tipos. Minha prova de conceito (branch que vinculei) adiciona apenas outra fonte e agora triplicamos:

Seria impossível apenas adicionar isso na forma atual.

O que eu quero fazer é algo assim:

Mas isso requer alguma refatoração / retrabalho importante, pois a criação do esquema atual é projetada com a inferência de tipos de dados como única fonte de dados. Depois disso, adicionar outra fonte seria trivial com o conhecimento que ganhei durante o desenvolvimento da minha prova de conceito.

Quero criar um problema de RFC para isso (criei fluxogramas no início desta semana :)). Só preciso de algum tempo livre para realmente se comprometer com a discussão de que isso iria começar.

@MarcCoet Pessoalmente, mudei todos os meus projetos temporariamente para
Mas pretendo fazer a transição de volta para Gatsby assim que isso for consertado.

Criei o problema RFC sobre refatoração (https://github.com/gatsbyjs/gatsby/issues/4261), se alguém estiver interessado em participar da discussão, faça-o.

Obrigado pela atualização e pelo trabalho @pieh . Vou ficar de olho no problema do RFC.

Ei pessoal. Alguma atualização sobre isso? Atualmente um blocker / show-stopper para usarmos Gatsby + Contentful e só queria saber se havia algum desenvolvimento ativo ou se deveríamos considerar outras opções. Obrigado.

@ i8ramin Ainda não há um desenvolvimento ativo, pretendo iniciá-lo esta semana.

Olá pessoal, só estou verificando se alguém fez algum progresso com este problema - nós acabamos de descobrir quando lidamos com campos opcionais / vazios em Contentful> Gatsby - então seria bom ter uma solução - obviamente :) Agradecemos antecipadamente!

Ei @pieh , só

Olá @nicolaslair e @nathanjdunn ! Desculpe pela falta de atualizações sobre isso. Eu tive que colocar este projeto em espera (... de novo) e concentrar meu tempo no gatsby v2 por enquanto. Gostaria de ter notícias melhores :(

Ei @pieh , esse problema será corrigido no Gatsby v2?

Isso não está programado para a v2 - este recurso não interromperá as mudanças, então o plano é implementar a v2 o mais rápido possível e, em seguida, adicionar esse recurso em uma das versões secundárias da v2

@pieh e qualquer outra pessoa, estou fazendo um noramlizer bagunçado para garantir que haja sempre o mesmo modelo de dados para GraphQL, independentemente dos campos opcionais / nulos, etc. Alguém veio com uma solução alternativa melhor antes de algo mais central ser desenvolvido?

O padrão que usei foi criar entradas "fictícias" (em CMS / markdown) que teriam todos os campos opcionais preenchidos e, mais tarde, ao construir o site gatsby, eu teria que filtrar nas consultas, para que nós fictícios não apareçam nos resultados.

@pieh essa é uma boa ideia, obrigado, acho que vou tentar

Para referência, estou agora fazendo esta solução alternativa de entrada fictícia em meu plug-in de origem, o que mantém a equipe CMS feliz e significa que a normalização e exclusão da entrada fictícia é tratada no código de Gatsby, em vez de nos componentes CMS ou UI React .

@dominicchapman Quer criar um
ou uma postagem média?
ou qualquer coisa neste momento

Alguma novidade?

Acabei de ver o plugin de @Undistraction https://github.com/Undistraction/gatsby-plugin-node-fields .

uma maneira simples e consistente de gerenciar a criação de campos em seus nós, com suporte para valores padrão, transformações e validação de valores

Estou pensando que isso deve ser parte do núcleo ... Com certeza vou tentar.

Alguma atualização sobre isso?

Isso será retomado após o lançamento da v2. Não tenho largura de banda para lidar com v2 e isso ao mesmo tempo

Existe uma solução alternativa sugerida até algum tempo depois da V2, quando isso seria resolvido novamente?
Parece estranho se tantas pessoas que usam o GatsbyJS nunca precisaram de campos opcionais. Estou usando com Contentful btw.

Também o estamos usando com Contentful e esse comportamento está nos deixando malucos. Como vemos, o plug-in Contentful é o principal culpado aqui por (supostamente) construir o esquema a partir dos dados recebidos, em vez do esquema do tipo de conteúdo real recebido pela API.

O plugin

Quanto à solução alternativa - se possível, crie uma entrada fictícia para cada tipo de conteúdo que conterá todos os campos opcionais e, em seguida, filtre essa entrada fictícia ao criar páginas ou listagens de entradas. Os dados de entrada fictícios garantirão que o esquema completo seja construído

@pieh Obrigado pela sugestão de

@pieh Eu não sabia disso - obrigado por esclarecer. Uma pergunta de acompanhamento, então, não seria possível para os autores do plug-in injetar valores fictícios para os dados ausentes antes de passá-los para Gatsby? Se Gatsby admitir chaves com undefined como valor no esquema, eu consideraria isso uma solução muito melhor.

Também estamos enfrentando esse problema com gatsby-source-ghost . Nosso esquema de dados tem muitos campos que podem ser retornados legitimamente como nulos e, portanto, são omitidos por Gatsby.

Eu 100% ouço e entendo que qualquer trabalho sobre isso está pausado até depois da chegada da v2 (que estou muito ansioso para ver). Eu queria sinalizar o plug-in de origem do Ghost como sendo outro bom exemplo onde isso ocorre e oferecer ajuda se houver algo que possamos fazer quando chegar a hora de retomar isso 🙂

Mesmo problema em https://github.com/datocms/gatsby-source-datocms 😄

Pergunta: Na V2, poderíamos usar isso para evitar o problema de "consulta de dados ausentes"?

https://next.gatsbyjs.org/docs/actions/#addThirdPartySchema

Em outras palavras, o plug-in Contentful poderia usar essa função para injetar o esquema para um modelo de conteúdo que ainda não tem dados / entradas?

@pieh , você teve algum tempo para refinar isso e iniciar algum desenvolvimento? 😁

Olá a todos, sou muito novo no GatsbyJS, mas uso o Contentful há muito tempo e comecei a experimentar o framework e a mexer um pouco com o GraphQL. Enfrentei esse problema rapidamente, pois geralmente é útil ter campos opcionais em Contentful.

No entanto, descobri se você está puxando uma coleção (por exemplo, allContentfulNews etc) e você tem pelo menos 1 entrada nessa coleção que tem conteúdo em todos os campos (no meu caso, tenho uma 'Data de expiração opcional '), então não vai quebrar a compilação e as entradas com a Data de Expiração vazia retornarão como null . Então, como solução alternativa, estou planejando manter esta postagem de "modelo" e ocultá-la no frontend.

@moreguppy eu tenho uma solução semelhante. Você cria uma página pronta _Teste_ e oculta esta página. Por exemplo:

allContentfulPageExample( filter: { title: { ne: "Test" } } )

@moreguppy @loeildes Sim, foi exatamente assim que resolvemos o problema nesse meio tempo. Mas fica mais difícil a longo prazo, cada vez que você adiciona um novo modelo de conteúdo / novo campo, você precisa criar / atualizar todas as entradas "fictícias" criadas.

criar entradas fictícias funcionou para mim como uma solução temporária. não é o ideal pelas razões mencionadas acima, é provável que seja analisado em algum momento em breve?

ainda nenhuma correção à vista? temos um lançamento em 21 dias

@ bgnz968 É muito improvável que haja consertos adequados (ou melhor, recursos) em 21 dias. Eu não tenho nenhuma data aqui. Há muitos problemas que precisam ser resolvidos aqui - alguns relacionados ao esquema inferido embutido de gatsby, alguns a esquemas costurados de terceiros (https://github.com/gatsbyjs/rfcs/pull/11).

Acho que vou jogar uma lenha no fogo também ... Eu também tenho que fazer a "entrada fictícia" para evitar a quebra de compilação em meu punhado de projetos que usam gatsby-source-prismic . Como @stoltzrobin dublado: é uma solução temporária boa o suficiente, mas é hacky.

Os instantâneos de esquema parecem etapas demais para obter algo que parece tão básico e essencial (ou seja, campos de dados opcionais). Mas parece que sim ou escrever explicitamente o esquema esperado é a única maneira de permitir campos de dados opcionais que são mais complexos do que strings ou números simples.

Também estou usando uma solução alternativa para entradas fictícias para lidar com isso, mas concordo que é muito difícil. Adoraria ver uma correção!

Também usando a solução @loeildes . Apenas adicionando minha voz aqui, esperando que haja uma solução mais ideal em breve.

Ei pessoal,
Eu não testei isso, mas pode ser uma solução alternativa de limpeza que não requer a criação de conteúdo fictício.

https://medium.com/@Zepro/contentful -reference-fields-with-gatsby-js-graphql-9f14ed90bdf9

@Khaledgarbaya Não tive muito tempo para testar sua solução, no entanto, à primeira vista, só consigo fazer isso espalhando Node assim?

... on Node {
    ... on FieldType {
     # ...
   }
}

Sim, a solução alternativa só funciona para referências "polimórficas", mas não para campos opcionais normais

Pode ser tarde para a festa, também deparei com isso no plug-in de origem do Drupal, e não apenas devido a campos ausentes, mas também entidades ausentes fazendo com que os fragmentos não funcionem.

Acredito que a solução alternativa de @pieh será o suficiente, mas quero mencionar algo em minha mente.

Vejo que https://www.drupal.org/project/schemata usando http://json-schema.org/ é útil aqui. Talvez possamos aproveitar isso e ter uma maneira opcional de fornecer um esquema json em vez de inferi-lo. Como esse esquema json é exposto, será parcialmente dependente do plug-in.

Seria incrível ter uma solução para isso. Usar conteúdo de espaço reservado funciona, mas parece hacky e me deixa nervoso, especialmente quando você tem referências aninhadas

Eu criei um problema semelhante, mas com escopo um pouco diferente em # 10856 - como um plug-in de origem pode corrigir o problema de campos ausentes e tipos de nó, visto que um esquema está disponível para informar Gatsby do que está faltando.

@rexxars Há outro tíquete relacionado a isso - https://github.com/gatsbyjs/gatsby/issues/4261 . @stefanprobst trabalhou no protótipo que permite fornecer tipos - por favor, verifique este comentário em particular https://github.com/gatsbyjs/gatsby/issues/4261#issuecomment -442549881 - há um exemplo de definição de tipos de Nó e sua forma (mesmo se nenhum dado está disponível para inferir)

@pieh obrigado! Isso parece promissor!

A postagem original é de dezembro de 2017. Começando a perder a esperança de encontrar uma solução adequada.

Eu sei que isso não é uma solução para o problema nesta versão do Gatsby, mas o gatsby-source-graphql do Gatsby 2.0 praticamente eliminou os problemas de inferência de esquema em minha experiência.

Todos: isso está sendo trabalhado ativamente em # 11480.

Temos uma versão alfa de nossa nova API de personalização de esquema pronta e adoraríamos receber seus comentários! Para obter mais informações, verifique esta postagem do blog .

isso é _muito_ empolgante, obrigado por todo seu trabalho duro @stefanprobst !

Eu vi a nova API na visualização: no entanto, não está claro para mim como isso poderia ser usado para "fazer um instantâneo" do esquema graphql existente para resolver o problema que foi discutido neste tíquete. Eu vi que existe por exemplo https://www.gatsbyjs.org/packages/gatsby-plugin-extract-schema/ com algum código simples para extrair o esquema para um arquivo json. A ideia seria que algo assim pudesse ser "alimentado novamente" no esquema de gatsby?

(Cruzando o dedo porque esta é no momento a maior dor de cabeça que estamos tendo em nosso (s) projeto (s), usando o plugin drupal + gatsby_source_drupal) e seria tão bom poder consertá-lo de forma limpa). :)

@vermario Ainda não oferece suporte à criação de snaphost de esquema. Mas deve resolver o problema melhor do que criar instantâneos. Assim que isso for mesclado, começaremos a implementar definições de tipo para plug-ins (incluindo um Drupal). Se o Drupal tiver endpoint de introspecção (não sou especialista em drupal). Então seremos capazes de gerar o esquema correto, mesmo sem quaisquer dados, então o instantâneo não seria necessário

@pieh parece ótimo: continuaremos observando este espaço. Nesse ínterim, estamos adicionando conteúdo de "teste" (: /) e excluindo o conteúdo das consultas do Graphql no momento da construção. Parece "sujo" :) Obrigado!

Estou tendo um problema ao usar a nova personalização de esquema com gatsby-source-contentful.

Definir um tipo onde um dos campos aponta para uma matriz de referência sempre retorna null

Ie:

type ContentfulPage implements Node {
   editorTitle: String
   title: String
   slug: String
   sections: [ContentfulSection] // im always null 
}

Hiya!

Este problema ficou quieto. Silêncio assustador. 👻

Recebemos muitos problemas, então atualmente os fechamos após 30 dias de inatividade. Já se passaram pelo menos 20 dias desde a última atualização aqui.

Se perdemos esse problema ou se você deseja mantê-lo aberto, responda aqui. Você também pode adicionar o rótulo "não obsoleto" para manter este problema aberto!

Obrigado por fazer parte da comunidade Gatsby! 💪💜

Olá de novo!

Já se passaram 30 dias desde que algo aconteceu sobre esse problema, então nosso amigável robô da vizinhança (sou eu!) Vai fechá-lo.

Lembre-se de que sou apenas um robô, portanto, se fechei este problema por engano, sou HUMAN_EMOTION_SORRY . Sinta-se à vontade para reabrir este problema ou criar um novo se precisar de mais alguma coisa.

Obrigado novamente por fazer parte da comunidade Gatsby!

Estou tendo um problema ao usar a nova personalização de esquema com gatsby-source-contentful.

Definir um tipo onde um dos campos aponta para uma matriz de referência sempre retorna null

Ie:

type ContentfulPage implements Node {
   editorTitle: String
   title: String
   slug: String
   sections: [ContentfulSection] // im always null 
}

@ sami616 Achei que essa abordagem funcionou:

// In gatsby-node.js
exports.sourceNodes = ({ actions }) => {
  const { createTypes } = actions
  const typeDefs = `
    type ContentfulPage implements Node {
      sections: ContentfulSection
    }
    type ContentfulSection implements Node {
      title: String
    }
  `
  createTypes(typeDefs)
}

Parece que, para campos de referência, você também deve definir a forma do modelo ao qual está se referindo

Estou tentando resolver isso. Eu tenho um campo de "Vídeo" (que não é obrigatório em contentful) em um tipo de conteúdo de "ContentfulHomepage" com um campo de referência chamado "Blocos" chamando "ContentfulBlockHomepageBanner".

Funciona bem se o campo de vídeo tem conteúdo ... mas cai se for nulo, então aqui está minha tentativa de resolver o problema do campo vazio.

Consulte abaixo.

Minha tentativa ...

Errando ...

Alguém pode apontar onde estou errado aqui? Obrigado.

Olá de novo!

Já se passaram 30 dias desde que algo aconteceu sobre esse problema, então nosso amigável robô da vizinhança (sou eu!) Vai fechá-lo.

Lembre-se de que sou apenas um robô, portanto, se fechei este problema por engano, sou HUMAN_EMOTION_SORRY . Sinta-se à vontade para reabrir este problema ou criar um novo se precisar de mais alguma coisa.

Como um lembrete amigável: a melhor maneira de ver esse problema, ou qualquer outro, corrigido é abrir uma solicitação pull. Verifique gatsby.dev/contribute para obter mais informações sobre como abrir PRs, fazer a triagem de problemas e contribuir!

Obrigado novamente por fazer parte da comunidade Gatsby!

sou o único que ainda está com esse problema?

Desculpe, estamos trabalhando nisso. Vou definir isso como não obsoleto para que o bot pare de fechá-lo.

Estou tendo um problema ao usar a nova personalização de esquema com gatsby-source-contentful.
Definir um tipo onde um dos campos aponta para uma matriz de referência sempre retorna null
Ie:

type ContentfulPage implements Node {
   editorTitle: String
   title: String
   slug: String
   sections: [ContentfulSection] // im always null 
}

@ sami616 Achei que essa abordagem funcionou:

// In gatsby-node.js
exports.sourceNodes = ({ actions }) => {
  const { createTypes } = actions
  const typeDefs = `
    type ContentfulPage implements Node {
      sections: ContentfulSection
    }
    type ContentfulSection implements Node {
      title: String
    }
  `
  createTypes(typeDefs)
}

Parece que, para campos de referência, você também deve definir a forma do modelo ao qual está se referindo

@silviopaganini Achei que esta é uma boa solução nesse ínterim

sim! tentar isso agora, parece funcionar, mas não é escalável ... Estou trabalhando em um site enorme , se eu tiver que criá-los para todos os campos não obrigatórios não é ótimo, mas funciona por agora

@moreguppy Estou tentando corrigir um problema semelhante com gatsby-source-wordpress, mas recebo a seguinte mensagem quando adiciono este código a gatsby-node.js:

Erro: o esquema deve conter tipos com nomes exclusivos, mas contém vários tipos chamados "wordpress__PAGEAcf".

Meu código:

exports.sourceNodes = ({ actions }) => {
  const { createTypes } = actions
  const typeDefs = `
    type wordpress__PAGEAcf implements Node {
      enter_content: String
    }
  `
  createTypes(typeDefs)
}

Esqueça, para qualquer pessoa com um problema semelhante, este é o formato correto para corrigi-lo:

exports.sourceNodes = ({ actions }) => {
  const { createTypes } = actions
  const typeDefs = `
    type wordpress__PAGE implements Node {
      acf: wordpress__PAGEAcf
    }
    type wordpress__PAGEAcf implements Node {
      enter_content: String
    }
  `
  createTypes(typeDefs)
}

Olá de novo!

Já se passaram 30 dias desde que algo aconteceu sobre esse problema, então nosso amigável robô da vizinhança (sou eu!) Vai fechá-lo.

Lembre-se de que sou apenas um robô, portanto, se fechei este problema por engano, sou HUMAN_EMOTION_SORRY . Sinta-se à vontade para reabrir este problema ou criar um novo se precisar de mais alguma coisa.

Como um lembrete amigável: a melhor maneira de ver esse problema, ou qualquer outro, corrigido é abrir uma solicitação pull. Verifique gatsby.dev/contribute para obter mais informações sobre como abrir PRs, fazer a triagem de problemas e contribuir!

Obrigado novamente por fazer parte da comunidade Gatsby!

Reabrir e adicionar uma tag not stale partir de https://github.com/gatsbyjs/gatsby/issues/3344#issuecomment -505001979

Eu ficaria muito grato se alguém pudesse dar ao material do # 16291 alguns testes do mundo real. Obrigado!

Temos um PR aberto para bloqueio de esquema em # 16291. Seria legal se aqueles que ainda estão interessados ​​em ver este terreno pudessem compartilhar algum feedback. Obrigado!

Ei @stefanprobst . Otimo trabalho!
Desculpe pelo atraso na resposta. Isso está atrasado há tanto tempo que me acostumei com as soluções alternativas e não era mais um grande problema para mim. É tão legal que isso está avançando! :)
Eu tentei rapidamente e funcionou perfeitamente! Isso é raro o suficiente para saudar. ; D
Estou trabalhando em uma grande atualização de um projeto e terei mais alguns testes do 'mundo real' nas próximas semanas. Vou comentar mais no PR.
Muito obrigado pelo trabalho!

@stefanprobst alguma ideia sobre # 19210