هل أنا فقط أم أن Hyperscript قبيح؟

أنا فقط أفرغ عن غضبي هنا، ولكن بعد استخدام لغات قوالب أكثر مما أود أن أتذكر (Jinja2، ERB، FTL، XSLT، JSX، Handlebars، إلخ)، أجد أن Hyperscript مريع تمامًا في التعامل معه.

وبدون ترتيب محدد، تشمل الأمور التي تفشل فيها:

  • قابلية نقل الكود (لا يمكن نسخ/لصق مقاطع HTML دون تمريرها عبر محوّل)
  • تمييز بناء الجملة (يحوّل كل شيء إلى كتلة ضخمة) على سبيل المثال
    مقابل
  • إكمال الكود في حالة فوضوية (FUBAR)، ناهيك عن أدوات توفير الوقت مثل https://emmet.io

لم أكن أتوقع أبدًا أن شيءًا ما سيجعلني أشتاق إلى الأيام السيئة القديمة من PHP، لكن Hyperscript فعل ذلك!

هل أنا الوحيد؟

أوافق تمامًا على أن التعامل معها ليس الأفضل، خاصة بالمقارنة مع Handlebars (الذي نستخدمه أيضًا) حيث يمكنك كتابة HTML كما تتوقع.

بدأنا في استخدام virtual-dom/virtual-hyperscript في الأماكن التي كنا بحاجة فيها إلى تحسين الأداء. وقد كان موضوع أنظمة القوالب المتعددة موضوعًا بدأنا في مناقشته مؤخرًا داخل فريقنا؛ لا نملك خططًا محددة بعد، لكننا ندرك أن تبسيط الأمر سيكون فكرة جيدة. ربما يعني هذا أننا لن نستخدم virtual-hyperscript بعد الآن؟ الوقت سيكشف.

التركيب النحوي غريب بعض الشيء بالنسبة للتعود عليه. أتذكر أنني شعرت بالارتباك الشديد تجاهه عندما بدأت لأول مرة في كتابة مواضيع Discourse، لكنني في النهاية فهمت كيفية عمله. من الممكن أيضًا توليد HTML خام عبر الـ widget.

لست الأكثر مهارة في تحديد متى وأين يجب استخدام كل شيء، لكنها خيار يُعتبر إذا كنت تقوم ببعض الأعمال المخصصة، وتحتاج إلى كتابة widget، وتواجه صعوبة في استخدام virtual-hyperscript.

هذا يستحق المعرفة — شكرًا لك! قضيت ساعة أو ساعتين في إعادة كتابة أجزاء HTML يدويًا، ولكن بين هذا وبين html2hyperscript، لدي خياران للتجربة :slight_smile:

مثير للاهتمام… كنت أظن أن أحد الفوائد الكبيرة لإمبر كان سرعة GlimmerVM. هل أداء virtual-dom يمثل تحسناً كبيراً جداً مقارنة بـ Glimmer؟

أعتقد أننا بدأنا في استخدام virtual-dom قبل أن يصبح Glimmer خيارًا ممكنًا؟ @eviltrout سيكون أكثر دراية مني بهذا الشأن.

هذا أيضًا ذكّرني بأنه من الممكن استخدام Handlebars في الودجات باستخدام Glimmer… اعتبارًا من FEATURE: Use Glimmer compiler for widget templates · discourse/discourse@dffb1fc · GitHub

Discourse هو من عام 2013، بدأنا في الشكوى بشأن أداء أندرويد في عام 2015، وأضفنا virtual-dom في عام 2016، وتم الإعلان عن Glimmer في عام 2017 وهو يُدمج بنشاط في Ember.

أرى ذلك. هذا الجدول الزمني مفيد — شكرًا لك! إذن، أفترض أن أسهل مسار هو الانتظار حتى تصبح أداءات Glimmer مكافئة لـ virtual-dom، ثم التخلي عنها والعودة إلى Ember النقي؟

هذه الميزة رائعة، لكنني أواجه بعض الصعوبات في تشغيلها. لقد قمت باستدعاء discourse/widgets/hbs-compiler باستخدام require، لكنني ما زلت أحصل على error: hbs is not a function

هل لديك أي فكرة عن السبب؟

أنا أستخدم الإصدار 2.4.0beta5، وأستخدم theme-cli، إذا كان ذلك يساعد.

لقد حاولت استخدام القوالب داخل الودجات، لكنني وجدت أن فائدتها محدودة دون دعم واضح للوظائف المساعدة:

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

نعم، للأسف، أعتقد أن محاولة استخدام Handlebars بدلاً من Hyperscript حالياً أكثر عناءً مما تستحق.

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

رائع - شكرًا لك :slight_smile:

سأكون سعيدًا بالمشاركة في هذه المناقشة و/أو إيجاد طرق أخرى للمساهمة :slight_smile:

لا يوجد نقاش حقيقي حول ما نرغب في فعله، فنحن نريد نظام HBS كاملًا. السؤال هو أكثر:

  • هل الأداء جيد بما يكفي الآن؟
  • كيف ننتقل من النظام الحالي إلى هذا؟

آه.. حسنًا.

نعم، قد يكون الانتقال شائكًا بعض الشيء. من حيث المبدأ، يمكننا بناء النسخة العكسية من html2hyperscript، لكن عمليًا، من المرجح أن يكون معظم كود hyperscript متشابكًا بشكل وثيق مع JavaScript الخاص بالعنصر التفاعلي، مما قد يحول الأمر بسرعة إلى كابوس.

أعتقد أن الحل الأبسط هو الحفاظ على دعم hyperscript لفترة من الوقت، وربما إلغاء تدريجي له لاحقًا؟

هل يستحق الانتظار حتى إصدار Octane قبل الاستثمار بشكل أكبر في هذا المجال؟

في الواقع، أقول العكس تمامًا؛ فكوننا قد عقلنا استخدام القوالب قبل إصدار Octane سيسهل علينا الانتقال إلى بناء الجملة باستخدام الأقواس الزاوية عندما نرغب في ذلك.

سأقدم مثالًا أكثر تفصيلاً خلال بضعة أيام، لكن يمكنني تأكيد أنه يعمل.

import hbs from 'discourse/widgets/hbs-compiler';
import { createWidget } from "discourse/widgets/widget";

export default createWidget("foo", {
  template: hbs`
    <p>قالبِي الخاص</p>
  `
});

يُستخدم في منشور مع [wrap] و WidgetGlue:

@edL أرى withPluginApi في تتبع الاستدعاء الخاص بك - هل تحاول استخدام مترجم hbs داخل وسم <script> في السمة؟ للأسف، لا يعمل مترجم هاندلبارز الخاص بالودجات في هذا السيناريو.

يجب عليك تعريف الودجة في وحدة منفصلة باستخدام عبارات import التي أدرجها @j.jaffeux أعلاه. يمكنك القيام بذلك في سمة باستخدام دعم ملفات جافاسكريبت المتعددة.

أوه، أدركت الآن — هذا مفيد حقًا! شكرًا لك، ديفيد :slight_smile: