السمات القائمة على المكونات باستخدام مكون الدليل الفردي الخاص بدروبال

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

هذا النهج القائم على المكونات لتخصيص تطبيق دروبال ليس جديدًا ولكنه وصل أخيرًا إلى الصميم. إنه يعطي حدودًا جديدة تمامًا لمطوري الواجهة الأمامية لتنظيم الكود الخاص بهم بطريقة أكثر قابلية للصيانة مع الحد الأدنى من منحنى التعلم. داخل SDC ، يتم تجميع جميع الملفات اللازمة لتقديم المكون (Twig و CSS و JS وما إلى ذلك) معًا في دليل واحد. لدى SDC القدرة على إحداث ثورة في تطوير الواجهة الأمامية في دروبال من خلال تمكين المطورين من الاستفادة من أحدث تقنيات الواجهة الأمامية ، وترسيخ مكانة دروبال باعتبارها CMS قوية وتطلعية.

نهج السمات الحالي لدروبال

كانت أبسط طريقة للعمل على سمة دروبال هي إضافة الترميز إلى ملفات html.twig داخل مجلدات القوالب. من أجل التصميم والسلوك ، نقوم بإنشاء ملفات CSS و JS وفقًا لاحتياجات الكيان ووضعها داخل مجلدي CSS و JS على التوالي. يتضمن ذلك قائمة رأس السمات ، وقائمة التذييل ، والكتل ، والمناطق ، وأنواع المحتوى الفردية وأوضاع العرض المختلفة ، وجهات النظر المختلفة ، وما إلى ذلك ، ثم يتم الإعلان عن هذه الملفات في ملف libraries.yml حيث يمكن أيضًا ذكر التبعيات (إن وجدت). بهذه الطريقة يمكن تحميلها عند الطلب أو إتاحتها عالميًا. بصرف النظر عن هذا ، يذهب أي منطق معالجة مسبقة إلى ملفات .theme ، لدينا نقاط توقف .yml للمساعدة في التصميمات سريعة الاستجابة وبالطبع ملف .info.yml الذي بدونه يكون كل الجهد مضيعة.

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

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

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

نهجنا في الثيمات في سبيبي

في Specbee ، قمنا بتوحيد كيفية إنشاء السمات الخاصة بنا باستخدام أداة NPM تسمى Drupal Theme Init تم تطويرها بواسطتنا من البداية وهي مفتوحة المصدر. نظرًا لكونه منشئ Yeoman ، يمكن تثبيته بسهولة باستخدام NPM / Yarn والذي يساعد بشكل تفاعلي في إنشاء سمة مخصصة. تتمثل فكرة نموذج دروبال الأولي في الحصول على نهج متسق لكيفية سقالة ملفات السمات وفقًا لممارسات دروبال ومساعدة المطورين على بدء العمل على السمة دون عناء تعيين الملفات في كل مرة يبدؤون فيها مشروعًا جديدًا. الفكرة الأساسية للهيكل هي تقسيم SASS إلى مكونات باستخدام اتفاقية BEM. كل ملفات CSS مرتبطة بكيان مثل الحظر ، والعرض ، ونوع المحتوى ، وما إلى ذلك ، لها CSS خاصة بها تم إنشاؤها وإرفاقها بهذا الكيان إما من خلال قالب الغصين أو المعالجة المسبقة. الشيء نفسه ينطبق على ملفات JS. يساعدنا الاستخدام المكثف لـ libraries.yml على الحد من كمية CSS و JS التي نعرضها على الصفحة.

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

ما هو السمات القائمة على المكونات

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

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

كيفية عمل السمات القائمة على المكون في دروبال

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

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

كيفية عمل السمات القائمة على المكونات باستخدام SDC

مع دخول النسخة الأولية من SDC إلى النواة كوحدة تجريبية ، كان هناك الكثير من الإثارة حولها. تم وصف SDC على أنه أكبر تغيير في سمات دروبال منذ تقديم Twig. SDC مرة أخرى ليس حلاً كاملاً لفريق تطوير الواجهة الأمامية ولكنه نهج يحركه المكون في تكوينهم بهيكل أساسي خارج الصندوق. لا يزال من الممكن تمديد هذا بعدد من الوحدات النمطية لنوع معين من سير العمل. الفكرة الأساسية هي أن كل ما يتعلق بالمكون يبقى داخل دليل واحد. يتضمن ذلك ملف Component Twig و JS و CSS وأصول أخرى وملف مخطط YAML واحد يوضح خصائص المكون.

بعض الفوائد الفورية لاستخدام SDC:

