تقديم جسر React-Gutenberg: دعم كتلة مقطوعة الرأس لتجربة تحرير أفضل

أنت متحمس للفرص التي يقدمها WordPress بدون رأس ، لكن فريق التسويق لعميلك مرتبط بمحرر WYSIWYG Gutenberg.

شاهد كيف يجمع دعم كتلة Gutenberg الجديد من Faust للمشاريع بدون رأس بين الاثنين لتحديث تطويرك مع تمكين جهات التسويق لديك.

مكبرات الصوت:

• تيريزا غوبل ، مهندس برمجيات في WP Engine
• بليك ويلسون ، مهندس برمجيات أول في WP Engine

شرائح الجلسة:

نص:

تيريزا جوبل: مرحبًا بكم. اسمي تيريزا غوبل. أنا مهندس برمجيات مع WP Engine أعمل في فريق Faust.

وأنا هنا مع Blake Wilson ، كبير مهندسي البرمجيات ، لأعرفك على React-Gutenberg Bridge - دعم الكتلة بدون رأس للحصول على تجربة تحرير أفضل. مرحباً. هيا بنا نبدأ.

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

إذن ها هي المشكلة. لا توجد طريقة مبسطة لترجمة كتل Gutenberg من WordPress إلى واجهة أمامية مقطوعة الرأس. الحلول الموجودة ليست قابلة للتطوير أو بديهية حتى الآن لتوفير تجربة مطور يمكن للمطورين بدون رأس توقعها.

يكسر الفصل القدرة على استخدام محتوى كتلة Gutenberg في المحرر بشكل طبيعي. وتُترك الوكالات لتتساءل عن كيفية المضي في جعلها على طريقتها الخاصة أو من الصفر مع القليل من التوجيه. ويبقى الكثير من الأسئلة التي لم تتم الإجابة عليها للناس.

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

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

تحتوي الواجهة الخلفية لموقع الويب الخاص بك المستند إلى React على كتل Gutenberg الخاصة بها ، والتي يتم الكشف عنها بواسطة المكون الإضافي WPGraphQL Content Blocks. يعرض محتوى block.json لـ WPGraphQL. يوفره للمكوِّن الإضافي ، المسمى WPGraphQL.

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

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

بليك ويلسون: شكرًا تيريزا. مرحباً جميعاً. أنا بليك ويلسون. أنا مهندس برمجيات كبير هنا في WP Engine.

وأنا عضو في فريق Faust JS لبناء فاوست. لقد حصلت على عرض توضيحي رائع حقًا لكم اليوم يعرض المكونين اللذين قمنا ببنائهما للمساعدة في تنظيم جسر React-Gutenberg هذا. لذلك دعونا ندخلها مباشرة.

لبدء الأشياء ، سأريك ما لدي هنا من أجل الإعداد الخاص بي. وبعد ذلك يمكننا الدخول في الشفرة الفعلية ومعرفة ما لدينا هناك. بالنسبة للمبتدئين ، لدي موقع WordPress يعمل هنا على Local.

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

ثم حصلت على كتل محتوى WPGraphQL. إذن هذا هو أحد المكونات الإضافية التي أنشأناها للمساعدة في تسهيل جسر React-Gutenberg هذا. يتكون هذا الحل من جزأين رئيسيين.

لذلك لدينا واحدة من القطع التي تعرض بيانات Gutenberg Block برمجيًا من خلال WPGraphQL ، ثم جزء آخر لاستهلاك ذلك على الواجهة الأمامية لـ Faust JS. لنبدأ بإلقاء نظرة على WPGraphQL Content Blocks وكيف يعمل ذلك.

لذلك سننطلق إلى IDE الرسومي الخاص بنا. وقد تم إعداد هذا الاستعلام هنا للحصول على بيانات الصفحة. في هذه الحالة ، نحصل فقط على عنوان الصفحة.

إذن ما تفعله قوالب محتوى GraphQL هو عرض نوع كتل المحتوى في مخطط GraphQL الخاص بك. لذلك إذا كتبنا كتل المحتوى ، يمكنك أن ترى هنا ، نحصل على معلومات لهذه الصفحة المعينة وجميع الكتل الموجودة في هذه الصفحة. دعنا نذهب ونعدل هذه الصفحة ونضيف بعض المحتوى.

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

