الانتقال من Redux إلى MobX

لماذا نحن هنا؟

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

ما هي الإعادة؟

كما هو مذكور في redux.js.orgفهي "حالة حاوية يمكن التنبؤ بها لـ تطبيقات JS." تم إنشاؤه بواسطة دان أبراموف وأندرو كلارك في عام 2015.
يمكن وصفها بـ 3 مبادئ:

1. نقطة حقيقة واحدة - يتم الاحتفاظ بالحالة في مخزن واحد,
2. الحالة للقراءة فقط - لا يمكنك تغيير الحالة مباشرةً، يجب أن تصدر إجراءً للقيام بذلك,
3. يتم إجراء التغييرات باستخدام الدوال البحتة - الدوال البحتة بحكم تعريفها تُرجع دائمًا نفس النتائج لمعلمات معينة، ويمكن تنفيذها دائمًا، وليس لها أي آثار جانبية.

ما هي MobX؟

لا مفاجأة هنا, موب إكس هي أيضًا مكتبة لإدارة الحالة، فهي تطبق البرمجة التفاعلية الوظيفية (TFRP) بشفافية لجعلها بسيطة وقابلة للتطوير. على غرار المكتبة السابقة، فلسفتها موصوفة في 3 نقاط:
1. بسيط ومباشر - كود بسيط وخالٍ من الغلايات ولا يتطلب أدوات خاصة لتشغيله,
2. عرض مثالي دون عناء - يتأكد من تحسين جميع العمليات الحسابية بشكل جيد ولا حاجة للقيام بذلك يدويًا,
3. الحرية المعمارية - التنفيذ غير مقيّد ويمكن استخدامه بدون أي إطار عمل لواجهة المستخدم.

مقارنة بين MobX وRedux

التعلّم

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

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

بنية البيانات - ماذا يوجد داخل الدولة؟

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

في موب إكس، نجعل الخصائص، والكائنات بأكملها، والمصفوفات، والخرائط، والمجموعات قابل للملاحظة. نعم، الأوليات غير مذكورة هنا لأن قيمها في الشبيبة غير قابلة للتغيير وبسبب ذلك يجب التعامل معها بشكل مختلف. كل ما تحتاج إلى معرفته إذا ذهبت مع قابل للملاحظة هو أنه سيغلف البدائية في "مربع" وسيكون مُحصِّل القيمة الفعلية ومُحدِّدها متاحًا عبر .get() و .set(newValue) على التوالي انظر observable.box(القيمة)

استيراد { قابل للملاحظة، تشغيل تلقائي } من "موبكس"

const cityName = observable.box("فيينا") // نفس observable("فيينا")

التشغيل التلقائي(()) => {
    Console.log(cityName.get()))
})
// يطبع: "فيينا

cityName.set("أمستردام")
// يطبع: 'أمستردام'

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

موقع البيانات - المخزن (المخازن)

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

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

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

ثابت وقابل للتغيير والتبديل

الإعادة يتطلب تحديث الحالة لا يتحور الحالة الأصلية. لذا، إن أردنا إضافة عنصر جديد إلى مصفوفة موجودة، نحتاج إلى إرجاع مثيل جديد بدلًا من إضافة ذلك العنصر إلى المصفوفة الحالية.

الدالة todoReducer(الحالة = []، الإجراء) {
    // هنا نُنشئ مصفوفة جديدة ونستخدم مشغل انتشار للاحتفاظ بالقيم القديمة
    إرجاع [
      ...الحالة,
     الإجراء.payload
    ]
}

ثم، في موب إكس، يمكننا تغيير الخصائص القابلة للرصد، هنا: يمكن أن نقوم بتحويل تودوس المصفوفة. لاحظ أننا نغير المصفوفة الأصلية في إضافة تودو

فئة ObservableTodoStore {
  تودوس = [];

  مُنشئ() {
    جعل قابل للملاحظة(هذا، {
      تودوس: قابل للملاحظة,
      إضافة تودو: إجراء,
    });
    التشغيل التلقائي(()) => console.log(this.todos.length)))
  }


  إضافة تودو(مهمة) {
    // هنا نقوم فقط بدفع العنصر الجديد إلى المصفوفة الموجودة!
    هذا.todos.push({
      المهمة: مهمة,
      مكتملة: خطأ,
    });
  }

}

const observableTodoStore = جديد ObservableTodoStore();
observableTodoStore.addTodoStore("بعض الأشياء الصعبة التي يجب القيام بها");

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

observableTodoStore.todos.push("بعض المهام الصعبة الأخرى");

// ما هو أكثر إثارة للاهتمام، فقط عندما تقوم بتحديث خاصية مهمة معينة
// سيحذرك MobX (أثناء وجودك في الوضع الصارم) أنه لا يجب عليك القيام بذلك مباشرةً
observableTodoStore.todos[1].task = ("ربما شيء أكثر صعوبة");

تصحيح الأخطاء

أنا شخصياً يعجبني كروم امتداد Redux DevTools DevTools. يسمح لك بإلقاء نظرة سريعة على حالة تطبيقك ولديه إمكانيات رائعة للرجوع إلى الوراء والعودة لكل تغيير يطرأ على الحالة (السفر عبر الزمن!). كل ذلك ممكن بسبب مبدأ عدم تغيير الحالة السابقة.

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

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

الشعبية

عندما تنظر إلى الشعبية، فإن Redux تسود هنا. بالقرب من 4 ملايين عملية تنزيل من npm في الأسبوع مقارنة بـ 450 ألف دولار لـ MobX. كما أن عدد المساهمين (~ 870 > 270 مساهمًا) والنجوم (57 ألفًا > 24 ألفًا) على مستودع GitHub لكل مكتبة يُظهر أن Redux علامة تجارية معروفة.

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

تم وصف الرضا في هذا الرسم البياني بـ "سيستخدم مرة أخرى / (سيستخدم مرة أخرى + لن يستخدم مرة أخرى)"

الخاتمة

لا يوجد فائزون في هذه المسابقة... حتى الآن! بالمناسبة، لم تكن هناك مسابقة على الإطلاق 😉 أعتقد أن كلتا المكتبتين تقومان بعمل رائع في إنجاز مهمتهما الأساسية، وهي الاهتمام بوجود حالة إدارة قوية في تطبيق JS . سأحتاج إلى مزيد من الوقت لمعرفة كيفية العمل اليومي مع موب إكس يختلف عن الإعادة وفي أي الحالات يمكنني أن أوصي به.

في الوقت الحالي، يمكنني القول بأنني أفتقد بالفعل "السفر عبر الزمن" من أدوات التطوير في Redux، ولكن من ناحية أخرى، فإن تعيين حالة مع موب إكس يبدو واضحًا جدًا وتبدو الشيفرة المكتوبة أكثر سهولة في القراءة.

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

آمل أن أعود إليكم ببعض التفسيرات المثيرة حقًا حول كيفية حل مشاكل معينة مع موب إكس. أراك لاحقاً!