Создание тем Gatsby для веб-сайтов на базе WordPress

Gatsby — это фреймворк с открытым исходным кодом, построенный поверх React. С Gatsby вы можете получать данные (почти) из любого места и использовать их для создания статических или динамических веб-сайтов. Данные могут быть извлечены из CMS, что определенно приносит пользу WordPress. Вы получаете преимущества статического веб-сайта (скорость, безопасность, статический хостинг), продолжая управлять своим контентом через панель управления WordPress.

Одной из особенностей фреймворка Gatsby является то, что он предлагает темы в качестве инструмента настройки. Как человек с большим опытом работы с WordPress, я нахожу концепцию тем Gatsby особенно привлекательной. Раньше я проектировал и разрабатывал темы WordPress. Однако с ростом интереса к решениям Jamstack я постепенно переключился на работу с WordPress как безголовой CMS. В этой статье я хотел бы поделиться некоторыми концепциями, которые я извлек из этого перехода.

Примечание. Прежде чем двигаться дальше, давайте сосредоточимся на инструментах, которые мы собираемся использовать. Gatsby предоставляет официальный плагин gatsby-source-wordpress. Чтобы заставить его работать, нам нужно подготовить наш конец WordPress. Точнее, нам нужно предоставить данные WordPress в стиле Гэтсби через GraphQL API. На практике это означает установку двух плагинов WordPress WPGraphQL и WPGatsby. Оба доступны через официальный репозиторий плагинов WordPress и не требуют настройки.

Что такое темы Гэтсби?

Тема Gatsby — это набор общих функций, абстрагированных в пакете Node.js. Таким образом, тема предназначена для публикации (в реестре, например, npm) и повторного использования в качестве устанавливаемой зависимости.

Поскольку мы говорим здесь о Гэтсби и WordPress , сразу поясню — есть сходство с темами WordPress, но мы не должны отождествлять понятие тем WordPress с темами Гэтсби. Для тех, у кого есть опыт работы с WordPress (таких как я), диссоциация может быть сложной в начале.

Тема WordPress — это обязательная система шаблонов, которая определяет то, что мы видим во внешнем интерфейсе. На этом ответственность за хорошую тему WordPress заканчивается. Он не должен вводить какие-либо функциональные возможности, поскольку функциональные возможности являются территорией плагинов. Поэтому в экосистеме WordPress существует строгое разделение между темами и плагинами. Темы должны заботиться об уровне представления, а плагины — о функциональных аспектах.

Следуя определению Гэтсби, темы отвечают за функциональность . Разве мы не должны тогда называть их плагинами? Собственно, у Gatsby, как и у WordPress, есть и плагины, и темы. Плагины, как и темы, представляют собой устанавливаемые пакеты Node.js, реализующие API-интерфейсы Gatsby. И на самом деле тема Gatsby — это плагин Gatsby. Если плагину принадлежит раздел, страница или часть страницы на сайте — мы называем это темой.

Более того, в отличие от WordPress, Gatsby не требует использования тем для создания сайта. Вместо этого вы, вероятно, начнете создавать свой сайт, настроив проект, структурированный следующим образом:

Это нормально, пока у вас не будет более одного сайта для поддержки. В этом случае вы можете абстрагировать общие части процесса и управлять ими (версией и обновлением) по отдельности.

Благодаря системе тем Gatsby вы можете объединять общие части в пакет (или несколько пакетов), публиковать пакеты и, наконец, устанавливать их во множество приложений. Обратите внимание, что я использовал пакеты во множественном числе — вы можете комбинировать несколько тем в одном проекте.

Дочерние темы и затенение

При работе с Gatsby и WordPress вы определите некоторые основные функции, общие для всех проектов. Я имею в виду: поиск данных и динамическое создание страниц. Кажется, стоит иметь тему, которая заботится о логике поиска данных и создании страниц. С другой стороны, то, как вы решите отображать свои страницы, может меняться от одного проекта к другому. Что бы вы ни установили на базовом уровне, в какой-то момент вам, вероятно, потребуется переопределить.