وسنقوم بعمل عمود 50/50. دعنا نضيف فقرة في هذا النصف ، ثم في صورة في هذا النصف. لدي صورة هنا في مكتبة الوسائط الخاصة بي. دعنا نمضي قدمًا وإسقاط هذا.

ويمكنك أن ترى هنا ، لدينا عمودين. مرة أخرى ، فقرة على اليسار وصورة على اليمين. لذلك دعونا نقوم بتحديث هذا. ودعنا نعود إلى WPGraphQL Content Blocks ونرى ما نحصل عليه نتيجة لذلك.

يمكنك أن ترى هنا ، لدينا الآن كتلتان للمحتوى. أول واحد هنا هو العمود الأساسي ، العمود الأساسي. وبعد ذلك نحصل على HTML داخل ذلك.

لذا فإن الشيء العظيم في WPGraphQL Content Blocks هو أننا نتعامل مع InnerBlocks أيضًا. يمكنك أن ترى هنا إذا أضفنا معلمة إلى كتل المحتوى تسمى Flat true ، يمكنك أن ترى الآن أننا نحصل بالفعل على جميع الكتل التي كانت موجودة في تلك الأعمدة. لذلك نحن نتعامل مع هذه الحالة من أجلك أيضًا.

نحصل على عمود أساسي ، عمود أساسي ، فقرة أساسية ، صورة أساسية. لذلك يتم كل ذلك برمجيًا من أجلك. والآن ، يمكنك استخدام بيانات الكتلة هذه على واجهتك الأمامية. لذلك دعونا نحفر أعمق قليلاً هنا.

لنفترض أننا نريد بعض السمات الخاصة بذلك. يمكننا استخدام ذلك باستخدام اتحاد في GraphQL. لذلك سنفعل في الصورة الأساسية ، نحصل على السمات. ودعنا نقول أننا نريد التسمية التوضيحية ، على سبيل المثال.

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

وإذا قمنا بتحديث هذا الاستعلام ، يمكننا أن نرى الآن ، أننا نحصل على التسمية التوضيحية الخاصة بي كسمة مناسبة في WPGraphQL Content Blocks. إذن هذا هو الجزء الأول من الحل. الآن ، يمكننا بالفعل الحصول على جميع بيانات Gutenberg Block الخاصة بنا واستخدامها لاستهلاكها في الواجهة الأمامية.

لذلك دعونا ننتقل إلى VS Code ، وسنرى كيف نتعامل مع هذه القطعة. هذا مثال على مشروع Faust JS الذي جمعته معًا. انه بسيط جدا. يعتمد على Faust Scaffold Blueprint ، ولكن مع بعض التكوين الإضافي للتعامل مع هذه الكتل.

لذا إذا ألقينا نظرة على الحزمة JSON ، يمكنك أن ترى هنا بعض التبعيات هنا ، بعض حزم Faust المعتادة ، مثل core و CLI. لدينا أيضًا Faust VP Blocks. إذن هذه واحدة من تلك الحزم التي توفر جميع وظائف المساعد الخاصة بنا.

لدينا أيضًا بعض تبعيات WordPress للتعامل مع الأنماط وما إلى ذلك. ستلاحظ هنا أيضًا أن لدينا دليل WP Blocks هذا. هذا هو المكان الذي تعيش فيه كل الكتل الخاصة بنا للواجهة الأمامية ، وتعمل كسجل لجميع الكتل التي نستخدمها في الواجهة الأمامية.

يمكنك أن ترى أن لدينا ملف index.js. وهذا في الأساس كائن يحدد كل الكتل التي نستخدمها في الواجهة الأمامية. يمكنك أن ترى هنا ، لدينا فقرة أساسية وعمود أساسي وأعمدة أساسية وصورة أساسية.

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

وسيكون هذا متاحًا في pages_app. لذلك يمكنك أن ترى هنا لدينا هذا المكون ، هذا المزود ، مزود WordPress Blocks. ويقبل خاصية التكوين التي تقبل الكتل. يمكنك أن ترى هنا أننا نستورد كتلًا من WP Blocks ، فهرس هذا الدليل ، ونقوم بتمريره إلى كائن التكوين.

