Créer des thèmes Gatsby pour les sites Web alimentés par WordPress

Gatsby est un framework open-source construit sur React. Avec Gatsby, vous pouvez extraire des données de (presque) n'importe où et les utiliser pour générer des sites Web statiques ou dynamiques. Les données peuvent être extraites d'un CMS, ce qui amène définitivement WordPress à la table. Vous bénéficiez des avantages d'un site web statique (rapidité, sécurité, hébergement statique) tout en continuant à gérer votre contenu via un tableau de bord WordPress.

Une des particularités du framework Gatsby est qu'il propose des thèmes comme outil de personnalisation. En tant que personne ayant une solide expérience dans WordPress, je trouve le concept des thèmes Gatsby particulièrement attrayant. J'avais l'habitude de concevoir et développer des thèmes WordPress. Cependant, avec l'intérêt croissant pour les solutions Jamstack, je me suis progressivement orienté vers l'utilisation de WordPress en tant que CMS sans tête. Dans cet article, je voudrais partager quelques concepts que j'ai appris de cette transition.

Remarque : Avant d'aller plus loin, concentrons-nous sur les outils que nous allons utiliser. Gatsby fournit un plugin officiel gatsby-source-wordpress. Pour que cela fonctionne, nous devons préparer notre fin WordPress. Plus précisément, nous devons exposer les données WordPress à saveur Gatsby via une API GraphQL. En pratique, cela signifie installer deux plugins WordPress WPGraphQL et WPGatsby. Les deux sont disponibles via le référentiel officiel de plugins WordPress et ne nécessitent aucune configuration.

Que sont les thèmes Gatsby ?

Le thème Gatsby est un ensemble de fonctionnalités partagées résumées dans un package Node.js. Un thème est donc destiné à être publié (vers un registre comme npm) et réutilisé comme dépendance installable.

Puisque nous parlons ici de Gatsby et de WordPress , je vais le préciser tout de suite — il y a des similitudes avec les thèmes WordPress, mais il ne faut pas assimiler la notion de thèmes WordPress aux thèmes Gatsby. Pour quelqu'un qui a une formation WordPress (comme moi), la dissociation peut être difficile au début.

Un thème WordPress est un système obligatoire de modèles qui définit ce que nous voyons sur le front-end. La responsabilité d'un bon thème WordPress s'arrête là. Il ne doit introduire aucune fonctionnalité puisque les fonctionnalités sont le territoire des plugins. Il existe donc une séparation stricte entre les thèmes et les plugins dans l'écosystème WordPress. Les thèmes doivent s'occuper de la couche de présentation et les plugins s'occuper des aspects fonctionnels.

Selon la définition de Gatsby, les thèmes sont responsables des fonctionnalités . Ne devrions-nous pas les appeler plugins alors ? En fait, Gatsby, comme WordPress, a à la fois des plugins et des thèmes. Les plugins, tout comme les thèmes, sont des packages Node.js installables qui implémentent les API Gatsby. Et en fait, un thème Gatsby est un plugin Gatsby. Si un plugin possède une section, une page ou une partie de page sur un site, nous l'appelons un thème.

De plus, contrairement à WordPress, Gatsby ne nécessite pas l'utilisation de thèmes pour créer un site. Au lieu de cela, vous commencerez probablement à créer votre site en mettant en place un projet structuré comme ci-dessous :

C'est ok jusqu'à ce que vous ayez plus d'un site à maintenir. Dans ce cas, vous souhaiterez peut-être extraire les parties communes du processus et les gérer (version et mise à jour) séparément.

Grâce au système de thèmes Gatsby, vous pouvez regrouper les parties partagées dans un package (ou plusieurs packages), publier les packages et enfin les installer dans de nombreuses applications. Notez que j'ai utilisé les packages de forme plurielle - vous pouvez combiner plusieurs thèmes dans un projet.

Thèmes enfants et ombrage

Lorsque vous travaillez avec Gatsby et WordPress, vous identifierez certaines fonctionnalités de base communes à tous les projets. Je veux dire ici : sourcer les données et créer les pages de manière dynamique. Il semble intéressant d'avoir un thème qui s'occupe de la logique de sourcing des données et de la création des pages. En revanche, la façon dont vous décidez d'afficher vos pages peut changer d'un projet à l'autre. Quoi que vous définissiez au niveau de base, vous devrez probablement remplacer à un moment donné.

