مزايا وعيوب استخدام الثيم بدلاً من الإضافة للتخصيص

لاحظت أنه من الموصى به استخدام السمات (Themes) بدلاً من الإضافات (Plugins) لتخصيص التصميم. ما هي الفوائد؟

من منظور التطوير، أرى أن السمات معقدة للغاية. أحتاج إلى أداة إضافية لرؤية التغييرات في الكود في الوقت الفعلي - وحدة تحكم واجهة سطر الأوامر للسمات (Theme CLI console).

كما أفهم أن السمات يمكن اختيارها من قبل المستخدم (لست بحاجة إلى هذه الميزة).

ما هي فوائد السمات مقارنة بالإضافات في بيئة الإنتاج؟

رأيي:

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

لكنني أوافق على أن الإضافات عادةً ما تكون أسهل في التنقل من منظور المطورين، في رأيي.

مع إضافة تقسيم ملفات جافا سكريبت الخاصة بالموضوع إلى ملفات متعددة، يمكنك فعليًا القيام بـ كل شيء يمكن للإضافة القيام به عبر Ember باستخدام موضوع.

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

أكبر تحدٍ نواجهه فيما يتعلق بالإضافات المخصصة من منظور الدعم هو انقطاع المواقع. يحدث هذا عادةً لأن الإضافة تقوم بتعديل فئة أو طريقة في Rails ضمن النواة الأساسية تم تغييرها، ولم يتم تحديث الإضافة بعد لمراعاة هذا التغيير. إذا حدث تغيير على جانب Ember وبالتالي تعطل الموضوع أو مكون الموضوع، فقد لا يتم عرض الموقع بشكل صحيح، ولكن يمكن تعطيله بسرعة باستخدام /safe-mode.

أستطيع أن أفهم وجهة نظرك هنا. سأضيف أيضًا أن gem يتيح لك التطوير على موضوعك محليًا ومزامنته مع أي موقع Discourse تملك مفتاح API له، بما في ذلك theme-creator.discourse.org. لا تحتاج حتى إلى إعداد بيئة تطوير محلية إذا كان لديك gem واحد يعمل.

واو، الردود هنا ذهبية، ولدي القليل جدًا لإضافته هنا.

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

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