بسبب اقتراح في موضوع آخر، بدأت للتو في تعلم مكونات Glimmer من وثائق Ember. في الواقع، إنها ممتعة حقًا في الاستخدام وأفضل من البناء في React، في رأيي. أنا مندهش من أن Ember ليست شائعة جدًا. على أي حال، سؤالي هو، مما يمكنني فهمه، يمكنك بناء أي مكون إضافي للمظهر في Discourse باستخدام مكونات Glimmer ويبدو أن لديك وصولاً إلى كل شيء من Ember فورًا. لذا، ألا يمكنك، من الناحية النظرية، تخصيص أي جزء من Discourse عن طريق إنشاء مكونات Glimmer؟ ما هو القيد هنا؟ هل جميع ميزات Ember/Glimmer متاحة على Discourse ثم تحتاج فقط إلى العثور على منفذ للمكون الإضافي للمكون وتهيئته بشكل صحيح؟ على سبيل المثال، احتجت إلى استكمال بعض مواضيعي في مجتمعي ببيانات منتجات ذات صلة من موقع تجارة إلكترونية خارجي. لذا فإن فكرتي هي إنشاء مكون مظهر Glimmer في Discourse لتشغيل استدعاء لجلب بيانات المنتج ثم عرضها في نهاية المنشور. إنه أمر بسيط نسبيًا مع Glimmer، ولكني أتساءل عما إذا كان هذا المسار هو الطريقة الصحيحة للقيام بذلك في Discourse لأنني لست متأكدًا إلى أي مدى يمكنني الاستفادة من مكونات Ember/Glimmer. شكرًا على أي ملاحظات.
أعتقد أنك تفهم الأمور بشكل صحيح.
طالما أن إعدادات البرمجة النصية المتداخلة تسمح بذلك، يجب أن تكون قادرًا على جلب البيانات من الموقع البعيد (ولا تحتاج إلى استخدام مفتاح API سري، والذي سيكون متاحًا للمستخدم).
قد ينجح ذلك،
على الرغم من أنه يجب أن تكون على علم بأن هذا سيجلب بيانات المنتج من الموقع الخارجي عند كل عرض للصفحة وقد لا يكون هذا شيئًا تريده أنت - أو هم. لذا سيكون من الأفضل إنشاء إضافة (plugin)، وجعلها تطلب البيانات من وحدة التحكم (controller) الخاصة بك، وجعل وحدة التحكم تلك تطلب البيانات من الموقع البعيد. سيسمح ذلك بتخزين النتيجة مؤقتًا وسيسمح لك أيضًا باستخدام أي واجهات برمجة تطبيقات (APIs) غير عامة.
إذا كان هناك رابط لمنتج وكانت البيانات قديمة، يمكنك أيضًا إنشاء إضافة (plugin) تقوم بـ “oneboxing” للمنتج وإضافة البيانات الإضافية هناك.
شكرًا. كنت أعتقد أن EmberData متاح، ويبدو أنه يحتوي على ذاكرة تخزين مؤقت مدمجة. لم أختبر EmberData بعد داخل Discourse، ولكن هل هناك سبب لعدم عمله؟
سيكون هذا من جانب العميل (أي خاص بالمستخدم) وسيحل المشكلة إذا كان لديك مستخدم واحد يقوم بالطلب (نفسه) 1000 مرة.
ولكن إذا كان لديك 1000 مستخدم، يقومون بالطلب مرة واحدة لكل منهم، فلن يعمل ذلك، حيث أن لكل منهم ذاكرة تخزين مؤقت منفصلة.
شكراً للتوضيح. نعم، أنا قلق بشأن جانب العميل أكثر، حيث أن واجهة برمجة التطبيقات (API) لديها حدود تعتمد على عنوان IP. لذا طالما أن العميل نفسه يتم تخزينه مؤقتًا، فسأكون بخير حيث لا يوجد لدي العديد من المستخدمين المتزامنين الذين سيؤثرون على قيود واجهة برمجة التطبيقات (API) الخارجية.
ترددي الوحيد مع Ember هو أنه يبدو أن لا أحد يستخدمه حقًا بعد الآن، باستثناء Discourse. أنا أتعلمه فقط لأن Discourse يزداد شعبية باستمرار والمنصة تتحسن. ولكن، هل هناك مستقبل لـ Ember خارج Discourse، وهل سيعتمد Discourse عليه لفترة طويلة في المستقبل؟ أجد أنه من الغريب أن Ember ليس أكثر شعبية. لقد طورت باستخدام React لسنوات وبعد تثبيت Ember في اليوم الآخر، فوجئت بمدى جودته. من المفيد جدًا أن يكون لديك إطار عمل له رأي.
لا يمكن لـ CDCK فقط الرد على ذلك بالكامل، ولكن وجهة نظري:
- يبدو أنه مستثمر بالكامل
- إنه إطار عمل ممتاز وكامل.
- سيكون من المكلف جدًا إعادة كتابته (ومن شبه المؤكد أنه لن يكون له أي جدوى تجارية)
- لقد كان Ember لأكثر من عقد من الزمان، ضع رهاناتك.
قائمة ضخمة من الشركات تستخدم EmberJS:
لا يستخدم Discourse EmberData.
بينما كان أكثر شعبية في الماضي، عندما استخدمته شركات مثل Apple و LinkedIn و Twitch، لا يزال لديه مستخدمون مثلنا، و Intercom، و Hashicorp، و CrowdStrike.
لقد انضممنا إلى Ember Initiative | Mainmatter لأن Discourse مستثمر بالكامل فيه.
بالعودة إلى عنوان هذا الموضوع. أعتقد أنه من الواضح أن Glimmer Components تتوسع بشكل جيد حيث أن CDCK كان مرتاحًا أخيرًا للسماح بإضافة Components إلى Topic List، مما يتطلب من الإطار العملي الأداء على نطاق واسع، انظر: Upcoming topic-list changes - how to prepare themes and plugins
في الأصل، اعتمدت الإضافات على نظام الأدوات (widget system) الذي تم إيقافه الآن والذي تم إنشاؤه للتعامل مع تحديات عرض العديد من Topic List Items حتى على هواتف Android القديمة.