Criando temas Gatsby para sites com WordPress

Gatsby é um framework de código aberto construído em cima do React. Com o Gatsby, você pode extrair dados de (quase) qualquer lugar e usá-los para gerar sites estáticos ou dinâmicos. Os dados podem ser extraídos de um CMS, o que definitivamente traz o WordPress para a mesa. Você obtém as vantagens de um site estático (velocidade, segurança, hospedagem estática) enquanto continua gerenciando seu conteúdo por meio de um painel do WordPress.

Uma das particularidades do framework Gatsby é que ele propõe temas como ferramenta de customização. Como alguém com uma forte experiência em WordPress, acho o conceito de temas Gatsby particularmente atraente. Eu costumava projetar e desenvolver temas WordPress. No entanto, com o crescente interesse nas soluções Jamstack, gradualmente mudei para trabalhar com o WordPress como um CMS headless. Neste artigo, gostaria de compartilhar alguns conceitos que aprendi com essa transição.

Nota: Antes de prosseguirmos, vamos nos concentrar nas ferramentas que vamos usar. Gatsby fornece um plugin oficial gatsby-source-wordpress. Para fazê-lo funcionar, precisamos preparar nosso WordPress final. Mais precisamente, precisamos expor os dados do WordPress com sabor de Gatsby por meio de uma API GraphQL. Na prática, isso significa instalar dois plugins WordPress WPGraphQL e WPGatsby. Ambos estão disponíveis através do repositório oficial de plugins do WordPress e não requerem nenhuma configuração.

O que são temas de Gatsby?

O tema Gatsby é um monte de funcionalidades compartilhadas abstraídas dentro de um pacote Node.js. Um tema é, portanto, destinado a ser publicado (em um registro como o npm) e reutilizado como uma dependência instalável.

Já que estamos falando de Gatsby e WordPress aqui, vou esclarecer isso imediatamente – existem semelhanças com temas WordPress, mas não devemos equacionar a noção de temas WordPress com temas Gatsby. Para alguém com experiência em WordPress (como eu), a dissociação pode ser um desafio no início.

Um tema WordPress é um sistema obrigatório de templates que define o que vemos no front-end. A responsabilidade de um bom tema WordPress termina aqui. Não deve introduzir quaisquer funcionalidades, uma vez que as funcionalidades são o território dos plugins. Existe, portanto, uma separação estrita entre temas e plugins no ecossistema WordPress. Os temas devem cuidar da camada de apresentação e os plugins cuidam dos aspectos funcionais.

Seguindo a definição do Gatsby, os temas são responsáveis ​​pelas funcionalidades . Não deveríamos chamá-los de plugins então? Na verdade, o Gatsby, como o WordPress, possui plugins e temas. Plugins, assim como temas, são pacotes Node.js instaláveis ​​que implementam APIs Gatsby. E, de fato, um tema Gatsby é um plugin Gatsby. Se um plug-in possui uma seção, uma página ou parte de uma página em um site - nós o chamamos de tema.

Além disso, ao contrário do WordPress, o Gatsby não requer o uso de temas para construir um site. Em vez disso, você provavelmente começaria a criar seu site configurando um projeto estruturado como abaixo:

Tudo bem até que você tenha mais de um site para manter. Nesse caso, convém abstrair as partes comuns do processo e gerenciá-las (versão e atualização) separadamente.

Graças ao sistema de temas Gatsby, você pode agrupar as partes compartilhadas em um pacote (ou vários pacotes), publicar os pacotes e, finalmente, instalá-los em vários aplicativos. Observe que usei os pacotes de forma plural — você pode combinar vários temas dentro de um projeto.

Temas infantis e sombreamento

Ao trabalhar com Gatsby e WordPress, você identificará algumas funcionalidades principais que são comuns a todos os projetos. Quero dizer aqui: obter os dados e construir as páginas dinamicamente. Parece valer a pena ter um tema que cuide da lógica do data sourcing e da criação das páginas. Por outro lado, como você decide exibir suas páginas pode mudar de um projeto para outro. O que quer que você defina no nível principal, provavelmente precisará substituir em algum momento.

Uma das abordagens possíveis é ter um tema central (pai) e construir temas filhos em cima do tema central.

O que quero dizer com um tema filho Gatsby?

Vamos prosseguir com uma comparação dos temas filhos do WordPress. Os temas filhos do WordPress nos permitem adicionar funcionalidades e substituir modelos. Eles fornecem uma maneira segura de aprimorar e modificar um tema existente.