لذلك ، ما يقوله هذا هو أن موفر WordPress Blocks يلف تطبيقك بالكامل ويعطي سياقًا لكل هذه الكتل لتطبيقك بالكامل. الآن ، دعنا نذهب إلى قوالب WP في قالبنا الفردي. ويمكنك أن ترى هنا أننا ندعو عارض WordPress Blocks مع دعامة من كتل المحتوى. إذن هذه هي بيانات الكتلة التي نحصل عليها من WPGraphQL.

حسنًا ، هذا يكفي بشأن الإعداد. دعنا ندير هذا ونرى كيف يبدو في العمل. لذلك سأقوم بتشغيل NPM run dev ، والذي سينشئ بيئة مطورة على localhost 3000. والصفحة التي كنا نعمل عليها من قبل كانت عبارة عن عينة مائلة للصفحة ، لذلك سأزور localhost 3000 عينة مائلة لرؤية تلك Gutenberg الكتل التي أنشأناها من قبل.

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

لذلك قد تقول ، هذا يبدو رائعًا وكل شيء ، لكن هل يمكننا تعديل الأنماط؟ هل يمكننا تغيير حجم الخط؟ يمكنك بالتأكيد.

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

دعنا نخرج التسمية التوضيحية. وسنقوم بتحديث ذلك. ويمكنك أن ترى هنا أن هذه الأنماط تنطبق الآن. ويمكنك رؤيتها على واجهتك الأمامية.

لذلك نحن نعيد تجربة الناشر التي لا تتوقعها في WordPress إلى موقع WordPress بدون رأس. شيء رائع آخر حول هذا هو أنك تحصل الآن على بيانات برمجية لهذه الكتل ، يمكنك جعل مكون React الخاص بك بميزات خاصة بإطار العمل ، مثل الصورة التالية. الآن ، بدلاً من مجرد عرض HTML الذي تحصل عليه من WPGraphQL ، يمكننا الآن استخدام تلك البيانات البرمجية لإنشاء مكون يعرض جميع صورنا في Gutenberg مع الصورة التالية ، مما يمنحنا تحميلًا بطيئًا وأداء أفضل وصورًا محسّنة بشكل أفضل بشكل عام ، مما يخلق تجربة مستخدم أفضل لمستخدمينا.

لذلك هذا شيء عظيم. نحن نرى بالضبط ما نتوقعه في محرر Gutenberg الخاص بنا ، ولكن لنفترض أننا أضفنا مكونًا ربما لم يتم دعمه بعد ، أو أننا لم نقم بتكوينه في موقع Faust الخاص بنا. لذلك دعونا نمضي قدمًا وننشئ مكونًا جديدًا هنا. سنستخدم الجدول.

وسنقوم بعمل صفين - الصف 1 ، الصف 2. اذهب وقم بتحديث ذلك. وإذا نظرنا إلى الوراء في الكود الخاص بنا هنا ، يمكننا أن نرى أن لدينا أربع مجموعات محددة - الفقرة الأساسية ، والعمود الأساسي ، والأعمدة الأساسية ، والصورة الأساسية. ليس لدينا جدول أساسي هنا.

إذن ما الذي سيحدث عندما نعرض هذه الصفحة؟ لنلقي نظرة. لذلك سنعود إلى نموذج الصفحة على واجهة Faust الأمامية. ويمكنك أن ترى أننا ما زلنا نحصل على جدول هنا بالصف 1 والصف 2.

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

مع وضع كل هذا في الاعتبار ، دعنا نلقي نظرة على ما يتطلبه الأمر فعليًا لإنشاء كتلة - كيف تبدو في الواقع. لذا سنعود إلى VS Code هنا. ودعنا نختار الصورة الأساسية على سبيل المثال.

يمكنك أن ترى هنا ، هذا مجرد مكون React تقليدي. نحن نسميها الصورة الأساسية. وهو يقبل الدعائم ، تمامًا مثل أي مكون React آخر.

هناك قطعتان في الكتلة هنا. إذن لدينا مكون React الفعلي ، وهو الطبقة التقديمية. ثم نحصل على block.fragments ، وهي البيانات اللازمة لأداء هذه الكتلة.

