تطوير الإضافات بشكل أسرع عن طريق فصل الواجهة الأمامية إلى مكون سمة

لقد سألت سابقًا عن كيفية إعداد البيئة المحلية للترميز بشكل أسرع عند بناء إضافة، وأعلم أن آخرين قد فعلوا ذلك أيضًا.

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

أولاً، مشكلتي السابقة:

لتطوير إضافة، كان عليّ الترميز من نسخة محلية من Discourse، وكان هذا بطيئًا جدًا لأن: 1) أي تغيير في الملفات يتطلب إعادة تحميل الصفحة، وكان جهازي يقوم بذلك ببطء شديد عند تشغيل Discourse (حوالي 30 ثانية لكل إعادة تحميل للصفحة)، 2) كان موقع Discourse المحلي للتطوير الذي أختبر عليه بطيئًا جدًا (بطيء في التنقل، إلخ)، و 3) أي تغيير في كود الإضافة الخلفي يتطلب إيقاف الخادم وإعادة تشغيله - وهذا يمكن أن يستغرق بضع دقائق. طوال الوقت، كانت مروحة جهازي تعمل بأقصى طاقتها.

ونتيجة لذلك، ربما كنت أقضي ساعة في الترميز لما كان يمكنني ترميزه عادةً في حوالي 10 دقائق بسير عمل سلس.


حلي

على عكس تطوير إضافة، فإن سير العمل لترميز مكون سمة رائع، وذلك بفضل أداة Discourse Theme CLI. (خطواتي لاستخدامها هنا.) إنه سريع وسلس.

لماذا ترميز سمة أو مكون سمة أسرع وأسهل بكثير

باستخدام أداة Theme CLI، يمكنك ترميز سمة محليًا، ولكن “مراقبتها” (أي تشغيل السمة) على موقع مباشر (إما موقعك الفعلي، أو موقعك الفعلي ولكن في وضع المعاينة فقط، أو موقع مباشر اختباري قمت بإعداده).

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

لذلك، ما أدركته: في معظم الأوقات عندما أقوم بترميز إضافة، يكون ذلك في الواقع على واجهة المستخدم الأمامية (ملفات hbs، ملفات javascript، إلخ). وقليل فقط منه يُقضى على الأمور الخلفية (إعداد المسارات، إنشاء حقول مخصصة، إلخ).

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

عندما أحتاج إلى تحديث الأمور الخلفية في الإضافة، عندها يجب عليّ الترميز في الإضافة مرة أخرى - ولكن هذا يمثل حوالي 20٪ فقط من الوقت (في تطوير إضافتي على أي حال). مما يسمح لي الآن بقضاء 80٪ من وقتي مع سير عمل مكون السمة الأفضل بكثير.

عندما يحين وقت نقل كل شيء إلى الإنتاج، يمكنني:

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

هذا كل شيء.

ليس ثوريًا. ولكنه جعل الأمور أفضل بكثير في شيء كان يعيقني لفترة من الوقت.

7 إعجابات

نعم، هذا نهج جيد.

لقد استخدمت هذا النهج في معاينات قوائم المواضيع لفترة طويلة الآن، ونقلت أكبر قدر ممكن من الوظائف إلى TC وجعلتها مستقلة. الميزات الإضافية التي تتطلب تعديلات API تذهب بعد ذلك إلى مكون إضافي ويتم تشجيع المستخدمين على تثبيته أيضًا للاستفادة منها (إذا استطاعوا).

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

إذا كان ذلك لموقعك الخاص فقط، فبالتأكيد، هذا رائع!

3 إعجابات

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

إعجابَين (2)