Um tema filho Gatsby usa um tema pai como seu plugin. Podemos então usar o conceito de sombreamento que dá ao tema filho a capacidade de substituir os arquivos do tema pai; isso é semelhante a substituir os modelos do WordPress em um tema filho. Shadowing significa que podemos substituir arquivos do diretório src incluído no pacote webpack. Vale ressaltar que o shadowing é possível no nível do projeto (onde consumimos nossos temas como pacotes). Veremos isso em ação mais adiante neste artigo.

Com o WordPress, estamos limitados a apenas um tema pai, apenas um tema filho e nenhum encadeamento adicional é possível. Com a flexibilidade dos temas Gatsby, podemos ir muito mais longe. É possível construir diferentes configurações de chains pai-filho.

Vamos agora ver o tema Gatsby em ação. Em nosso exemplo, construiremos dois temas, gatsby-theme-wp-parent e seu tema filho gatsby-theme-wp-child . Eu escolhi esta configuração por uma questão de simplicidade. Em um cenário do mundo real, você pode querer decompor suas funcionalidades em mais temas, cada um com alguma responsabilidade específica.

Publicaremos nossos temas, os instalaremos em um projeto e adicionaremos mais personalização por meio de sombreamento no nível do projeto.

Configuração de desenvolvimento

A última ilustração retrata a estrutura do projeto do usuário final ( site) , onde os temas são consumidos. Eles são instalados como dependências do projeto. Esta configuração assume que os temas estão disponíveis através de algum repositório npm, o que significa que já os publicamos. Nós não estamos lá ainda. Precisamos construir os temas pai e filho primeiro. Mas como é a configuração de desenvolvimento ? Nossos temas são dois pacotes independentes, mas precisamos trabalhar neles em paralelo dentro de um único projeto durante o desenvolvimento. Além disso, queremos configurar uma demonstração dentro do mesmo projeto que implemente os temas diretamente.

Uma das soluções possíveis são os espaços de trabalho do fio. Com os espaços de trabalho do yarn, trabalhamos em um único repositório mono com um único arquivo de bloqueio no nível da raiz do projeto. Além disso, as dependências podem ser vinculadas, o que significa que as áreas de trabalho dependem umas das outras, e usamos as versões locais durante o desenvolvimento.

Como configurar os espaços de trabalho do yarn? Primeiro, certifique-se de ter o fio instalado globalmente. Em seguida, na raiz do seu monorepo, adicione o arquivo package.json que especifica os espaços de trabalho:

 { "private": true, "workspaces": [ "packages/*", "demo" ] }

Agora, cada tema é uma subpasta dentro de packages com seu próprio arquivo package.json e uma entrada principal vazia index.js . Prossigo assim com cada tema que adiciono:

 mkdir packages/gatsby-theme-wp-parent touch packages/gatsby-theme-wp-parent/package.json packages/gatsby-theme-wp-parent/index.js

Com o package.json da seguinte forma:

 { "name": "@pehaa/gatsby-theme-wp-parent", "version": "1.0.0", "license": "MIT", "main": "index.js" }

Discutiremos um pouco mais sobre a publicação do tema. Mas, no momento, vamos observar que publicaremos nossos temas como pacotes com escopo; Eu uso meu apelido @pehaa como escopo aqui. Lembre-se de que, se você decidir publicar pacotes com escopo no registro npm público https://registry.npmjs.org, deverá declarar o acesso público explicitamente e adicionar o seguinte aos arquivos package.json :

 "publishConfig": { "access": "public" }

Além dos temas, também precisaremos de uma área de trabalho de demo a partir da qual testaremos nosso código. A demo tem que ser um pacote "private" , já que não deve ser publicado.

 // demo/package.json { "private": true, "name": "demo", "version": "1.0.0", "scripts": { "build": "gatsby build", "develop": "gatsby develop", "clean": "gatsby clean" } }

Com a configuração dos espaços de trabalho, podemos executar os scripts de desenvolvimento ou compilação de qualquer lugar em nosso monorepo, especificando o script e o espaço de trabalho da seguinte forma:

 yarn workspace demo develop

A propósito, você não está limitado a uma única demo . Por exemplo, nosso GatsbyWPThemes GatsbyWPThemes contém várias demos que adicionamos ao diretório de examples . Nesse caso, o arquivo package.json no nível da raiz define os espaços de trabalho da seguinte maneira:

 "workspaces": [ "packages/*", "examples/*" ]

Construindo Temas Gatsby