Один из возможных подходов — иметь основную (родительскую) тему и создавать дочерние темы поверх основной.

Что я имею в виду под дочерней темой Гэтсби?

Приступим к сравнению дочерних тем WordPress. Дочерние темы WordPress позволяют нам добавлять функциональные возможности и переопределять шаблоны. Они обеспечивают безопасный способ улучшения и изменения существующей темы.

Дочерняя тема Gatsby использует родительскую тему в качестве плагина. Затем мы можем использовать концепцию затенения, которая дает дочерней теме возможность переопределять файлы родительской темы; это похоже на переопределение шаблонов WordPress в дочерней теме. Теневое копирование означает, что мы можем переопределить файлы из каталога src , включенного в пакет webpack. Стоит подчеркнуть, что затенение возможно на уровне проекта (где мы используем наши темы как пакеты). Мы увидим это в действии позже в этой статье.

В WordPress мы ограничены только одной родительской темой, только одной дочерней темой, и дальнейшая цепочка невозможна. С гибкостью тем Гэтсби мы можем пойти гораздо дальше. Можно построить различные конфигурации дочерних и родительских цепочек.

Давайте теперь посмотрим на тему Гэтсби в действии. В нашем примере мы создадим две темы: gatsby-theme-wp-parent и ее дочернюю тему gatsby-theme-wp-child . Я выбрал эту установку для простоты. В реальном сценарии вы можете захотеть разбить свои функции на несколько тем, каждая из которых несет определенную ответственность.

Мы опубликуем наши темы, установим их в проекте и добавим дальнейшую настройку с помощью теневого копирования на уровне проекта.

Настройка разработки

На последней иллюстрации изображена структура проекта конечного пользователя ( сайта) , где используются темы. Они устанавливаются как зависимости проекта. Эта настройка предполагает, что темы доступны через какой-то репозиторий npm, а это значит, что мы их уже опубликовали. Мы еще не там. Сначала нам нужно создать родительскую и дочернюю темы. Но как выглядит установка для разработки ? Наши темы — это два независимых пакета, но нам нужно работать над ними параллельно в рамках одного проекта в процессе разработки. Кроме того, мы хотим создать демонстрацию в том же проекте, который напрямую реализует темы.

Одно из возможных решений — рабочие области пряжи. С рабочими пространствами пряжи мы работаем в одном монорепозитории с одним файлом блокировки на корневом уровне проекта. Более того, зависимости могут быть связаны друг с другом, что означает, что рабочие области зависят друг от друга, и мы используем локальные версии во время разработки.

Как настроить рабочие пространства для пряжи? Во-первых, убедитесь, что пряжа установлена ​​глобально. Затем добавьте в корень вашего монорепозитория файл package.json , в котором указаны рабочие области:

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

Теперь каждая тема представляет собой подпапку внутри packages с собственным файлом package.json и пустой основной записью index.js . Я поступаю так с каждой темой, которую добавляю:

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

С package.json следующим образом:

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

Мы обсудим публикацию темы чуть дальше. Но пока отметим, что мы будем публиковать наши темы в виде пакетов с ограниченной областью действия; Я использую здесь свой никнейм @pehaa в качестве прицела. Помните, что если вы решите опубликовать пакеты с ограниченной областью действия в общедоступном реестре npm https://registry.npmjs.org, вы должны явно указать общедоступный доступ и добавить следующее в их файлы package.json :

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

В дополнение к темам нам также понадобится demo рабочее пространство, в котором мы будем опробовать наш код. Демо должно быть "private" пакетом, так как его не предполагается публиковать.

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

С настройкой рабочих областей мы можем запускать сценарии разработки или сборки из любого места в нашем монорепозитории, указав сценарий и рабочую область следующим образом:

 yarn workspace demo develop

Кстати, вы не ограничены одной demo . Например, наш GatsbyWPThemes GatsbyWPThemes содержит несколько демонстраций, которые мы добавляем в каталог examples . В этом случае файл package.json корневого уровня определяет рабочие пространства следующим образом:

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

