الإضافات الأساسية التي كان يتم فيها استخدام تفرع (fork) لإضافة مدمجة

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

للتوضيح، Set up Discord notifications with the discourse-chat-integration plugin - #71 by skatefriday أضفت القدرة على توجيه المشاركات التي تم الإبلاغ عنها إلى Discord لأنه من المهم للمشرفين الحصول على إشعار فوري بأن مستخدمًا أبلغ عن مشاركة، و Discord هو وسيلة الاتصال ذات أقل زمن انتقال لهذا الغرض.

إضافة تكامل الدردشة في Discourse الموجودة لم يكن لديها، ولا تزال لا تملك، هذه الميزة.

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

والآن لاحظت أن ميزتي قد اختفت.

إذًا، ما هي أفضل ممارسة عندما يستخدم إعداد مستضاف ذاتيًا إضافة معدلة لاستعادة ميزات الإضافة المعدلة؟

4 إعجابات

أفضل شيء تفعله هو كتابة إضافة تتجاوز الإضافة الأصلية.

شيء آخر يمكنك فعله هو في السطر الذي يسبق استنساخ نسختك المشتقة، تقوم بتنفيذ الأمر “rm - rf” على الإضافة المدمجة.

لذا افعل ذلك بالضبط في إضافتك الجديدة بدلاً من إنشاء نسخة مشتقة من الإضافة الرئيسية. سيكون هناك خطاف (hook) للقيام بذلك.

3 إعجابات

كتابة إضافة جديدة تمامًا؟ هذا يبدو مفرطًا.

هذه هي الإجابة على الأرجح.

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

إلى حد ما يمكنك استبدال/توسيع المنطق في الفئات الموجودة. قد يكون هذا خيارًا لتوسيع المكون الإضافي المجمع. ستقوم بكتابة مكون إضافي جديد يضيف المنطق المعدل فقط. باستخدام إلحاق الوحدة (module prepend).

enabled_site_setting :myoverridingplugin_enabled

module ::MyOverridingPlugin
	PLUGIN_NAME = "my-overriding-plugin"

	class Engine < ::Rails::Engine
		engine_name MyOverridingPlugin::PLUGIN_NAME
		isolate_namespace MyOverridingPlugin
	end

	module SomeClassOverrides
		def overriding_method(foo, bar)
			if foo == "something"
				# قم بشيء مخصص
			else
				# سيؤدي هذا إلى استدعاء المنطق الأصلي
				super(f00, bar)
			end
		end
	end
end

after_initialize do
	SomeClass.prepend(MyOverridingPlugin::SomeClassOverrides)
end

لقد استخدمت هذا المُنشئ لتحديد بعض وحدات التحكم في ظل ظروف معينة.

إعجاب واحد (1)

أنا أتفق معك، وقد وجدت أن هذا أحد أكثر التعقيدات التقنية تأثيرًا لـ “تجميع الإضافات مع النواة” أيضًا. كان لدينا عدد قليل من الإضافات المتفرعة وكان من الصعب جدًا جعلها تعمل دون إزالة الإضافة المجمعة.

لا أعتقد أن جاي يقترح ذلك. يمكن للإضافة أيضًا تجاوز أجزاء محددة جدًا من إضافة أخرى.

أفضل طريقة هي إقناع الفريق بأن الكود الخاص بك يستحق الدمج في الإضافة الرسمية. سينجح هذا إذا كان التعديل الخاص بك عامًا أو مرنًا بما فيه الكفاية. أرى أنك قمت بالفعل بإنشاء تفرع وأن التغييرات/الإضافات الخاصة بك نظيفة جدًا. ربما يمكن أن يكون النص الثابت “Flagged” في ملف ترجمة وإذا جعلت :flagged القيمة الافتراضية هي false فلن تحتاج إلى تعديل معالج الأحداث الأصلي بمعامل إضافي ولكن بخلاف ذلك، يبدو الأمر جديراً بالاهتمام. لو كنت مكانك، سأقوم بتحديثه، وفتح طلب سحب (PR)، ومناقشة هذا الأمر في موضوع الإضافة.

إذا فشل هذا المسار، يمكنك ببساطة إنشاء إضافة تتجاوز الدوال الثلاثة التي قمت بتغييرها، وإضافة معالج on(:reviewable_created).

إعجاب واحد (1)

الهدف من الإضافات هو أنك لست مضطرًا لعمل تفرع لـ Discourse. هذا ليس مفرطًا، هذا هو سبب وجود الإضافات.

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