Primeiro de tudo, precisamos instalar react , react-dom e gatsby . Precisamos instalar esses três como dependências de pares ( -P ) em cada tema e como dependências em nossa demonstração. Também instalamos o tema pai como dependência do tema filho e o tema filho como dependência da demonstração.

 yarn workspace @pehaa/gatsby-theme-wp-parent add -P react react-dom gatsby yarn workspace @pehaa/gatsby-theme-wp-child add -P react react-dom gatsby yarn workspace @pehaa/gatsby-theme-wp-child add "@pehaa/gatsby-theme-wp-parent@*" yarn workspace demo add react react-dom gatsby "@pehaa/gatsby-theme-wp-child@*"

Nota : Você não pode adicionar @pehaa/gatsby-theme-wp-parent ou @pehaa/gatsby-theme-wp-child sem um número de versão. Você deve especificá-lo como @* ou @1.0.0 . Sem ele, o npm tentará buscar o pacote do repositório em vez de usar o local. Mais tarde, quando publicarmos nossos pacotes com o Lerna, todos os * serão atualizados automaticamente para as versões atuais do tema e mantidos em sincronia.

Tema pai

Vamos agora focar no tema pai e suas dependências:

 yarn workspace @pehaa/gatsby-theme-wp-parent add gatsby-source-wordpress gatsby-plugin-image gatsby-plugin-sharp gatsby-transformer-sharp gatsby-awesome-pagination

A responsabilidade do nosso tema pai é carregar o plugin fonte e três plugins necessários para processar e exibir imagens. Carregamos todos eles no arquivo gatsby-config.js .

 // gatsby-config.js module.exports = (options) => { return { plugins: [ 'gatsby-plugin-sharp', // must have for gatsby 'gatsby-transformer-sharp', // must have for gatsby images 'gatsby-plugin-image', { resolve: 'gatsby-source-wordpress', options: { url: `${options.wordPressUrl}/graphql`, }, }, ], } }