1. كل التعليمات البرمجية المتعلقة بالمكون موجودة في دليل واحد (كما يوحي الاسم!).
2. يتم إنشاء مكتبات المكون تلقائيًا مما يؤدي إلى صدمة أقل لعدم الإعلان عنها في ملف libraries.yml. على الرغم من أننا قد لا نزال بحاجة إلى إضافة التبعيات إلى ملف component.yml ، إلا أن ذلك يتم في مكان واحد بدلاً من القفز إلى ملف libraries.yml.
3. هناك منحنى تعليمي أصغر بكثير لتنفيذ SDC. إذا كنت تعرف أساسيات تصميم دروبال ، فكل ما عليك فعله هو تمكين هذه الوحدة والبدء في كتابة المكونات.
4. لا تزال قوة الغصين (التضمين / التمديد / التضمين) متاحة مما يساعد في إعادة استخدام الكود.
5. نظرًا لأن المكونات هي ملحقات YML ، والتي يمكن اكتشافها بسهولة بواسطة Drupal ويمكن تبديلها بسهولة بواسطة مكون له نفس بنية API.
6. يمكن أيضًا تقديم المكونات من خلال مصفوفات التصيير!
7. يوفر آلية جيدة لدمج المكتبات الخارجية لتسهيل نظام التصميم.
8. نظرًا لتنظيم المكونات ، تكون النتيجة مظهرًا ومظهرًا متسقًا للمنتج النهائي.
9. يصبح الرمز أكثر قابلية للاختبار لأن لدينا وحدات (قراءة المكونات) التي يمكن اختبارها بشكل مستقل
10. نظرًا لأننا نحدد المخطط ضمن تعريف YAML للمكون ، يمكن للوحدات النمطية إنشاء نماذج تلقائيًا لتعبئة البيانات.

على الرغم من تضمينه حاليًا كميزة تجريبية في جوهره ، إلا أن إعداد SDC سهل للغاية. بافتراض وجود تثبيت Drupal 10.1.x:

1. تمكين الوحدة الأساسية التجريبية SDC.

2. إنشاء أو استخدام سمة مخصصة لإضافة SDC. لغرضنا ، أنشأنا سمة مخصصة تسمى Ice Cream مع Olivero كموضوع أساسي.

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

4. يتكون ملف قالب غصين من رمز أساسي:

5. قم بإنشاء مجلد يسمى المكونات داخل السمة المخصصة الخاصة بك. هذا مشابه لكيفية وجود مجلد قوالب لقوالب دروبال.

6. في الوقت الحالي ، الفكرة الأساسية هي تصميم العنوان والوصف ، بحيث يمكن إعادة استخدامهما في الطبيعة. لنقم بإنشاء مكون يسمى simple-article. سيكون هناك ملف simple-article.component.yml و simple-article.twig الذي سنطلبه. بصرف النظر عن ذلك ، سنضيف أيضًا simple-article.css للتصميم.

7. لنقم بإنشاء ملف simple-article.twig . سيكون لدينا ترميز أساسي لذلك.

8. أضف ملف simple-article.component.yml بالمخطط المذكور في https://www.drupal.org/node/3352951. الفكرة هي تحديد المدخلات لملف الغصين. سيبدو مثل هذا بالنسبة لنا:

9. دعنا نضيف بعض الأنماط الأساسية للمكون في simple-article.css .

10. امسح ذاكرة التخزين المؤقت.

11. أبراكادابرا! المكون جاهز الآن للاستخدام. لكنها لا تزال بحاجة إلى استخدامها . بدون ذلك ، يظل المكون خاملاً في مجلد المكونات.

12. قم بتضمين هذا المكون في ملف القالب المطلوب (هذا هو ملف html.twig ضمن مجلد القوالب في السمة المخصصة) بالتنسيق [theme_name: component-name]. لاحظ عبارة include حيث نضيف متغيرات الغصين لاستخدامها في المكون.

13. يتم الآن تقديم المكون مع ترميزنا الجديد والتصميم الأفضل.

14. لاحظ الترميز. إذا تم تمكين twig debug ، فسنحصل على بعض الرموز الخاصة أيضًا مع تقديم مكون SDC الخاص بنا.

وهذا كل شيء!

مراجع

• https://www.drupal.org/docs/develop/theming-drupal/using-single-directory-components/about-single-directory-components
• https://www.drupal.org/project/sdc
• https://herchel.com/articles/creating-your-first-single-directory-component-within-drupal

افكار اخيرة

مع الطريقة التي تم بها بناء SDC ، سيكون هناك تطوير عالي الكثافة حوله. أحد المسارات الشائعة هو أن الوحدات النمطية ستكتشف تلقائيًا المكونات وتدرج أشكالها الخاصة في Layout Builder و CKEditor و Paragraphs و Blocks و Fields وما إلى ذلك! بالإضافة إلى ذلك ، يلعب SDC الآن بشكل جيد مع Storybook من خلال وحدة مساهمة تسمى CL Server (والتي تمت صيانتها بواسطة مشرفو مشروع SDC). توجد بالفعل وحدات أخرى مثل CL Devel و CL Generator وحتى أنماط واجهة المستخدم التي يتم بناؤها حول SDC.

سيساعدنا هذا أيضًا على ترقية منشئ السمات الخاص بنا (Drupal Theme Init) والذي ناقشناه سابقًا لإعطاء خيار استخدام SDC جنبًا إلى جنب مع نظام التصميم المعمول به ، ويفضل أن يكون Storybook. سيساعد هذا أي شخص على بدء تنفيذ SDC على الفور مما يمهد الطريق لتطوير أفضل للموضوع.

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