L'une des approches possibles consiste à avoir un thème principal (parent) et à créer des thèmes enfants au-dessus du thème principal.

Qu'est-ce que je veux dire par un thème enfant Gatsby ?

Procédons à une comparaison des thèmes enfants WordPress. Les thèmes enfants WordPress nous permettent d'ajouter des fonctionnalités et de remplacer les modèles. Ils fournissent un moyen sûr d'améliorer et de modifier un thème existant.

Un thème enfant Gatsby utilise un thème parent comme plugin. Nous pouvons alors utiliser le concept d'ombrage qui donne au thème enfant la possibilité de remplacer les fichiers du thème parent ; cela revient à remplacer les modèles WordPress dans un thème enfant. L'observation signifie que nous pouvons remplacer les fichiers du répertoire src inclus dans le bundle webpack. Il convient de souligner que l'observation est possible au niveau du projet (où nous consommons nos thèmes sous forme de packages). Nous le verrons en action plus loin dans cet article.

Avec WordPress, nous sommes limités à un seul thème parent, un seul thème enfant, et aucun chaînage supplémentaire n'est possible. Avec la flexibilité des thèmes Gatsby, on peut aller beaucoup plus loin. Il est possible de créer différentes configurations de chaînes enfant-parent.

Voyons maintenant le thème Gatsby en action. Dans notre exemple, nous allons construire deux thèmes, gatsby-theme-wp-parent et son enfant-theme gatsby-theme-wp-child . J'ai choisi cette configuration par souci de simplicité. Dans un scénario réel, vous souhaiterez peut-être décomposer vos fonctionnalités en plusieurs thèmes, chacun avec une responsabilité spécifique.

Nous publierons nos thèmes, les installerons dans un projet et ajouterons une personnalisation supplémentaire via l'observation au niveau du projet.

Configuration du développement

La dernière illustration décrit la structure du projet de l'utilisateur final ( site) , où les thèmes sont consommés. Ils sont installés en tant que dépendances du projet. Cette configuration suppose que les thèmes sont disponibles via un référentiel npm, ce qui signifie que nous les avons déjà publiés. Nous n'en sommes pas encore là. Nous devons d'abord créer les thèmes parent et enfant. Mais à quoi ressemble la configuration de développement ? Nos thèmes sont deux packages indépendants, mais nous devons les travailler en parallèle au sein d'un même projet lors du développement. De plus, nous voulons mettre en place une démo au sein du même projet qui implémente directement les thèmes.

L'une des solutions possibles est les espaces de travail du fil. Avec les espaces de travail de fil, nous travaillons dans un seul dépôt unique avec un seul fichier de verrouillage au niveau de la racine du projet. De plus, les dépendances peuvent être liées entre elles, ce qui signifie que les espaces de travail dépendent les uns des autres, et nous utilisons les versions locales lors du développement.

Comment mettre en place des espaces de travail fils ? Tout d'abord, assurez-vous que le fil est installé dans le monde entier. Ensuite, à la racine de votre monorepo, ajoutez le fichier package.json qui spécifie les espaces de travail :

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

Désormais, chaque thème est un sous-dossier dans les packages avec son propre fichier package.json et une entrée principale vide index.js . Je procède ainsi avec chaque thème que j'ajoute :

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

Avec le package.json comme suit :

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

Nous discuterons un peu plus loin du thème de la publication. Mais, pour le moment, notons que nous publierons nos thèmes sous forme de packages ciblés ; J'utilise mon surnom @pehaa comme champ d'application ici. N'oubliez pas que, si vous décidez de publier des packages étendus dans le registre public npm https://registry.npmjs.org, vous devez indiquer explicitement l'accès public et ajouter les éléments suivants à leurs fichiers package.json :

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

En plus des thèmes, nous aurons également besoin d'un espace de travail de demo à partir duquel nous essaierons notre code. La démo doit être un package "private" car elle n'est pas censée être publiée.

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

Avec la configuration des espaces de travail, nous pouvons exécuter les scripts de développement ou de construction depuis n'importe où dans notre monorepo en spécifiant le script et l'espace de travail comme suit :

 yarn workspace demo develop