Além de fornecer o conteúdo, precisamos criar rotas para nosso conteúdo WordPress dinamicamente. Precisamos criar rotas para páginas estáticas do WordPress, postagens individuais, arquivo de blog, arquivo de categoria e arquivo de tags. Gatsby fornece a API createPages como parte da API Gatsby Node. Vamos dar uma olhada no código responsável pela criação de posts individuais.

 exports.createPages = async ({ graphql, actions }) => { const { createPage } = actions const postsQuery = await graphql(` query GET_POSTS { allWpPost(sort: {order: DESC, fields: date}) { edges { node { uri id } } } } `) const posts = postsQuery.data.allWpPost.edges posts.forEach(({ node }) => { createPage({ path: node.uri, component: path.resolve('../src/templates/post-query.js'), context: { // Data passed to context is available in page queries as GraphQL variables // we need to add the post id here // so our blog post template knows which blog post it should display id: node.id }, }) }) }

Você pode encontrar o código completo neste repositório do GitHub. Você pode notar que varia dependendo do tipo de página. É diferente para um post, uma página ou um arquivo, especialmente com a paginação implementada para este último. Ainda assim, segue o mesmo padrão:

• execute uma consulta assíncrona graphql “obter itens”;
• faça um loop sobre os itens resultantes e execute a função auxiliar createPage para cada item, passando:
  • o caminho,
  • component — o arquivo de modelo; Gatsby precisa saber o que cada página deve exibir,
  • context — quaisquer dados que o modelo (fornecido no campo de component ) possa precisar.

Como não queremos nos preocupar com a parte da interface do usuário dentro do tema pai, nós a delegamos ao componente que vamos sombrear no tema filho.

 // src/templates/post-query.js import { graphql } from "gatsby" import Post from "../components/Post" export default Post export const pageQuery = graphql` query ($id: String!) { wpPost(id: { eq: $id }) { # query all usefull data } } `

O componente Post tem acesso aos dados da consulta da página graphql definida no arquivo de modelo. Nosso componente recebe os resultados da consulta via props como props.data . Nosso arquivo de componente é separado do modelo, mas tem acesso aos seus dados. Com essa configuração, podemos fazer sombra no componente Post sem precisar reescrever a consulta.

 // src/components/Post.js import React from 'react' const Post = (props) => { return <pre>{JSON.stringify(props.data, null, 2)}</pre> } export default Post

Tema filho

Agora, vamos passar para o tema filho e adicionar suas dependências.

Nota : Eu escolhi usar o Chakra UI como biblioteca de componentes, é baseado na emoção e vem com seu próprio plugin Gatsby. Também precisamos instalar estilos específicos de conteúdo do WordPress de @wordpress/block-library .

 yarn workspace @pehaa/gatsby-theme-wp-child add @chakra-ui/gatsby-plugin @chakra-ui/react @emotion/react @emotion/styled @wordpress/block-library framer-motion gatsby-plugin-webfonts html-react-parser

A responsabilidade do tema filho é a parte da interface do usuário e precisamos substituir a saída básica gerada pelo tema pai. Para que o sombreamento funcione, precisamos seguir a estrutura de arquivos do tema pai. Por exemplo, para substituir o componente Post de gatsby-theme-wp-parent/src/components/Post.js , precisamos criar um arquivo Post.js em gatsby-theme-wp-child/src/@pehaa/gatsby-theme-wp-parent/components . A pasta intermediária @pehaa corresponde ao escopo do pacote gatsby-theme-wp-parent .

Passando opções para temas

Carregamos e configuramos plugins gatsby em um arquivo gatsby-config.js . Teremos três arquivos de configuração em nossa configuração, um em cada nível, nosso tema pai, o tema filho e o demo.

 ├── demo │ └── gatsby-config.js ├── packages │ ├── gatsby-theme-wp-child │ │ └── gatsby-config.js │ └── gatsby-theme-wp-parent │ └── gatsby-config.js └── ...

No nível de demonstração, a configuração carrega o tema filho assim:

 // demo/gatsby-config.js module.exports = { plugins: [ { resolve: '@pehaa/gatsby-theme-wp-child', options: { wordPressUrl: process.env.GATSBY_WP_URL, /* other options */ }, }, ], }

Como você pode ver acima, passamos opções para o tema filho. Eles estarão disponíveis no arquivo de configuração no nível do tema filho. Isso é possível, pois os plugins Gatsby têm a configuração exportada como uma função. Assim, quando carregamos um plugin fornecendo algumas opções, o plugin as recebe como argumento de sua função de configuração. Em particular, as opções que passamos para um tema podem ser “encaminhadas” para seu tema de nível pai da seguinte forma:

 // gatsby-theme-wp-child/gatsby-config.js const defaultFonts = ... module.exports = (options) => { // destructure option to extract fonts const {fonts, ...rest} = options return { plugins: [ { resolve: `@pehaa/gatsby-theme-wp-parent`, options: { // "forward" the options gatsby-theme-wp-child options to its parent theme ...rest } }, '@chakra-ui/gatsby-plugin', { resolve: `gatsby-plugin-webfonts`, options: { fonts: fonts || defaultFonts }, }, ], } }

Vejamos novamente o código acima. Observe que definimos as faces da fonte no nível do tema filho, mas mantemos a possibilidade de modificá-las através das opções do tema.

 // demo/gatsby-config.js module.exports = { plugins: [ { resolve: `@pehaa/gatsby-theme-wp-child`, options: { wordPressUrl: process.env.GATSBY_WP_URL, fonts: { google: [{family: "Rubik"}], }, }, }, ], }

Ao configurar nossos temas, devemos lembrar que um tema é apenas um pacote, e o usuário final não acessa diretamente seu código. Portanto, é uma boa ideia pensar no futuro e expor as configurações adequadas. Se nosso tema carregar um plugin que requer configuração, provavelmente devemos passar as opções de plugins do nível do projeto (demo) até o fim.

Vejamos um exemplo. Nosso tema pai usa o plugin gatsby-source-wordpress que busca os dados do WordPress. Este plugin vem com várias opções, algumas delas possivelmente críticas para o processo de construção, como schema.requestConcurrency ou schema.timeout . Mas, novamente, o tema pai é apenas um pacote, e o usuário final não pode editar seu arquivo gatsby-config . Pode parecer óbvio, mas de alguma forma perdemos isso no lançamento inicial de Gatsby WP Themes. No entanto, com uma correção rápida, o usuário pode passar as opções gatsby-plugin-source-wordpress da configuração do projeto…

 // user's project gatsby-config.js module.exports = { plugins: [ { resolve: `@pehaa/gatsby-theme-wp-child`, options: { wordPressUrl: process.env.GATSBY_WP_URL, gatsbySourceWordPressOptions: {}, // ... }, }, ], }

… através do tema filho e pai para o plugin de destino:

 // packages/gatsby-theme-wp-parent/gatsby-config.js module.exports = (options) => { return { plugins: [ // ... { resolve: `gatsby-plugin-source-wordpress`, options: { url: `${options.wordPressUrl}/graphql`, ...options.gatsbySourceWordPressOptions }, }, ], } }

Tema CSS

As soluções CSS-in-JS que suportam temas parecem ser uma boa opção para os temas Gatsby. Nosso tema filho Gatsby usará o framework Chakra UI e personalizaremos um pouco seu tema CSS. Sim, Chakra UI também usa a noção de um “tema”. Nesse contexto, um tema é um objeto JavaScript que armazena valores de estilo do sistema de design, escalas e/ou tokens de design. Para evitar qualquer confusão, vou me referir a ele como um “tema CSS”. Já instalamos os pacotes @chakra-ui necessários junto com o plugin Gatsby @chakra-ui/gatsby-plugin . Vamos explorar o código do plugin para descobrir como ele funciona. Na verdade, ele envolve nosso aplicativo Gatsby no ChakraProvider e expõe o arquivo src/theme.js para sombreamento, para que possamos proceder assim:

 /* packages/gatsby-theme-wp-child/src/@chakra-ui/gatsby-plugin/theme.js */ import { extendTheme } from "@chakra-ui/react" const theme = { fonts: { body: "Karma, sans-serif", heading: "Poppins, sans-serif", }, styles: { global: { body: { color: "gray.700", fontSize: "xl", }, }, }, components: { Button: { baseStyle: { borderRadius: "3xl", }, defaultProps: { colorScheme: "red", }, }, }, } export default extendTheme(theme)

Mais uma vez, usamos o conceito de sombreamento. O aspecto chave aqui é o local onde criamos o arquivo theme.js .

Mais tarde, veremos como sombrear o tema CSS no nível do projeto do usuário.

Publicando temas com Lerna

Quando seus temas estiverem prontos, você precisa publicá-los. Se você quiser compartilhar seu código publicamente, provavelmente o publicará no registro npm público. E se você nunca publicou um pacote antes, você pode se familiarizar com o processo jogando com o Verdaccio em sua máquina local.

Na Gatsby WP Themes, usamos um serviço premium da Cloudsmith. Cloudsmith oferece suporte a registros completos para pacotes npm com a opção premium para registros privados e uma solução gratuita para os públicos. Continuarei com uma solução Cloudsmith gratuita. Depois de criar sua conta, crie um novo repositório; o meu é pehaa/gatsby-wp-theming .

Para fazer alterações no registro do Cloudsmith por meio da linha de comando, você precisará fornecer suas credenciais de login para esse registro. Basta digitar:

 npm login --registry=https://npm.cloudsmith.io/organistion/repository_name/

e ser-lhe-á pedido o seu nome de utilizador, a sua palavra-passe (que é a sua API KEY) e o seu e-mail.

Com um repositório git de vários pacotes, você pode usar o Lerna para facilitar a publicação. Lerna combina bem com espaços de trabalho de fios. Você pode instalar o Lerna CLI globalmente com npm install --global lerna . Para iniciá-lo em nosso projeto, executaremos o seguinte comando:

 lerna init --independent

O comando acima criará um arquivo lerna.json na raiz do monorepo. Você precisará adicionar "useWorkspaces" : true e "npmClient": "yarn" manualmente; você também pode precisar especificar o command.publish.registry se não for o npm público padrão.

 { "npmClient": "yarn", "useWorkspaces": true, "version": "independent", "command": { "publish": { "registry": "https://cloudsmith.io/organisation/repository_name" } } }

Em seguida, o comando lerna publish publica os pacotes que foram alterados desde a última versão. Por padrão, o Lerna executa prompts para a mudança de versão de cada pacote que está sendo atualizado. Você pode pular os prompts executando:

 lerna publish [major|minor|patch|premajor|preminor|prepatch|prerelease] --yes

Você também pode configurar o Lerna para usar a especificação de confirmação convencional para determinar o aumento de versão e gerar arquivos CHANGELOG.md. Com todas as opções disponíveis, você poderá adaptar a maneira como usa o Lerna ao seu fluxo de trabalho.

Usando um tema em um projeto

Agora, vamos parar o servidor de desenvolvimento e adotar a perspectiva do usuário. Vamos criar um novo projeto, gatsby-wp-site , que implementa gatsby-theme-wp-child como um pacote instalado a partir do repositório npm. Dentro da pasta do nosso projeto, instalaremos nossas quatro dependências: gatsby , react , react react-dom e o próprio tema. Como usamos @pehaa para publicar pacotes com escopo @pehaa, teremos que adicionar um arquivo .npmrc onde especificamos o repositório com @pehaa @pehaa assim:

 mkdir gatsby-wp-site cd gatsby-wp-site echo "@pehaa:registry=https://npm.cloudsmith.io/pehaa/gatsby-wp-theming/" >> .npmrc yarn init -yp yarn add react react-dom gatsby @pehaa/gatsby-theme-wp-child

Nosso site está quase pronto. Basta criar um gatsby-config.file para carregar o tema e fornecer a URL do WordPress. Uma vez feito, estamos prontos para executar gatsby build .

 // gatsby-config.js module.exports = { plugins: [ { resolve: "@pehaa/gatsby-theme-wp-child", options: { wordPressUrl: "https://yourwordpress.website" } } ] }

Nosso site está pronto.

E quanto à personalização? Ainda podemos aproveitar o sombreamento. Além disso, o nível do projeto sempre tem precedência em termos de sombreamento. Vamos vê-lo em ação substituindo o componente Footer. No momento, nosso rodapé está definido em @pehaa/gatsby-theme-wp-child/src/components/Footer.js . Precisamos criar a pasta src e recriar a seguinte estrutura de arquivos:

 gatsby-wp-site ├── src │ └── @pehaa │ └── gatsby-theme-wp-child │ └── components │ └── Footer.js

Com a estrutura de arquivos acima, estamos prontos para fornecer uma nova versão do rodapé do site. Por exemplo:

 import React from "react" import { useStaticQuery, graphql } from "gatsby" import { Box } from "@chakra-ui/react" const Footer = () => { const data = useStaticQuery(graphql` query { wp { generalSettings { title } } } `) return ( <Box as="footer" p="6" fontSize="sm" bg="gray.700" color="white" mt="auto" textAlign="center" > <b>{data.wp.generalSettings.title}</b> - Built with WordPress and GatsbyJS </Box> ) } export default Footer

Finalmente, vamos ver como podemos trabalhar com o tema CSS. Com o código abaixo, devidamente localizado em src/@chakra-ui/gatsby-plugin/theme.js você pode estender o tema padrão dentro do projeto.

 // src/@chakra-ui/gatsby-plugin/theme.js import { extendTheme } from "@chakra-ui/react" const theme = { /* ... */ } export default extendTheme(theme)

Na maioria dos casos, isso não é exatamente o que você precisa. O novo tema CSS ignora o de gatsby-theme-wp-child , enquanto você deseja estender o tema CSS definido no tema filho Gatsby. O último é possível, pois a função extendTheme permite passar vários objetos. Para fazê-lo funcionar, você deve importar o tema CSS de gatsby-theme-wp-child e passá-lo como segundo argumento para a função extendTheme :

 // src/@chakra-ui/gatsby-plugin/theme.js import theme from "@pehaa/gatsby-theme-wp-child/src/@chakra-ui/gatsby-plugin/theme" import { extendTheme } from "@chakra-ui/react" const extendedTheme = { fonts: { body: "Rubik, sans-serif", heading: "Rubik, sans-serif", }, /* ... */ } export default extendTheme(extendedTheme, theme)

Você pode ver o site ao vivo aqui, ele é implantado a partir da ramificação principal deste repositório do GitHub.

Empacotando

Você acabou de ver o tema Gatsby em ação. Com a abordagem de tema, você pode configurar rapidamente vários sites Gatsby com a maior parte de seu código mantido nos pacotes de tema. Também vimos como separar partes do projeto em pacotes e como tirar proveito do sombreamento.

Em nosso exemplo, seguimos a configuração de dois temas com uma relação pai-filho entre os temas. Isso nem sempre pode ser uma escolha ideal.

Às vezes, você pode querer ir muito longe com a personalização da interface do usuário. Nesse caso, você pode considerar carregar e sombrear diretamente o tema pai em vez de usar o filho. Em um cenário do mundo real, você provavelmente optaria por alguns temas de nível filho responsáveis ​​por partes diferentes e reutilizáveis ​​da interface do usuário (por exemplo, comentários, formulários ou pesquisa).

Leitura adicional na revista Smashing

• Construindo uma API com funções Gatsby
• Funções sem servidor de Gatsby e a Estação Espacial Internacional
• Monetize software de código aberto com funções Gatsby e Stripe
• Smashing Podcast Episódio 20 Com Marcy Sutton: O que é Gatsby?