يمكنك أن ترى هنا أننا نقوم بإنشاء جزء أساسي من الصورة على الصورة الأساسية. ونحن نحصل على هذه السمات - السمات التي نحتاجها لتقديم هذه الكتلة. لذا يمكنك أن ترى أننا نحصل على النص البديل والمصدر والتعليق واسم الفئة والعرض والارتفاع وما إلى ذلك.

ثم ما يمكننا فعله هو تطبيق هذه السمات على منطق React الفعلي. لذا فإن جميع الحقول المطلوبة هنا متوفرة بعد ذلك في الدعائم. لذلك يمكنك رؤية ظهور الخاصيات ، وهي السمات التي طلبناها هنا ، السمات ، البديل ، السمات ، المصدر ، وما إلى ذلك. لذا فهذه طريقة رائعة لتجميع جميع متطلبات البيانات الخاصة بكتلك داخل نفس الملف.

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

إذن فهذه هي في الأساس مجرد أخذ هذه الأنماط من WordPress ، ودمجها في كائن أنماط حقيقي يمكن لـ React استخدامه. حاليًا ، يتم دعم الأنماط للأنماط المضمنة. يمكنك أيضًا الحصول على أوراق أنماط عامة ، لكننا نعمل حاليًا على توفير الدعم لـ theme.json.

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

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

بليك ويلسون: أجل ، أجل. سؤال رائع يا تيريزا. لذا فإن المطلب الوحيد لاستخدام البرنامج المساعد هو تثبيت WPGraphQL أيضًا. من الواضح ، إذا كنت تريد أن يتفاعل موقعك مع Faust JS ، فيمكنك تثبيت حزمة كتل Faust JS ، والتي ستساعد في تسهيل العرض وكل هذه الأشياء الجيدة على الواجهة الأمامية مقطوعة الرأس. ولكن لكشف بيانات الكتلة فعليًا ، كل ما تحتاجه هو WPGraphQL والمكوّن الإضافي WP GraphQL Content Blocks.

تيريزا جوبل: رائع. كيف يتم جمع بيانات الكتلة أيضًا؟

بليك ويلسون: نعم ، يتم جمع كل بيانات الحظر بواسطة أي كتلة في WordPress تستخدم وظيفة كتلة السجل. ستظهر إلى حد كبير أي كتلة تستخدمها تلك الواجهات مع هذه الوظيفة في كتل المحتوى. والشيء الرائع في ذلك هو أنه يقوم بالترحيل مع ملف block.json ويقوم تلقائيًا بوصف كل هذه الحقول وتوثيقها ذاتيًا. إذاً لديك وثائق الكل في واحد.

تيريزا جوبل: رائع. يا له من موفر للوقت. الشيء الآخر الذي أحب أن تتحدث عنه أكثر قليلاً هو ما يحدث مع كتلة غير مدعومة؟ ماذا يحدث عندما يتم الاستعلام عن كتلة غير مدعومة؟

بليك ويلسون: نعم ، هذا سؤال رائع آخر. هناك سيناريوهان حقيقيان يمكن أن يحدثا هنا. لذلك قد يكون هناك مثال حيث لنفترض أن لديك حظرًا في بيانات المنشور الخاصة بك تمت إزالته منذ ذلك الحين من WordPress.

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

تيريزا جوبل: رائع. وهذا يقودني في الواقع إلى سؤالي التالي. فيما يتعلق بالمكونات الإضافية لجهات خارجية في موقع ويب منفصل ، هل يمكنك استخدام مكون إضافي تابع لجهة خارجية باستخدام المكون الإضافي WPGraphQL Content Blocks؟ كيف يعمل كل ذلك معًا؟

بليك ويلسون: أجل ، أجل. لذلك بالنسبة لأي مكون إضافي تابع لجهة خارجية ، بالعودة إلى السؤال الأول أو الثاني ، طالما أنها تتفاعل مع وظيفة نوع الكتلة المسجلة في WordPress ، فسيتم عرض هذه الكتلة تلقائيًا إلى WPGraphQL Content Blocks. طالما يتم تقديم هذه البيانات ، يمكنك بعد ذلك إنشاء الكتلة في الواجهة الأمامية لـ Faust JS. والشيء الرائع في ذلك هو دعنا نقول أن لديك كتلة طرف ثالث للعرض الدائري. بمجرد إنشاء ذلك مرة واحدة في الواجهة الأمامية لـ Faust JS ، يمكنك إعادة استخدامه في مشاريع أخرى من الآن فصاعدًا.