D'ailleurs, vous n'êtes pas limité à une seule demo . Par exemple, notre GatsbyWPThemes GatsbyWPThemes contient plusieurs démos que nous ajoutons au répertoire des examples . Dans ce cas, le fichier package.json de niveau racine définit les espaces de travail comme suit :

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

Construire des thèmes Gatsby

Tout d'abord, nous devons installer react , react react-dom et gatsby . Nous devons installer ces trois en tant que dépendances homologues ( -P ) dans chaque thème et en tant que dépendances dans notre démo. Nous installons également le thème parent comme dépendance du thème enfant et le thème enfant comme dépendance de la démo.

 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@*"

Remarque : Vous ne pouvez pas ajouter @pehaa/gatsby-theme-wp-parent ou @pehaa/gatsby-theme-wp-child sans numéro de version. Vous devez le spécifier sous la forme @* ou @1.0.0 . Sans cela, npm essaiera de récupérer le package à partir du référentiel au lieu d'utiliser celui local. Plus tard, lorsque nous publierons nos packages avec Lerna, tous les * seront automatiquement mis à jour avec les versions de thème actuelles et synchronisés.

Thème parent

Concentrons-nous maintenant sur le thème parent et ses dépendances :

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

La responsabilité de notre thème parent est de charger le plugin source et trois plugins nécessaires au traitement et à l'affichage des images. Nous les chargeons tous dans le fichier 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`, }, }, ], } }

Outre la recherche de contenu, nous devons créer des routes pour notre contenu WordPress de manière dynamique. Nous devons créer des itinéraires pour les pages statiques WordPress, les publications individuelles, les archives de blogs, les archives de catégories et les archives de balises. Gatsby fournit l'API createPages dans le cadre de l'API Gatsby Node. Jetons un coup d'œil au code responsable de la création de messages individuels.

 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 }, }) }) }

Vous pouvez trouver le code complet dans ce référentiel GitHub. Vous remarquerez peut-être que cela varie en fonction du type de page. C'est différent pour un article, une page ou une archive, notamment avec la pagination mise en place pour cette dernière. Pourtant, il suit le même schéma :

• exécuter une requête "get items" graphql asynchrone ;
• bouclez sur les éléments résultants et exécutez la fonction d'assistance createPage pour chaque élément, en transmettant :
  • le chemin,
  • component — le fichier modèle ; Gatsby doit savoir ce que chaque page doit afficher,
  • context — quelles que soient les données dont le modèle (fourni dans le champ component ) pourrait avoir besoin.

Comme nous ne voulons pas nous soucier de la partie UI dans le thème parent, nous la déléguons au composant que nous allons masquer dans le thème enfant.

 // 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 } } `

Le composant Post a accès aux données de la requête de page graphql définie dans le fichier de modèle. Notre composant reçoit les résultats de la requête via des accessoires en tant que props.data . Notre fichier de composant est séparé du modèle mais a accès à ses données. Avec cette configuration, nous pouvons masquer le composant Post sans avoir à réécrire la requête.

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

Thème enfant

Passons maintenant au thème enfant et ajoutons ses dépendances.

Note : J'ai choisi d'utiliser Chakra UI comme bibliothèque de composants, elle est basée sur l'émotion et est livrée avec son propre plugin Gatsby. Nous devons également installer des styles spécifiques au contenu WordPress à partir 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

La responsabilité du thème enfant est la partie de l'interface utilisateur, et nous devons remplacer la sortie de base générée par le thème parent. Pour que l'observation fonctionne, nous devons suivre la structure des fichiers du thème parent. Par exemple, pour remplacer le composant Post de gatsby-theme-wp-parent/src/components/Post.js nous devons créer un fichier Post.js dans gatsby-theme-wp-child/src/@pehaa/gatsby-theme-wp-parent/components . Le dossier intermédiaire @pehaa correspond à la portée du gatsby-theme-wp-parent .

Passer des options aux thèmes

Nous chargeons et configurons les plugins gatsby dans un fichier gatsby-config.js . Nous aurons trois fichiers de configuration dans notre configuration, un à chaque niveau, notre thème parent, le thème enfant et la démo.

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

Au niveau de la démo, la configuration charge le thème enfant comme suit :

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

