بناء ثيمات Gatsby لمواقع الويب التي تعمل بنظام WordPress

Gatsby هو إطار عمل مفتوح المصدر مبني على قمة React. باستخدام Gatsby ، يمكنك سحب البيانات من أي مكان (تقريبًا) واستخدامها لإنشاء مواقع ويب ثابتة أو ديناميكية. يمكن سحب البيانات من CMS ، مما يجعل WordPress بالتأكيد على الطاولة. تحصل على مزايا موقع الويب الثابت (السرعة والأمان والاستضافة الثابتة) بينما تستمر في إدارة المحتوى الخاص بك عبر لوحة تحكم WordPress.

تتمثل إحدى خصائص إطار عمل Gatsby في أنه يقترح موضوعات كأداة تخصيص. بصفتي شخصًا يتمتع بخلفية قوية في WordPress ، أجد مفهوم سمات Gatsby جذابًا بشكل خاص. اعتدت على تصميم وتطوير قوالب ووردبريس. ومع ذلك ، مع الاهتمام المتزايد بحلول Jamstack ، تحولت تدريجيًا نحو العمل مع WordPress كنظام CMS مقطوع الرأس. في هذه المقالة ، أود أن أشارك بعض المفاهيم التي تعلمتها من هذا الانتقال.

ملاحظة: قبل أن نذهب إلى أبعد من ذلك ، دعنا نركز على الأدوات التي سنستخدمها. يوفر Gatsby مكونًا إضافيًا رسميًا لبرنامج gatsby-source-wordpress. لجعلها تعمل ، نحتاج إلى إعداد نهاية WordPress الخاصة بنا. بتعبير أدق ، نحتاج إلى كشف بيانات WordPress بنكهة Gatsby عبر واجهة برمجة تطبيقات GraphQL. في الممارسة العملية ، هذا يعني تثبيت اثنين من إضافات WordPress WPGraphQL و WPGatsby. كلاهما متاح عبر مستودع إضافات WordPress الرسمي ولا يتطلب أي تكوين.

ما هي ثيمات غاتسبي؟

سمة Gatsby عبارة عن مجموعة من الوظائف المشتركة المستخرجة داخل حزمة Node.js. لذلك ، من المقرر نشر السمة (في سجل مثل npm) وإعادة استخدامها كعنصر تبعية قابل للتثبيت.

نظرًا لأننا نتحدث عن Gatsby و WordPress هنا ، فسوف أوضح ذلك على الفور - هناك أوجه تشابه مع سمات WordPress ، لكن لا ينبغي أن نساوي مفهوم سمات WordPress مع سمات Gatsby. بالنسبة لشخص لديه خلفية WordPress (مثلي) ، قد يكون الانفصال صعبًا في البداية.

قالب WordPress هو نظام إلزامي للقوالب يحدد ما نراه في الواجهة الأمامية. تنتهي مسؤولية سمة WordPress الجيدة هنا. لا ينبغي أن يقدم أي وظائف لأن الوظائف هي منطقة المكونات الإضافية. لذلك ، هناك فصل صارم بين السمات والإضافات في نظام WordPress البيئي. يجب أن تهتم السمات بطبقة العرض ، وتهتم المكونات الإضافية بالجوانب الوظيفية.

بعد تعريف Gatsby ، تكون السمات مسؤولة عن الوظائف . ألا يجب أن نسميها المكونات الإضافية إذن؟ في الواقع ، يحتوي Gatsby ، مثل WordPress ، على مكونات إضافية وسمات. الإضافات ، مثل السمات ، عبارة عن حزم Node.js قابلة للتثبيت تنفذ واجهات برمجة تطبيقات Gatsby. وفي الواقع ، سمة Gatsby هي مكون إضافي لـ Gatsby. إذا كان المكون الإضافي يمتلك قسمًا أو صفحة أو جزءًا من صفحة على موقع ما - فإننا نطلق عليه سمة.

علاوة على ذلك ، على عكس WordPress ، لا يتطلب Gatsby استخدام السمات لبناء موقع. بدلاً من ذلك ، من المحتمل أن تبدأ في إنشاء موقعك عن طريق إعداد مشروع منظم على النحو التالي:

لا بأس بذلك حتى يكون لديك أكثر من موقع تريد صيانته. في هذه الحالة ، قد ترغب في تلخيص الأجزاء المشتركة من العملية وإدارتها (الإصدار والتحديث) بشكل منفصل.

بفضل نظام السمات Gatsby ، يمكنك تجميع الأجزاء المشتركة في حزمة (أو حزم متعددة) ، ونشر الحزم وتثبيتها في النهاية عبر العديد من التطبيقات. لاحظ أنني استخدمت حزم صيغة الجمع - يمكنك الجمع بين موضوعات متعددة داخل المشروع.

ثيمات الطفل والتظليل

عند العمل مع Gatsby و WordPress ، ستحدد بعض الوظائف الأساسية المشتركة لجميع المشاريع. أعني هنا: تحديد مصادر البيانات وبناء الصفحات ديناميكيًا. يبدو أنه من المفيد أن يكون لديك موضوع يهتم بمنطق مصادر البيانات وإنشاء الصفحات. من ناحية أخرى ، قد تتغير الطريقة التي تقرر بها عرض صفحاتك من مشروع إلى آخر. مهما كان ما تحدده على المستوى الأساسي ، فربما تحتاج إلى تجاوزه في مرحلة ما.

أحد الأساليب الممكنة هو أن يكون لديك موضوع أساسي (أبوي) وبناء موضوعات فرعية فوق الموضوع الأساسي.

ماذا أعني بموضوع غاتسبي الطفل؟