تيريزا جوبل: رائع. هذا هو المكان الذي يأتي فيه جزء إعادة الاستخدام. ومع هذا المكون الإضافي ، يمكنك في الواقع سد بعض هذه الفجوة مع المكونات الإضافية لجهات خارجية التي لا تعمل خارج الصندوق مع مواقع الويب المنفصلة.

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

إذن كيف تتعامل مع الكتل داخل الكتل؟ هذا يمكن أن يكون خادعا حقا. هل يمكنك التحدث إلينا قليلاً عما سيبدو عليه ذلك؟

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

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

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

بليك ويلسون: أجل ، أجل ، بالضبط.

تيريزا جوبل: رائع. لدينا أيضًا في الواقع جزء آخر من البرنامج التعليمي هنا في الدردشة ، مرة أخرى ، لـ WPGraphQL Content Blocks لإلقاء نظرة على هذه الوظيفة المعينة أيضًا. لذلك أردت أن أطرح عليك سؤالًا آخر حول قطعة التصميم - لذا التصميم باستخدام أوراق الأنماط العالمية ، في السطر ، ما هو الأسلوب المتبع هناك؟ كيف يتم التعامل مع التصميم؟

بليك ويلسون: أجل ، أجل. لذا ربما يكون التصميم أحد أكبر الدوافع التي نحاول البحث عنها الآن. في المثال الذي عرضته للتو ، هذا باستخدام أنماط مضمنة.

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

تيريزا جوبل: رائع. شكرا لك على السير معنا من خلال ذلك. أعرف أن الكثير من الناس متحمسون حقًا لذلك. إذن كيف نقيّد الناشر من استخدام الكتل غير المدعومة؟

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

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

تيريزا جوبل: رائع. إذن ، يمكن أن تؤدي رؤية كتلة المكون الإضافي إلى التبديل والإخفاء وإظهار كتل معينة؟

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

تيريزا جوبل: أوه ، هذا يبدو وكأنه توصيل أنظف بالتأكيد. حسنا جيد. السؤال الأخير لك. هل تتوافق كتل الواجهة الأمامية هذه مع محرر الناشر؟

بليك ويلسون: نعم ، وسيلة شرح رائعة. إذن ليس بعد. هذا شيء سنعمل عليه في المستقبل ، لكن في الوقت الحالي ، هذه الكتل مدعومة للواجهة الأمامية مقطوعة الرأس.

إذا كان لديك كتلة مخصصة قمت بإنشائها في WordPress ، إذا كنت تستخدم أمر إنشاء كتلة NPX ، فستظل بحاجة إلى دعم هذا العرض على جانب WordPress. لكن هذا شيء نعمل عليه. لقد حصلنا عليه في خارطة الطريق الخاصة بنا.

تيريزا جوبل: رائع. نعم. شكرا لتحدثك معنا من خلال هذه النقاط ، بليك. لقد كان هذا مفيدًا حقًا ، وكذلك العرض التوضيحي.

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

بعد ذلك ، انتقلنا إلى المرحلة 2 ، والتي كانت تركز على تكامل Faust الأكثر إحكامًا مع Gutenberg Blocks من أجل ضمان وصول جميع الأشخاص إلى المرافق المختلفة والوظائف المساعدة الموجودة هناك. نحن الآن في المرحلة التالية ، المرحلة 3 ، نحن نركز على توفير دعم theme.json ومكتبات الكتل القابلة لإعادة الاستخدام ، كما ذكر بليك خلال مناقشتنا الفنية.

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

يمكنك رؤية رابط في الدردشة أدناه إلى منشورات المدونة الخاصة بنا إذا ألقيت نظرة. انطلق وقم بوضع إشارة مرجعية على هؤلاء. حسنًا ، شكرًا لكم جميعًا على الانضمام إلينا في مناقشتنا بشأن جسر React-Gutenberg. أريد إعادة Blake إلى الشاشة هنا حتى يتمكن من التعبير عن شكره أيضًا وإعطائنا المزيد من المعلومات حول المكان الذي يمكنك الذهاب إليه إذا كان لديك أي أسئلة باقية بعد ذلك.

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

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