Comme vous pouvez le voir ci-dessus, nous passons des options au thème enfant. Ceux-ci seront disponibles dans le fichier de configuration au niveau du thème enfant. C'est possible puisque les plugins Gatsby ont une configuration exportée en tant que fonction. Ainsi, lorsque nous chargeons un plugin fournissant certaines options, le plugin les reçoit en argument de sa fonction config. En particulier, les options que nous passons à un thème peuvent être "transférées" à son thème de niveau parent comme ceci :

 // 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 }, }, ], } }

Reprenons le code ci-dessus. Notez que nous définissons les polices au niveau du thème enfant, mais nous gardons la possibilité de les modifier via les options du thème.

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

Lors de la configuration de nos thèmes, nous devons nous rappeler qu'un thème n'est qu'un package et que l'utilisateur final n'accède pas directement à son code. Par conséquent, c'est une bonne idée de penser à l'avance et d'exposer les paramètres appropriés. Si notre thème charge un plugin qui nécessite une configuration, nous devrions probablement passer les options des plugins du niveau projet (démo) jusqu'en bas.

Examinons un exemple. Notre thème parent utilise le gatsby-source-wordpress qui récupère les données de WordPress. Ce plugin est livré avec un tas d'options, dont certaines peuvent être critiques pour le processus de construction, comme schema.requestConcurrency ou schema.timeout . Mais, encore une fois, le thème parent n'est qu'un package et l'utilisateur final ne peut pas modifier son fichier gatsby-config . Cela peut sembler évident, mais nous l'avons en quelque sorte manqué dans la version initiale de Gatsby WP Themes. Cependant, avec une solution rapide, l'utilisateur peut passer les gatsby-plugin-source-wordpress à partir de la configuration du projet…

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

… via le thème enfant et parent vers le plugin de destination :

 // 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 }, }, ], } }

Thème CSS

