ترتيب أولوية مكونات السمة

[guildai (Garrett)]

ألاحظ أن مكونات المظهر تبدو وكأنها تُنفّذ حسب ترتيب التثبيت. على سبيل المثال، إذا قمت بتثبيت المكون أ ثم المكون ب، فإن نصوص المكون أ تُدرَج في الصفحات المُنشأة قبل نصوص المكون ب.

هل يمكنني الاعتماد على هذا الأمر؟ هل توجد وجهة نظر ما تُظهر هذا الترتيب؟ عند عرض المكونات المثبتة، تُدرَج المكونات أبجديًا.

أفضّل وجود طريقة لتنفيذ الإجراءات بشكل صريح قبل مكون معين. في حالتي، أريد تنفيذ إجراءات قبل مكون جدول المحتويات (TOC) (متعلق بهذا الموضوع). ومن وثائق إمبر، يبدو أن الدوال المجدولة لـ طابور معين تُنفّذ حسب ترتيب جدولتها. وهذا يجعل ترتيب الجدولة أمرًا جوهريًا في حالتي.

[sam (Sam Saffron)]

@guildai

Is this something I can rely on?

This is not something you can rely on, instead proper APIs should control this. You can use ember initializers to control this to a degree. @eviltrout may have some specific ideas if you can paste the example code you are trying to schedule.

[guildai (Garrett)]

هذا هو الكود الذي أقوم بتشغيله:

<script type="text/discourse-plugin" version="0.8">
    const { run } = Ember;
    
    api.decorateCooked($elem => {
        run.scheduleOnce("actions", () => {
          // يجب أن يتم التنفيذ قبل الإجراءات المجدولة من مكون TOC.
        });
    })

يستخدم مكون TOC نفس الواجهة لـ جدولة إجراءاته.

وفقًا لوثائق Ember، فإن واجهة الجدولة:

تضيف الهدف/الطريقة الممررة وأي حجج اختيارية إلى الطابور المسمى ليتم تنفيذها في نهاية حلقة التشغيل (RunLoop)

يشير مصطلح “إضافة” هذا إلى ترتيب FIFO للإجراءات المجدولة. وبالتالي، فإن ترتيب استدعاء schedule حاسم هنا.

[guildai (Garrett)]

لاحظت أنه في محاولتي لإعادة ترتيب تنفيذ JavaScript عن طريق إعادة تثبيت وإلغاء تثبيت مكون TOC (وهو ما يبدو أن له أثرًا جانبيًا محظوظًا يتمثل في تشغيل JavaScript الخاص بـ TOC في النهاية)، فإن قواعد CSS تُطبّق الآن بهذا الترتيب

أشعر بأن موضوع ترتيب وضع كود مكونات السمات مهم جدًا. فإذا كان الترتيب غير مُعرَّف رسميًا، فلا توجد طريقة لمكونات أن تتفاعل مع بعضها.

ربما يكون تفاعل المكونات هدفًا غير مطلوب. لكنني أعتقد أنه بوجود قاعدة ترتيب (مثل الإعلان عن أن ملف مكون يجب أن يظهر قبل أو بعد ملف مكون آخر بنفس الاسم - وهذا يُعرَّف على الأرجح في about.json) فإن هذه المشكلة ليست صعبة للغاية.

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

[Johani (Joe)]

في كل مرة تنشئ أو تُثبّت سمة أو مكونًا، يقوم Discourse بتعيين معرف (ID) له. إذا قمت بزيارة صفحة ذلك المكون، فستجد المعرف في عنوان URL (الرقم في النهاية)

عند إضافة هذا المكون إلى سمتك، يبدو أن ترتيب تنفيذه يعتمد على معرفه - على مستوى بسيط جدًا (عند تسجيل السجل في وحدة التحكم دون أي تأخير). إذن، سيعمل 233 قبل 234 وهكذا.

يعمل هذا الأمر في معظم الحالات لأن التغييرات اللاحقة تُضاف عادةً في مكونات جديدة، لذا يعمل كل شيء بسلاسة.

على المدى الطويل، يمكننا جعل الترتيب يحترم قائمة المكونات التي أضفتها إلى السمة

لكن هذا غير مدرج في أي خطة طريق حاليًا.

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

/javascripts/discourse/initializers/initialize-for-foo.js

ويبدو كما يلي

import { withPluginApi } from "discourse/lib/plugin-api";

export default {
  name: "foo",
  initialize() {
    withPluginApi("0.8.7", api => {
      console.log("foo")
    });
  }
}

ولدي مبدئ آخر يبدو كما يلي

/javascripts/discourse/initializers/initialize-for-bar.js

import { withPluginApi } from "discourse/lib/plugin-api";

export default {
  name: "bar",
  initialize() {
    withPluginApi("0.8.7", api => {
      console.log("bar")
    });
  }
}

إذا أردت التأكد من أن bar يعمل بعد foo، يمكنني إضافة وسيطة after: إليه، مما يضمن عمله بعد اسم المبدئي الذي أمرره هناك. إذن، لجعل bar يعمل بعد foo، سأفعل ذلك في

/javascripts/discourse/initializers/initialize-for-bar.js

import { withPluginApi } from "discourse/lib/plugin-api";

export default {
  name: "bar",
+ after: "foo",
  initialize() {
    withPluginApi("0.8.7", api => {
      console.log("bar");
    });
  }
};

[guildai (Garrett)]

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

أعتقد أنه بالنظر إلى ما أقوم به في التوثيق، وبعضه خارج الإطار المعتاد، فإن هذا النهج هو الخيار الصحيح.