Crearea de teme Gatsby pentru site-uri web bazate pe WordPress

Gatsby este un cadru open-source construit pe React. Cu Gatsby, puteți extrage date de (aproape) oriunde și le puteți utiliza pentru a genera site-uri web statice sau dinamice. Datele pot fi extrase dintr-un CMS, ceea ce aduce cu siguranță WordPress la masă. Obțineți avantajele unui site web static (viteză, securitate, găzduire statică) în timp ce continuați să vă gestionați conținutul printr-un tablou de bord WordPress.

Una dintre particularitățile framework-ului Gatsby este că propune teme ca instrument de personalizare. În calitate de persoană cu un fundal puternic în WordPress, găsesc conceptul de teme Gatsby deosebit de atrăgător. Am creat și dezvoltat teme WordPress. Cu toate acestea, odată cu interesul tot mai mare pentru soluțiile Jamstack, am trecut treptat către lucrul cu WordPress ca un CMS fără cap. În acest articol, aș dori să împărtășesc câteva concepte pe care le-am învățat din această tranziție.

Notă: înainte de a merge mai departe, să ne concentrăm asupra instrumentelor pe care le vom folosi. Gatsby oferă un plugin oficial gatsby-source-wordpress. Pentru ca acesta să funcționeze, trebuie să ne pregătim finalul WordPress. Mai precis, trebuie să expunem datele WordPress cu aromă de Gatsby printr-un API GraphQL. În practică, asta înseamnă instalarea a două pluginuri WordPress WPGraphQL și WPGatsby. Ambele sunt disponibile prin intermediul depozitului oficial de pluginuri WordPress și nu necesită nicio configurare.

Care sunt temele Gatsby?

Tema Gatsby este o mulțime de funcționalități partajate abstractizate într-un pachet Node.js. Prin urmare, o temă este destinată să fie publicată (într-un registru precum npm) și reutilizată ca dependență instalabilă.

Deoarece aici vorbim despre Gatsby și WordPress , o voi clarifica imediat - există asemănări cu temele WordPress, dar nu ar trebui să echivalăm noțiunea de teme WordPress cu temele Gatsby. Pentru cineva cu un fundal WordPress (ca mine), disocierea poate fi o provocare la început.

O temă WordPress este un sistem obligatoriu de șabloane care definește ceea ce vedem pe front end. Responsabilitatea unei teme WordPress bune se termină aici. Nu ar trebui să introducă nicio funcționalitate, deoarece funcționalitățile sunt teritoriul pluginurilor. Există, așadar, o separare strictă între teme și pluginuri în ecosistemul WordPress. Temele ar trebui să aibă grijă de stratul de prezentare, iar pluginurile să aibă grijă de aspectele funcționale.

După definiția lui Gatsby, temele sunt responsabile pentru funcționalități . Atunci nu ar trebui să le numim pluginuri? De fapt, Gatsby, la fel ca WordPress, are atât pluginuri, cât și teme. Pluginurile, la fel ca și temele, sunt pachete Node.js instalabile care implementează API-urile Gatsby. Și, de fapt, o temă Gatsby este un plugin Gatsby. Dacă un plugin deține o secțiune, o pagină sau o parte a unei pagini de pe un site - îl numim o temă.

În plus, spre deosebire de WordPress, Gatsby nu necesită utilizarea temelor pentru a construi un site. În schimb, ați începe probabil să vă creați site-ul prin configurarea unui proiect structurat după cum urmează:

E ok până când aveți mai multe site-uri de întreținut. În acest caz, este posibil să doriți să abstrageți părțile comune ale procesului și să le gestionați (versiune și actualizare) separat.

Datorită sistemului de tematică Gatsby, puteți să grupați părțile partajate într-un pachet (sau mai multe pachete), să publicați pachetele și, în final, să le instalați în numeroase aplicații. Rețineți că am folosit pachetele cu forma plurală - puteți combina mai multe teme într-un proiect.

Teme pentru copii și umbre

Când lucrați cu Gatsby și WordPress, veți identifica câteva funcționalități de bază care sunt comune pentru toate proiectele. Mă refer aici: aprovizionarea datelor și construirea dinamică a paginilor. Se pare că merită să existe o temă care să aibă grijă de logica de aprovizionare a datelor și de crearea paginilor. Pe de altă parte, modul în care decideți să vă afișați paginile se poate schimba de la un proiect la altul. Indiferent de ce ai setat la nivelul de bază, probabil că va trebui să anulezi la un moment dat.

