(هذا يساعد في القوائم المنسدلة. يستخدم Discourse select-kit، وأعلم أنه قوي أيضًا، لكنني أجد صعوبة في تخصيصه لأنه معزول بشكل كبير في قاعدة الكود. لذا أود تجربة Power Select).
في تطبيق Rails/Ember عادي، أعتقد أنني سأقوم فقط بإضافة الإضافة باستخدام:
$ ember install ember-power-select
ثم سأضيف أشياء مثل ما يلي:
قالب hbs:
<PowerSelect @options={{this.names}} @onChange={{this.foo}} as |name|>
{{name}}
</PowerSelect>
ملف JavaScript المرتبط به:
import Controller from '@ember/controller';
export default class extends Controller {
names = ['Stefan', 'Miguel', 'Tomster', 'Pluto']
foo() { }
}
لكن مكون Discourse الإضافي ليس تطبيق Rails قياسي. هل هناك شيء خاص يجب علي فعله لجعله يعمل؟
حسنًا، لقد شاهدت هذا wondering إذا كنت ستحصل على أي تلميحات، لكننا هنا بعد 4 أيام.
أنا مبتدئ جدًا في Ember، لكنني متأكد تمامًا من أنك ستكون في وضع أفضل بكثير إذا تمكنت من التعامل مع الأشياء “المُجرَّدة بشكل كبير” والالتزام بتلك القواعد. ليس فقط لأن جلب الإضافات الأخرى صعب الفهم، بل لأنه سيكون أيضًا صعب الصيانة.
لقد رأيت ذلك من قبل، لكنني سعيد بتأكيد أن إضافة ملحقات Ember غير ممكنة حتى يتم إتمام هذه الترقية. إذًا يبدو أن إضافة ملحقات Ember ستكون ممكنة قريبًا—بمجرد اكتمال الترقية. وهذا يبدو رائعًا.
أعتقد أن هذا سؤال مثير للاهتمام. إليك رأيي:
من حيث استخدام الأشياء “المجرّدة” في Discourse مقابل ملحقات Ember: قد أكون مخطئًا، لكنني أعتقد أن استخدام ملحقات Ember لمهام محددة في الإضافات قد يكون أسهل في الصيانة، في الحالات التي تحاول فيها فعل شيء مختلف عما تفعله Discourse بالفعل. هذا هو تفكيري:
المثال هنا هو الرغبة في إضافة قائمة منسدلة جديدة تمامًا في إضافة. هذا التمييز مهم على الأرجح—أنا أتحدث هنا عن محاولة فعل أشياء جديدة في إضافة لا توجد في كود Discourse، والسؤال هو هل نبدأ بطرق Discourse أم بإضافة منفصلة.
في كثير من الأحيان لا يكون لديك خيار حقيقي. على سبيل المثال، إذا أردت إضافة حقل مخصص للمواضيع، فسأقوم دائمًا بالتخصيص فوق الطرق والكود المجهّز مسبقًا في Discourse.
ولكن إذا كانت الوظيفة مستهدفة ومحددة—مثل قائمة منسدلة لغرض جديد—فأنا أكون بالفعل في حالة حيث، إذا استخدمت طرق Discourse، سأكون أقوم بتكييفها لأشياء لم تكن موجهة إليها أصلاً.
الخيار الأول: يمكنني محاولة أخذ كود select-kit الذي أراه، على سبيل المثال، في category-chooser، وإدراجه في مكان جديد (ليس متعلقًا بالفئات)، ثم محاولة تخصيصه ليصبح عن الشيء الذي أريده أن تكون عنه القائمة المنسدلة، بدلًا من الفئات. هذه هي المهمة التي وصفتها سابقًا بأنها معقدة.
وقد يكون من الصعب صيانتها—لأنه إذا قام فريق Discourse بتغيير شيء ما في طريقة عمل كود select-kit في category-chooser، فقد يتغير ذلك قوائم منسدلة المخصصة الجديدة، ولكن بطرق قد تكون مفاجئة (لأنني قمت بتخصيصها لتعمل بشكل مختلف قليلاً عن قائمة الفئات الفعلية).
الخيار الثاني: يمكنني إدراج شيء من Ember قوي ولكنه مصمم أيضًا ليتم تخصيصه، حيث يمكنني رؤية بوضوح نسبيًا كيفية عمل الكود فعليًا. في هذه الحالة، قد أفوت ميزات جديدة رائعة قد يضيفها Discourse إلى قوائمها المنسدلة، لكنني سأتمكن من البقاء على اطلاع بكيفية عمل قوائم منسدلة الخاصة بي بسهولة أكبر. لذا، هذا على الأرجح هو الخيار الأفضل، أعتقد، إذا كان ذلك ممكنًا.
الخيار الثالث: كتابة الكود بالكامل من الصفر. هذا هو المكان الذي أميل إلى الوصول إليه. عندما ينتهي الترميز، من الجيد أن يكون لدي كود أفهمه بالكامل ويمكنني تخصيصه. ولكن بالطبع يستغرق وقتًا أطول، و(النسخ الأولية على الأقل) من غير المرجح أن تكون قوية ومتينة مثل ما بناه فريق Discourse أو فريق Ember.
أخشى أن لا. يمكن إضافة إضافات Ember إلى Discourse الأساسي، ولكن ليس عبر المكونات الإضافية. قد نضيف في النهاية طريقة للمكونات الإضافية/السمات لتحديد تبعيات npm، ولكنها ليست على خارطة الطريق الفورية.
سؤال جانبي لـ David: بينما لا يمكن الوصول إليه عبر المكونات الإضافية، هل يمكننا نظريًا إضافة مكون إضافي إلى النواة ثم استخدامه في مكون إضافي إذا كنا نستضيف ذاتيًا؟ إذا كان الأمر كذلك، فكيف؟ (حاولت الإضافة إلى package.json في app/assets/javascripts/discourse ولكن لم ينجح التحميل، وأتخيل أن السبب هو أنني أفتقد شيئًا بسيطًا.)
نعم، ولكنك حقًا لا تريد نسخ Discourse المتفرع ثم محاولة سحب جميع الالتزامات. كل من فعل ذلك ندم بشدة على فعله.
هممم. ولكن إذا كان مجرد ملف واحد، يمكنك تصور أن يكون ملف app.yml الخاص بك ينسخ الملف من مكان ما إلى /var/www/discourse بعد استنساخ Discourse مباشرة. أعتقد أنني فعلت ذلك من قبل لتغيير الحدود في إعدادات الموقع.
نعم، كما ذكر @pfaffman، قد تتمكن من تعديله للعمل عبر بعض التعديلات على app.yml. ستحتاج إلى التأكد من إجراء التعديل قبل خطوات yarn install و assets:precompile.
ولكن هذا غير مدعوم تمامًا، وقد يؤدي إلى تعطل أشياء غير متوقعة. لا أوصي به.
من باب الفضول، ما هي الوظيفة الإضافية التي كنت تأمل في استخدامها؟
لم أتقدم كثيرًا في الواقع، ومع ذلك، وجدت أن معظم الإضافات الشائعة لديها وظائف موجودة بالفعل داخل Discourse نفسه. جاذبية الإضافات هي أن الوثائق بشكل عام أفضل قليلاً والموارد المتاحة إذا واجهت صعوبة تكون مفصلة جيدًا. على سبيل المثال، هناك ثروة من الوثائق والمشكلات التي تم “حلها” باستخدام ember-concurrency، لذلك إذا كنت مطورًا جديدًا، فإن الوصول إلى هذه الإضافة يعني عادةً أنه يمكنك البدء والتشغيل بسهولة أكبر.
إذن أنت تبحث حرفيًا عن المتاعب. أوصي بعدم التفكير في أي إضافة حتى تجد أن الموارد الحالية لا تلبي احتياجاتك.
لكنك لا تعرف ما إذا كانت ستكون متوافقة مع كيفية حل Discourse لهذه المشكلة اليوم أو في المستقبل. إذا كنت تريد التطوير لـ Discourse، فإن النظر إلى أمثلة لكيفية عمل الأشياء في Discourse سيكون هو الطريق الصحيح.
لا تكن الرجل الذي يبحث عن مفاتيحه تحت المصباح بدلاً من تحت السيارة حيث أسقطها لأنه يمكنك الرؤية بشكل أفضل تحت المصباح.