Создание тем Гэтсби

В первую очередь нам нужно установить react , react react-dom и gatsby . Нам нужно установить эти три зависимости ( -P ) в каждой теме и в качестве зависимостей в нашей демонстрации. Мы также устанавливаем родительскую тему в качестве зависимости дочерней темы и дочернюю тему в качестве зависимости демо.

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

Примечание . Вы не можете добавить @pehaa/gatsby-theme-wp-parent или @pehaa/gatsby-theme-wp-child без номера версии. Вы должны указать его как @* или @1.0.0 . Без него npm попытается получить пакет из репозитория вместо использования локального. Позже, когда мы опубликуем наши пакеты с Lerna, все * будут автоматически обновлены до текущих версий темы и синхронизированы.

Родительская тема

Давайте теперь сосредоточимся на родительской теме и ее зависимостях:

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

Наша родительская тема отвечает за загрузку исходного плагина и трех плагинов, необходимых для обработки и отображения изображений. Загружаем их все в файл 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`, }, }, ], } }

Помимо поиска контента, нам нужно динамически строить маршруты для нашего контента WordPress. Нам нужно создать маршруты для статических страниц WordPress, отдельных сообщений, архива блога, архива категорий и архива тегов. Gatsby предоставляет API createPages как часть Gatsby Node API. Давайте посмотрим на код, отвечающий за создание отдельных сообщений.

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

Вы можете найти полный код в этом репозитории GitHub. Вы можете заметить, что это зависит от типа страницы. Для записи, страницы или архива все по-разному, особенно если для последних реализована нумерация страниц. Тем не менее, он следует той же схеме:

• запустить асинхронный graphql «получить элементы»;
• переберите полученные элементы и запустите вспомогательную функцию createPage для каждого элемента, передав:
  • тропинка,
  • component — файл шаблона; Гэтсби должен знать, что должна отображать каждая страница.
  • context — любые данные, которые могут понадобиться шаблону (указаны в поле component ).

Поскольку мы не хотим беспокоиться о части пользовательского интерфейса в родительской теме — мы делегируем ее компоненту, который будем затенять в дочерней теме.

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

Компонент Post имеет доступ к данным из запроса страницы graphql , определенного в файле шаблона. Наш компонент получает результаты запроса через реквизиты как props.data . Наш файл компонента отделен от шаблона, но имеет доступ к его данным. С помощью этой настройки мы можем скрыть компонент Post без необходимости переписывать запрос.

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

Детская тема

Теперь давайте перейдем к дочерней теме и добавим ее зависимости.

Примечание . Я решил использовать Chakra UI в качестве библиотеки компонентов, она основана на эмоциях и поставляется с собственным плагином Gatsby. Нам также необходимо установить стили, специфичные для контента WordPress, из @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

Дочерняя тема отвечает за часть пользовательского интерфейса, и нам нужно переопределить голый вывод, созданный родительской темой. Чтобы затенение работало, нам нужно следовать структуре файлов из родительской темы. Например, чтобы переопределить компонент Post из gatsby-theme-wp-parent/src/components/Post.js , нам нужно создать файл Post.js в gatsby-theme-wp-child/src/@pehaa/gatsby-theme-wp-parent/components . Промежуточная папка @pehaa соответствует объему пакета gatsby-theme-wp-parent .

Передача параметров в темы

Мы загружаем и настраиваем плагины gatsby в файле gatsby-config.js . В нашей настройке будет три файла конфигурации, по одному на каждый уровень, наша родительская тема, дочерняя тема и демоверсия.

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

На демонстрационном уровне конфигурация загружает дочернюю тему следующим образом:

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

Как вы можете видеть выше, мы передаем параметры в дочернюю тему. Они будут доступны в файле конфигурации на уровне дочерней темы. Это возможно, поскольку плагины Gatsby экспортируют конфигурацию как функцию. Таким образом, когда мы загружаем плагин, предоставляющий некоторые параметры, плагин получает их в качестве аргумента своей функции конфигурации. В частности, параметры, которые мы передаем теме, могут быть «перенаправлены» в тему родительского уровня следующим образом:

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

Давайте еще раз посмотрим на код выше. Обратите внимание, что мы определяем шрифты на уровне дочерней темы, но сохраняем возможность изменять их с помощью параметров темы.

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

При настройке наших тем мы должны помнить, что тема — это просто пакет, и конечный пользователь не имеет прямого доступа к его коду. Поэтому рекомендуется заранее подумать и выставить правильные настройки. Если наша тема загружает плагин, который требует настройки, нам, вероятно, следует передать параметры плагинов с уровня проекта (демо) полностью вниз.

Давайте рассмотрим пример. Наша родительская тема использует gatsby-source-wordpress , который извлекает данные из WordPress. Этот плагин поставляется с набором параметров, некоторые из которых могут иметь решающее значение для процесса сборки, например schema.requestConcurrency или schema.timeout . Но, опять же, родительская тема — это просто пакет, и конечный пользователь не может редактировать его gatsby-config . Это может показаться очевидным, но мы почему-то пропустили это в первоначальном выпуске Gatsby WP Themes. Однако с помощью быстрого исправления пользователь может передать параметры gatsby-plugin-source-wordpress из конфигурации проекта…

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

… через дочернюю и родительскую темы к целевому плагину:

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

CSS-темы

Решения CSS-in-JS, поддерживающие создание тем, хорошо подходят для тем Gatsby. Наша дочерняя тема Gatsby будет использовать структуру пользовательского интерфейса Chakra, и мы немного настроим ее тему CSS. Да, в пользовательском интерфейсе Chakra также используется понятие «тема». В этом контексте тема — это объект JavaScript, в котором хранятся значения стилей системы дизайна, масштабы и/или токены дизайна. Чтобы избежать путаницы, я буду называть ее «тема CSS». Мы уже установили необходимые пакеты @chakra-ui вместе с плагином Gatsby @chakra-ui/gatsby-plugin . Давайте изучим код плагина, чтобы узнать, как он работает. Он фактически заключает наше приложение Gatsby в ChakraProvider и предоставляет файл src/theme.js для затенения, так что мы можем действовать следующим образом:

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

Мы снова использовали концепцию затенения. Ключевым аспектом здесь является место, где мы создали файл theme.js .

Позже мы увидим, как скрыть тему CSS на уровне проекта пользователя.

Публикация тем с Лерной

Как только ваши темы будут готовы, вам нужно их опубликовать. Если вы хотите поделиться своим кодом публично, вы, скорее всего, опубликуете его в общедоступном реестре npm. И если вы никогда раньше не публиковали пакет, вы можете ознакомиться с процессом, поиграв с Verdaccio на своем локальном компьютере.

В Gatsby WP Themes мы используем премиальный сервис от Cloudsmith. Cloudsmith поддерживает полнофункциональные реестры для пакетов npm с премиальной опцией для частных реестров и бесплатным решением для общедоступных. Я продолжу использовать бесплатное решение Cloudsmith. После того, как вы создали свою учетную запись, создайте новый репозиторий; мой pehaa/gatsby-wp-theming .

Чтобы внести изменения в реестр Cloudsmith через командную строку, вам потребуется указать свои учетные данные для входа в этот реестр. Просто введите:

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

и вас попросят ввести имя пользователя, пароль (который является вашим API-КЛЮЧОМ) и адрес электронной почты.

С репозиторием git с несколькими пакетами вы можете использовать Lerna для облегчения публикации. Lerna хорошо сочетается с рабочими местами для пряжи. Вы можете установить Lerna CLI глобально с помощью npm install --global lerna . Чтобы инициировать его в нашем проекте, мы выполним следующую команду:

 lerna init --independent

Приведенная выше команда создаст файл lerna.json в корне монорепозитория. Вам нужно будет добавить "useWorkspaces" : true и "npmClient": "yarn" вручную; вам также может потребоваться указать command.publish.registry , если он не является общедоступным npm по умолчанию.

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

Затем команда lerna publish публикует пакеты, которые изменились с момента последней версии. По умолчанию Lerna запускает подсказки об изменении версии каждого обновляемого пакета. Вы можете пропустить подсказки, запустив:

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

Вы также можете настроить Lerna для использования спецификации обычных коммитов для определения изменения версии и создания файлов CHANGELOG.md. Имея все доступные опции, вы сможете адаптировать способ использования Lerna к своему рабочему процессу.

Использование темы в проекте

Теперь давайте остановим сервер разработки и взглянем на него с точки зрения пользователя. Мы создадим новый проект gatsby-wp-site , реализующий gatsby-theme-wp-child в виде пакета, установленного из репозитория npm. В папке нашего проекта мы установим четыре зависимости: gatsby , react , react react-dom и саму тему. Поскольку мы использовали Cloudsmith для публикации пакетов с @pehaa , нам нужно добавить файл .npmrc , в котором мы указываем репозиторий с областью @pehaa следующим образом:

 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

Наш сайт почти готов. Нам нужно только создать gatsby-config.file , чтобы загрузить тему и указать URL-адрес WordPress. Как только это будет сделано, мы готовы запустить gatsby build .

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

Наш сайт готов.

Как насчет настройки? Мы все еще можем воспользоваться преимуществами затенения. Более того, уровень проекта всегда имеет приоритет с точки зрения затенения. Давайте посмотрим на это в действии, переопределив компонент нижнего колонтитула. Прямо сейчас наш нижний колонтитул определен в @pehaa/gatsby-theme-wp-child/src/components/Footer.js . Нам нужно создать папку src и воссоздать следующую структуру файлов:

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

С приведенной выше структурой файлов мы готовы предоставить новую версию нижнего колонтитула сайта. Например:

 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

Наконец, давайте посмотрим, как мы можем работать с темой CSS. С кодом, как показано ниже, правильно расположенным в src/@chakra-ui/gatsby-plugin/theme.js , вы можете расширить тему по умолчанию в рамках проекта.

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

В большинстве случаев это не совсем то, что вам нужно. Новая тема CSS игнорирует тему из gatsby-theme-wp-child , тогда как вместо этого вы хотите расширить тему CSS, установленную в дочерней теме Gatsby. Последнее возможно, поскольку функция extendTheme позволяет передавать несколько объектов. Чтобы это работало, вам нужно импортировать тему CSS из gatsby-theme-wp-child и передать ее в качестве второго аргумента функции 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)

Вы можете увидеть сайт вживую здесь, он развернут из основной ветки этого репозитория GitHub.

Подведение итогов

Вы только что видели тематику Гэтсби в действии. С помощью тематического подхода вы можете быстро настроить несколько сайтов Gatsby, при этом большая часть их кода будет храниться в пакетах тем. Мы также увидели, как разделить части проекта на пакеты и как использовать преимущества затенения.

В нашем примере мы следовали настройке двух тем с отношениями родитель-потомок между темами. Это не всегда может быть идеальным выбором.

Иногда вы можете захотеть пойти довольно далеко с настройкой пользовательского интерфейса. В этом случае вы можете рассмотреть возможность загрузки и затенения непосредственно родительской темы вместо использования дочерней. В реальном сценарии вы, вероятно, выбрали бы несколько тем дочернего уровня, отвечающих за различные повторно используемые части пользовательского интерфейса (например, комментарии, формы или поиск).

Дальнейшее чтение журнала Smashing Magazine

• Создание API с функциями Гэтсби
• Бессерверные функции Gatsby и Международная космическая станция
• Монетизируйте программное обеспечение с открытым исходным кодом с помощью Gatsby Functions и Stripe
• Smashing Podcast Эпизод 20 с Марси Саттон: Что такое Гэтсби?