تقريبًا كل مكتبة واجهة مستخدم JavaScript &/| إطار العمل الذي رأيته يحتوي على نوع من خطافات دورة الحياة: onmount، willmount، beforemount، aftermount، onunmount، onwhatever.

هل تحتاجهم حقًا؟ هل هم جيدون أم سيئون؟ هل يمكن العيش بدونه؟

إذن، لماذا توجد هذه الأشياء في المقام الأول؟

  const oninit = (e: Element) => {
    e.style.prop = value;
    e.addEventListener('mouseover', handler);
    e.setAttribute('data-key', value);
  }

هذا هو النموذج النموذجي (الممل) للتهيئة الذي تأتي معه العديد من مكونات الويب وتستفيد منها. تهدف الطبيعة التصريحية لـ HTML وCSS إلى جعل هذه العناصر زائدة عن الحاجة، باستثناء أنه في بعض الأحيان يكون من الصعب إن لم يكن من المستحيل ضبط بعض الوظائف مسبقًا بالقيم المقصودة (فكر في Disabled="${()=>false}" الذي لا تتصرف كما يتوقع المرء).

إذن ماذا نفعل؟ قم بتعيين كل ما تبقى لنا بشكل حتمي في معالج init. إنه ينجح ويمكن للعالم أن يتحرك للأمام.

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

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

يأتي الحل مع عكس التحكم والبرمجة الوظيفية، وهو ما لا يصادف أنه تم تصور HTML وJavaScript، ولكن هناك أخبار جيدة: لا يزال بإمكاننا تنفيذ بعض أنماط التصميم الأساسية لـ FP وتوفيرها حل استراتيجي للمشكلة.

rimmel.js هو تطبيق مرجعي لمجموعة شاملة مفاهيمية من HTML تسمى Reactive Markup، والتي تعمل قليلاً مثل TypeScript لـ JavaScript، ولكنها تهدف إلى جعل HTML وDOM وظيفية/وظيفية متفاعلة.

يتم تحقيق ذلك من خلال التعامل مع كل شيء على أنه تيار: الأسلوب؟ إنه تيار. أحداث دوم؟ بالطبع هم تيارات. سمات HTML؟ تيارات أيضا. كلما قاموا بإصدار قيمة، تم ضبط ذلك.

دعونا نرى كيف يعمل.

  const style = CreateStream({color: 'red'});
  const key = CreateStream('red', value);
  const handler = CreateStream();

  const template = rml`
    

    
  `;

CreateStream هي مجرد أداة مساعدة افتراضية لإنشاء الدفق. عادةً ما ترغب في استخدام Promises، وObservables RxJS بشكل عام بدلاً من ذلك، لأنها تمثل أفضل نموذج لتفاعلات واجهة المستخدم.

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

سيكون أي إطار عمل أو مكتبة واجهة مستخدم معينة مسؤولاً عن إلغاء تحميل كل دفق تم تحديده أو ربطه في القوالب: النمط، ومفتاح البيانات، وتشغيل الماوس. ليس هناك خطر من نسيان التنظيف وتقل فرص حدوث تسرب للذاكرة بشكل كبير.

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

هل أنت مستعد لتجربة غريبة بعض الشيء؟ تحقق من rimmel.js