دعنا ننتقل إلى مقارنة موضوعات WordPress الفرعية. تسمح لنا السمات الفرعية لـ WordPress بإضافة وظائف وتجاوز القوالب. إنها توفر طريقة آمنة لتحسين وتعديل سمة موجودة.

يستخدم قالب Gatsby الفرعي موضوعًا رئيسيًا كمكوِّن إضافي. يمكننا بعد ذلك استخدام مفهوم التظليل الذي يمنح السمة الفرعية القدرة على تجاوز ملفات النسق الأصل ؛ هذا مشابه لتجاوز قوالب WordPress في قالب فرعي. يعني التظليل أنه يمكننا تجاوز الملفات من دليل src المضمن في حزمة webpack. يجدر التأكيد على أن التظليل ممكن على مستوى المشروع (حيث نستهلك موضوعاتنا كحزم). سنراه في العمل لاحقًا في هذه المقالة.

مع WordPress ، نحن مقيدون بموضوع رئيسي واحد فقط ، وموضوع فرعي واحد فقط ، ولا يمكن إجراء مزيد من التسلسل. مع مرونة سمات Gatsby ، يمكننا الذهاب إلى أبعد من ذلك بكثير. من الممكن بناء تكوينات مختلفة من سلاسل الأبوين.

دعنا الآن نرى غاتسبي يعمل. في مثالنا ، سنبني نسختين ، gatsby-theme-wp-parent وموضوع الطفل gatsby-theme-wp-child . اخترت هذا الإعداد من أجل البساطة. في سيناريو العالم الواقعي ، قد ترغب في تقسيم وظائفك إلى المزيد من الموضوعات ، كل منها لديه بعض المسؤولية المحددة.

سننشر موضوعاتنا ، ونثبتها في مشروع ، ونضيف المزيد من التخصيص عبر التظليل على مستوى المشروع.

إعداد التطوير

يوضح الرسم التوضيحي الأخير بنية مشروع المستخدم النهائي ( الموقع) ، حيث يتم استهلاك السمات. يتم تثبيتها على أنها تبعيات المشروع. يفترض هذا الإعداد أن السمات متاحة عبر بعض مستودعات npm ، مما يعني أننا نشرناها بالفعل. نحن لم نصل إلى هناك بعد. نحتاج إلى بناء موضوعات الوالدين والطفل أولاً. ولكن كيف يبدو إعداد التطوير ؟ إن موضوعاتنا عبارة عن حزمتين مستقلتين ، لكننا نحتاج إلى العمل عليها بالتوازي في مشروع واحد أثناء التطوير. علاوة على ذلك ، نريد إعداد عرض توضيحي داخل نفس المشروع الذي ينفذ السمات مباشرة.

أحد الحلول الممكنة هو مساحات عمل الغزل. مع مساحات عمل الغزل ، نحن نعمل ضمن ريبو أحادي بملف قفل واحد على مستوى جذر المشروع. علاوة على ذلك ، يمكن ربط التبعيات معًا ، مما يعني أن مساحات العمل تعتمد على بعضها البعض ، ونستخدم الإصدارات المحلية أثناء التطوير.

كيفية إعداد مساحات عمل الغزل؟ أولاً ، تأكد من تثبيت الخيوط على مستوى العالم. بعد ذلك ، في جذر monorepo ، أضف ملف 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" } }

من خلال إعداد مساحات العمل ، يمكننا تشغيل البرامج النصية للتطوير أو الإنشاء من أي مكان في monorepo الخاص بنا عن طريق تحديد البرنامج النصي ومساحة العمل على النحو التالي:

 yarn workspace demo develop

بالمناسبة ، أنت لست مقيدًا بعرض demo واحد. على سبيل المثال ، يحتوي GatsbyWPThemes monorepo على العديد من العروض التوضيحية التي نضيفها إلى دليل examples . في هذه الحالة ، يعرّف ملف package.json على مستوى الجذر مساحات العمل على النحو التالي:

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

بناء ثيمات غاتسبي

بادئ ذي بدء ، نحن بحاجة إلى تثبيت 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 واجهة برمجة تطبيقات 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 كـ 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

إن مسؤولية القالب الفرعي هي جزء واجهة المستخدم ، ونحن بحاجة إلى تجاوز مخرجات العظم التي تم إنشاؤها بواسطة الموضوع الأصلي. لكي يعمل التظليل ، نحتاج إلى اتباع بنية الملفات من السمة الأصلية. على سبيل المثال ، لتجاوز مكون المنشور من gatsby-theme-wp-parent/src/components/Post.js Post نحتاج إلى إنشاء ملف 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 Theming

تبدو حلول CSS-in-JS التي تدعمها مناسبة تمامًا لموضوعات Gatsby. سيستخدم موضوع Gatsby child الخاص بنا إطار عمل Chakra UI ، وسنقوم بتخصيص سمة CSS الخاصة به بشكل طفيف. نعم ، تستخدم Chakra UI أيضًا مفهوم "السمة". في هذا السياق ، السمة هي كائن 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 في جذر monorepo. ستحتاج إلى إضافة "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-dom ، والموضوع نفسه. نظرًا لأننا استخدمنا Cloudsmith لنشر حزم @pehaa -scoped ، فسنضطر إلى إضافة ملف .npmrc حيث نحدد مستودع @pehaa -scoped مثل:

 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 child. هذا الأخير ممكن لأن وظيفة 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

• بناء API بوظائف Gatsby
• وظائف Gatsby Serverless ومحطة الفضاء الدولية
• استثمر البرامج مفتوحة المصدر باستخدام وظائف Gatsby و Stripe
• تحطيم بودكاست الحلقة 20 مع مارسي ساتون: ما هو غاتسبي؟