Les solutions CSS-in-JS qui prennent en charge la thématisation semblent convenir aux thèmes Gatsby. Notre thème enfant Gatsby utilisera le framework Chakra UI, et nous personnaliserons légèrement son thème CSS. Oui, Chakra UI utilise également la notion de "thème". Dans ce contexte, un thème est un objet JavaScript qui stocke les valeurs de style du système de conception, les échelles et/ou les jetons de conception. Pour éviter toute confusion, je l'appellerai un "thème CSS". Nous avons déjà installé les packages @chakra-ui requis avec le plugin Gatsby @chakra-ui/gatsby-plugin . Explorons le code du plugin pour découvrir comment cela fonctionne. En fait, il encapsule notre application Gatsby dans le ChakraProvider et expose le fichier src/theme.js pour l'observation, afin que nous puissions procéder comme suit :

 /* 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)

Encore une fois, nous avons utilisé le concept d'observation. L'aspect clé ici est l'emplacement où nous avons créé le fichier theme.js .

Plus tard, nous verrons comment masquer le thème CSS au niveau du projet de l'utilisateur.

Thèmes de publication avec Lerna

Une fois vos thèmes prêts, vous devez les publier. Si vous souhaitez partager votre code publiquement, vous le publierez très probablement dans le registre public npm. Et si vous n'avez jamais publié de package auparavant, vous pouvez vous familiariser avec le processus en jouant avec Verdaccio sur votre ordinateur local.

Chez Gatsby WP Themes, nous utilisons un service premium de Cloudsmith. Cloudsmith prend en charge les registres complets pour les packages npm avec l'option premium pour les registres privés et une solution gratuite pour les registres publics. Je vais continuer avec une solution Cloudsmith gratuite. Une fois que vous avez créé votre compte, créez un nouveau référentiel ; le mien est pehaa/gatsby-wp-theming .

Afin d'apporter des modifications à votre registre Cloudsmith via votre ligne de commande, vous devrez fournir vos identifiants de connexion pour ce registre. Tapez simplement :

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

et il vous sera demandé votre nom d'utilisateur, votre mot de passe (qui est votre clé API) et votre e-mail.

Avec un référentiel git multi-packages, vous pouvez utiliser Lerna pour faciliter la publication. Lerna s'accorde bien avec les espaces de travail du fil. Vous pouvez installer Lerna CLI globalement avec npm install --global lerna . Pour l'initier au sein de notre projet, nous exécuterons la commande suivante :

 lerna init --independent

La commande ci-dessus créera un fichier lerna.json à la racine du monorepo. Vous devrez ajouter les "useWorkspaces" : true et "npmClient": "yarn" manuellement ; vous devrez peut-être également spécifier le command.publish.registry s'il ne s'agit pas du npm public par défaut.

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

Ensuite, la commande lerna publish publie les packages qui ont été modifiés depuis la dernière version. Par défaut, Lerna exécute des invites pour le changement de version de chaque package mis à jour. Vous pouvez ignorer les invites en exécutant :

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

Vous pouvez également configurer Lerna pour utiliser la spécification des validations conventionnelles afin de déterminer le changement de version et de générer des fichiers CHANGELOG.md. Avec toutes les options disponibles, vous devriez pouvoir adapter la façon dont vous utilisez Lerna à votre flux de travail.

Utiliser un thème dans un projet

Maintenant, arrêtons le serveur de développement et adoptons le point de vue de l'utilisateur. Nous allons créer un nouveau projet, gatsby-wp-site , qui implémente gatsby-theme-wp-child en tant que package installé à partir du référentiel npm. Dans notre dossier de projet, nous allons installer nos quatre dépendances : gatsby , react , react react-dom et le thème lui-même. Puisque nous avons utilisé Cloudsmith pour publier @pehaa -scoped, nous devrons ajouter un fichier .npmrc où nous @pehaa -scoped repository comme ceci :

 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

Notre site est presque prêt. Nous n'avons qu'à créer un gatsby-config.file pour charger le thème et fournir l'URL WordPress. Une fois que c'est fait, nous sommes prêts à exécuter gatsby build .

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

Notre site est prêt.

Qu'en est-il de la personnalisation ? Nous pouvons encore profiter de l'observation. De plus, le niveau du projet est toujours prioritaire en termes d'observation. Voyons-le en action en remplaçant le composant Footer. À l'heure actuelle, notre pied de page est défini dans @pehaa/gatsby-theme-wp-child/src/components/Footer.js . Nous devons créer le dossier src et recréer la structure de fichiers suivante :

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

Avec la structure de fichiers ci-dessus, nous sommes prêts à fournir une nouvelle version du pied de page du site. Par exemple:

 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

Enfin, voyons comment nous pouvons travailler avec le thème CSS. Avec le code ci-dessous, correctement situé dans src/@chakra-ui/gatsby-plugin/theme.js , vous pouvez étendre le thème par défaut dans le projet.

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

Dans la plupart des cas, ce n'est pas exactement ce dont vous avez besoin. Le nouveau thème CSS ignore celui de gatsby-theme-wp-child , alors que vous voudriez plutôt étendre le thème CSS défini dans le thème enfant Gatsby. Ce dernier est possible puisque la fonction extendTheme permet de passer plusieurs objets. Pour que cela fonctionne, vous devez importer le thème CSS de gatsby-theme-wp-child et le passer comme deuxième argument à la fonction 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)

Vous pouvez voir le site en direct ici, il est déployé à partir de la branche principale de ce référentiel GitHub.

Emballer

Vous venez de voir le thème Gatsby en action. Avec l'approche thématique, vous pouvez configurer rapidement plusieurs sites Gatsby avec la plupart de leur code conservé dans les packages thématiques. Nous avons également vu comment séparer les parties du projet en packages et comment tirer parti de l'observation.

Dans notre exemple, nous avons suivi la configuration à deux thèmes avec une relation parent-enfant entre les thèmes. Ce n'est pas toujours un choix idéal.

Parfois, vous voudrez peut-être aller assez loin avec la personnalisation de l'interface utilisateur. Dans ce cas, vous pouvez envisager de charger et d'ombrager directement le thème parent au lieu d'utiliser celui de l'enfant. Dans un scénario réel, vous opteriez probablement pour quelques thèmes de niveau enfant responsables de différentes parties réutilisables de l'interface utilisateur (par exemple, commentaires, formulaires ou recherche).

Lectures complémentaires sur Smashing Magazine

• Construire une API avec des fonctions Gatsby
• Les fonctions sans serveur de Gatsby et la Station spatiale internationale
• Monétisez les logiciels open source avec les fonctions Gatsby et Stripe
• Smashing Podcast Épisode 20 Avec Marcy Sutton : Qu'est-ce que Gatsby ?