Una dintre abordările posibile este de a avea o temă de bază (părinte) și de a construi teme pentru copii peste cea de bază.

Ce vreau să spun prin tematică de copil Gatsby?

Să continuăm cu o comparație a temelor copil WordPress. Temele copil WordPress ne permit să adăugăm funcționalități și să înlocuim șabloanele. Ele oferă o modalitate sigură de a îmbunătăți și de a modifica o temă existentă.

O temă copil Gatsby folosește o temă părinte ca plugin. Putem folosi apoi conceptul de umbrire care oferă temei copil capacitatea de a suprascrie fișierele temei părinte; este similar cu suprascrierea șabloanelor WordPress într-o temă copil. Umbrirea înseamnă că putem suprascrie fișierele din directorul src inclus în pachetul webpack. Merită subliniat faptul că umbrirea este posibilă la nivel de proiect (unde ne consumăm temele ca pachete). O vom vedea în acțiune mai târziu în acest articol.

Cu WordPress, suntem limitați la o singură temă părinte, la o singură temă copil și nu este posibilă nicio înlănțuire ulterioară. Cu flexibilitatea temelor Gatsby, putem merge mult mai departe. Este posibil să construiți diferite configurații de lanțuri copil-părinte.

Să vedem acum tematica lui Gatsby în acțiune. În exemplul nostru, vom construi două teme, gatsby-theme-wp-parent și tema copilului gatsby-theme-wp-child . Am ales această configurație de dragul simplității. Într-un scenariu din lumea reală, este posibil să doriți să vă descompuneți funcționalitățile în mai multe teme, fiecare având o anumită responsabilitate.

Vom publica temele noastre, le vom instala într-un proiect și vom adăuga personalizare suplimentară prin umbrarea la nivel de proiect.

Configurare dezvoltare

Ultima ilustrație ilustrează structura proiectului utilizatorului final ( site-ul) , unde sunt consumate temele. Sunt instalate ca dependențe ale proiectului. Această configurare presupune că temele sunt disponibile prin intermediul unor depozite npm, ceea ce înseamnă că le-am publicat deja. Nu suntem încă acolo. Trebuie să construim mai întâi temele pentru părinți și copii. Dar cum arată configurația de dezvoltare ? Temele noastre sunt două pachete independente, dar trebuie să le lucrăm în paralel în cadrul unui singur proiect în timpul dezvoltării. Mai mult, dorim să înființăm un demo în cadrul aceluiași proiect care implementează temele direct.

Una dintre soluțiile posibile sunt spațiile de lucru pentru fire. Cu spațiile de lucru cu fire, lucrăm într-un singur mono-repo cu un singur fișier de blocare la nivel de rădăcină de proiect. Mai mult, dependențele pot fi legate între ele, ceea ce înseamnă că spațiile de lucru depind unul de celălalt, iar noi folosim versiunile locale în timpul dezvoltării.

Cum să configurați spațiile de lucru pentru fire? În primul rând, asigurați-vă că aveți fire instalate la nivel global. Apoi, la rădăcina monorepo-ului, adăugați fișierul package.json care specifică spațiile de lucru:

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

Acum, fiecare temă este un subdosar în cadrul packages cu propriul fișier package.json și o intrare principală goală index.js . Proced așa cu fiecare temă pe care o adaug:

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

Cu package.json , după cum urmează:

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

Vom discuta despre publicarea temei puțin mai departe. Dar, pentru moment, să remarcăm că vom publica temele noastre ca pachete cu scop; Folosesc porecla mea @pehaa ca scop aici. Rețineți că, dacă decideți să publicați pachete cu scop în registrul public npm https://registry.npmjs.org, trebuie să precizați accesul public în mod explicit și să adăugați următoarele fișiere package.json :

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

Pe lângă teme, vom avea nevoie și de un spațiu de lucru demo din care vom încerca codul nostru. Demo-ul trebuie să fie un pachet "private" , deoarece nu ar trebui să fie publicat.

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

Odată cu configurarea spațiilor de lucru, putem rula scripturile de dezvoltare sau de construire de oriunde în monorepo-ul nostru, specificând scriptul și spațiul de lucru astfel:

 yarn workspace demo develop

Apropo, nu sunteți limitat la un singur demo . De exemplu, monorepo-ul nostru GatsbyWPThemes conține mai multe demonstrații pe care le adăugăm în directorul de examples . În acest caz, fișierul package.json la nivel rădăcină definește spațiile de lucru după cum urmează:

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

Construirea temelor Gatsby

În primul rând, trebuie să instalăm react , react-dom și gatsby . Trebuie să instalăm aceste trei ca dependențe peer ( -P ) în fiecare temă și ca dependențe în demonstrația noastră. De asemenea, instalăm tema părinte ca dependență de tema copilului și tema copil ca dependență a demonstrației.

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

Notă : nu puteți adăuga @pehaa/gatsby-theme-wp-parent sau @pehaa/gatsby-theme-wp-child fără un număr de versiune. Trebuie să-l specificați ca @* sau @1.0.0 . Fără el, npm va încerca să preia pachetul din depozit în loc să îl folosească pe cel local. Mai târziu, când vom publica pachetele noastre cu Lerna, toate * vor fi actualizate automat la versiunile actuale ale temei și ținute sincronizate.

Tema Părinte

Să ne concentrăm acum pe tema părinte și pe dependențele acesteia:

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

Responsabilitatea temei noastre părinte este de a încărca pluginul sursă și trei pluginuri necesare pentru procesarea și afișarea imaginilor. Le încărcăm pe toate în fișierul 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`, }, }, ], } }

Pe lângă aprovizionarea conținutului, trebuie să construim rute pentru conținutul nostru WordPress în mod dinamic. Trebuie să creăm rute pentru paginile statice WordPress, postările individuale, arhiva blogului, arhiva categoriilor și arhiva etichetelor. Gatsby furnizează API-ul createPages ca parte a API-ului Gatsby Node. Să aruncăm o privire la codul responsabil pentru crearea postărilor individuale.

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

Puteți găsi codul complet în acest depozit GitHub. Este posibil să observați că acesta variază în funcție de tipul paginii. Este diferit pentru o postare, o pagină sau o arhivă, mai ales cu paginarea implementată pentru aceasta din urmă. Totuși, urmează același model:

• rulați o interogare asincronă graphql „obține articole”;
• treceți peste elementele rezultate și rulați funcția helper createPage pentru fiecare articol, trecând:
  • calea,
  • component — fișierul șablon; Gatsby trebuie să știe ce trebuie să afișeze fiecare pagină,
  • context — indiferent de date de care șablonul (furnizat în câmpul component ) ar putea avea nevoie.

Deoarece nu vrem să ne îngrijorăm cu privire la partea UI din tema părinte - o delegăm componentei pe care o vom umbri în tema copil.

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

Componenta Post are acces la datele din interogarea paginii graphql definită în fișierul șablon. Componenta noastră primește rezultatele interogării prin elemente de recuzită ca props.data . Fișierul nostru component este separat de șablon, dar are acces la datele acestuia. Cu această configurare, putem să umbrăm componenta Post fără a fi nevoie să rescriem interogarea.

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

Tema Copilului

Acum, să trecem la tema copil și să adăugăm dependențele acesteia.

Notă : Am ales să folosesc Chakra UI ca bibliotecă de componente, se bazează pe emoție și vine cu propriul plugin Gatsby. De asemenea, trebuie să instalăm stiluri specifice conținutului WordPress din @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

Responsabilitatea temei copil este partea interfeței de utilizare și trebuie să suprascriem rezultatul general generat de tema părinte. Pentru ca umbrirea să funcționeze, trebuie să urmărim structura fișierelor din tema părinte. De exemplu, pentru a suprascrie componenta Post din gatsby-theme-wp-parent/src/components/Post.js , trebuie să creăm un fișier Post.js în gatsby-theme-wp-child/src/@pehaa/gatsby-theme-wp-parent/components . Dosarul intermediar @pehaa corespunde domeniului de aplicare al pachetului gatsby-theme-wp-parent .

Trecerea de opțiuni la teme

Încărcăm și configurăm pluginuri gatsby într-un fișier gatsby-config.js . Vom avea trei fișiere de configurare în configurația noastră, câte unul la fiecare nivel, tema noastră părinte, tema copil și demo.

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

La nivel demo, configurația încarcă tema copil astfel:

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

După cum puteți vedea mai sus, trecem opțiuni pentru tema copil. Acestea vor fi disponibile în fișierul de configurare la nivelul temei copil. Acest lucru este posibil, deoarece pluginurile Gatsby au configurația exportată ca funcție. Astfel, atunci când încărcăm un plugin care oferă unele opțiuni, pluginul le primește ca argument al funcției sale de configurare. În special, opțiunile pe care le transmitem unei teme pot fi „redirecționate” către tema sa la nivel de părinte astfel:

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

Să ne uităm din nou la codul de mai sus. Rețineți că definim fonturi la nivelul temei copil, dar păstrăm posibilitatea de a le modifica prin opțiunile temei.

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

Când ne configuram temele, ar trebui să ne amintim că o temă este doar un pachet, iar utilizatorul final nu accesează direct codul ei. Prin urmare, este o idee bună să gândiți înainte și să expuneți setările adecvate. Dacă tema noastră încarcă un plugin care necesită configurare, probabil că ar trebui să trecem opțiunile de pluginuri de la nivelul proiectului (demo) până la capăt.

Să ne uităm la un exemplu. Tema noastră părinte folosește gatsby-source-wordpress care preia datele de la WordPress. Acest plugin vine cu o mulțime de opțiuni, unele dintre ele posibil critice pentru procesul de construire, cum ar fi schema.requestConcurrency sau schema.timeout . Dar, din nou, tema părinte este doar un pachet, iar utilizatorul final nu își poate edita fișierul gatsby-config . Poate părea evident, dar am ratat-o ​​cumva în lansarea inițială a Gatsby WP Themes. Cu toate acestea, cu o remediere rapidă, utilizatorul poate trece gatsby-plugin-source-wordpress din configurația proiectului...

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

… prin tema copil și părinte la pluginul de destinație:

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

Tematică CSS

Soluțiile CSS-in-JS care acceptă tematica par potrivite pentru temele Gatsby. Tema noastră pentru copil Gatsby va folosi cadrul Chakra UI și vom personaliza ușor tema CSS. Da, Chakra UI folosește și noțiunea de „temă”. În acest context, o temă este un obiect JavaScript care stochează valorile stilului sistemului de proiectare, scalele și/sau simbolurile de proiectare. Pentru a evita orice confuzie, mă voi referi la ea ca o „temă CSS”. Am instalat deja pachetele @chakra-ui necesare împreună cu pluginul Gatsby @chakra-ui/gatsby-plugin . Să explorăm codul pluginului pentru a afla cum funcționează. De fapt, include aplicația noastră Gatsby în ChakraProvider și expune fișierul src/theme.js pentru umbrire, astfel încât să putem proceda astfel:

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

Încă o dată, am folosit conceptul de umbrire. Aspectul cheie aici este locația în care am creat fișierul theme.js .

Mai târziu, vom vedea cum să umbrăm tema CSS la nivelul de proiect al utilizatorului.

Publicarea Teme Cu Lerna

Odată ce temele sunt gata, trebuie să le publicați. Dacă doriți să partajați codul în mod public, cel mai probabil îl veți publica în registrul public npm. Și dacă nu ați publicat niciodată un pachet înainte, vă puteți familiariza cu procesul jucând cu Verdaccio pe computerul dvs. local.

La Gatsby WP Themes, folosim un serviciu premium de la Cloudsmith. Cloudsmith acceptă registre cu funcții complete pentru pachetele npm cu opțiunea premium pentru registre private și o soluție gratuită pentru cele publice. Voi continua cu o soluție gratuită Cloudsmith. După ce v-ați creat contul, creați un nou depozit; al meu este pehaa/gatsby-wp-theming .

Pentru a face modificări în registrul dvs. Cloudsmith prin linia de comandă, va trebui să furnizați acreditările dvs. de conectare pentru acest registru. Doar tastați:

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

și vi se va cere numele dvs. de utilizator, parola (care este cheia dvs. API) și adresa de e-mail.

Cu un depozit git cu pachete multiple, este posibil să doriți să utilizați Lerna pentru a facilita publicarea. Lerna se potrivește bine cu spațiile de lucru din fire. Puteți instala Lerna CLI la nivel global cu npm install --global lerna . Pentru a o iniția în cadrul proiectului nostru, vom rula următoarea comandă:

 lerna init --independent

Comanda de mai sus va crea un fișier lerna.json în rădăcina monorepo. Va trebui să adăugați "useWorkspaces" : true și "npmClient": "yarn" ; de asemenea, poate fi necesar să specificați command.publish.registry dacă nu este cel public implicit npm.

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

Apoi, comanda lerna publish publică pachete care s-au schimbat de la ultima ediție. În mod implicit, Lerna rulează solicitări pentru modificarea versiunii fiecărui pachet care este actualizat. Puteți sări peste solicitări rulând:

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

De asemenea, puteți configura Lerna să folosească specificația convențională de comitere pentru a determina decalajul versiunii și pentru a genera fișiere CHANGELOG.md. Cu toate opțiunile disponibile, ar trebui să puteți adapta modul în care utilizați Lerna la fluxul dvs. de lucru.

Utilizarea unei teme într-un proiect

Acum, să oprim serverul de dezvoltare și să luăm perspectiva utilizatorului. Vom crea un nou proiect, gatsby-wp-site , care implementează gatsby-theme-wp-child ca pachet instalat din depozitul npm. În folderul nostru de proiect, vom instala cele patru dependențe: gatsby , react , react-dom și tema în sine. Deoarece am folosit Cloudsmith pentru a publica pachete @pehaa -scoped, va trebui să adăugăm un fișier .npmrc unde specificăm @pehaa -scoped astfel:

 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

Site-ul nostru este aproape gata. Trebuie doar să creăm un gatsby-config.file pentru a încărca tema și a furniza URL-ul WordPress. Odată ce este gata, suntem gata să rulăm gatsby build .

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

Site-ul nostru este gata.

Ce zici de personalizare? Încă putem profita de umbră. Mai mult, nivelul de proiect are întotdeauna prioritate în ceea ce privește umbrirea. Să-l vedem în acțiune, suprascriind componentei Subsol. În acest moment, subsolul nostru este definit în @pehaa/gatsby-theme-wp-child/src/components/Footer.js . Trebuie să creăm folderul src și să recreăm următoarea structură de fișiere:

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

Cu structura de fișiere de mai sus, suntem gata să oferim o nouă versiune a subsolului site-ului. De exemplu:

 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

În sfârșit, să vedem cum putem lucra cu tema CSS. Cu codul de mai jos, localizat corect în src/@chakra-ui/gatsby-plugin/theme.js , puteți extinde tema implicită în cadrul proiectului.

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

În cele mai multe cazuri, acest lucru nu este exact ceea ce aveți nevoie. Noua temă CSS o ignoră pe cea de la gatsby-theme-wp-child , în timp ce ați dori în schimb să extindeți tema CSS setată în tema copil Gatsby. Acesta din urmă este posibil, deoarece funcția extendTheme vă permite să treceți mai multe obiecte. Pentru ca aceasta să funcționeze, trebuie să importați tema CSS din gatsby-theme-wp-child și să o transmiteți ca al doilea argument funcției 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)

Puteți vedea site-ul live aici, este implementat din ramura principală a acestui depozit GitHub.

Încheierea

Tocmai ați văzut tematica lui Gatsby în acțiune. Cu abordarea temei, puteți configura rapid mai multe site-uri Gatsby cu cea mai mare parte a codului lor menținut în pachetele tematice. Am văzut, de asemenea, cum să separăm părți ale proiectului în pachete și cum să profităm de umbră.

În exemplul nostru, am urmărit configurația cu două teme cu o relație părinte-copil între teme. Este posibil să nu fie întotdeauna o alegere ideală.

Uneori, este posibil să doriți să mergeți destul de departe cu personalizarea UI. În acest caz, ați putea lua în considerare încărcarea și umbrirea directă a temei părinte, în loc să o utilizați pe cea secundară. Într-un scenariu din lumea reală, probabil că ați opta pentru câteva teme la nivel de copil responsabile pentru diferite părți reutilizabile ale interfeței de utilizare (de exemplu, comentarii, formulare sau căutare).

Citiri suplimentare despre Smashing Magazine

• Construirea unui API cu funcții Gatsby
• Funcțiile fără server Gatsby și Stația Spațială Internațională
• Monetizați software-ul open-source cu funcții Gatsby și Stripe
• Smashing Podcast Episodul 20 cu Marcy Sutton: Ce este Gatsby?