قواعد لاختيار إطار عمل JS

TL ؛ د

• لا يناقش هذا المقال أطر عمل JS من قائمة TOP-3.
• عند تطوير إطار JS بخلاف TOP-3 ، يتعين عليك حل أمر من المسائل الفنية أكثر من المتوقع في بداية التطوير
  
• تستند القصة إلى أحداث حقيقية.

بدأت القصة بمشروع صغير واحد ، تم تطويره في الأصل استنادًا إلى مكتبات backbone.js و marionette.js. هذه ، بالطبع ، هي المكتبات الكبرى التي بدأت تاريخ تطوير تطبيقات صفحة واحدة. ولكن بالفعل في ذلك الوقت كانوا أكثر عرضة لقيمة تاريخية من الناحية العملية. سأذكر فقط حقيقة أنه لعرض جدول بسيط ، كان من الضروري إنشاء: 1) وحدة نمطية مع وصف للنموذج ، 2) وحدة نمطية مع وصف المجموعة ، 3) وحدة نمطية مع تعريف نموذج العرض ، 4) وحدة نمطية مع تعريف مجموعة عرض ، 4) قالب صف جدول ، 5) قالب الجدول ؛ 6) وحدة تحكم. امتلاك حوالي 10 كيانات في تطبيق صغير - في المرحلة الأولية للغاية كان لديك بالفعل أكثر من خمسين وحدة صغيرة. وهذه هي البداية فقط. ولكن الآن ليس عن ذلك.

في مرحلة ما ، بعد ستة أشهر من التطبيق ، ما زال لم يظهر في نتائج البحث. ساعد إضافة prerender.io إلى المشروع (الذي استخدم محرك phantom.js بعد ذلك) ، ولكن ليس بنفس الدرجة المتوقعة. بدأت السحب تتجمع فوق التطبيق وفوقي ، وبعد ذلك أدركت أنني بحاجة إلى القيام بشيء بسرعة وكفاءة ، ويفضل اليوم. كان الهدف الذي حددته هو: التبديل إلى تقديم الخادم. مع backbone.js و marionettejs ، هذا مستحيل تقريبًا. على أي حال ، تم إيقاف مشروع rendr على backbone.js ، والذي تم تطويره تحت إشراف Spike Brehm (مؤلف فكرة التطبيقات المتجانسة / العالمية) ، حيث جمع 58 مساهمًا و 4،184 إعجابًا على github.com ، ولم يكن من الواضح أن الهدف من ذلك هو بدء حملة مدتها يوم واحد . بدأت أبحث عن بديل. لقد استبعدت إطار TOP-3 JS من الدراسة على الفور ، لأنني لم يكن لدي احتياطي من الوقت لتطويرها. بعد بحث قصير ، وجدت إطار عمل JS المتنامي بسرعة riot.js github.com/riot/riot ، والذي لديه حاليًا 13،704 إعجاب على github.com ، وكما كنت آمل ، كان من الممكن أن يصل إلى الأول الموقف (الذي ، ومع ذلك ، لم يحدث).

ونعم ، لقد أغلقت السؤال (وإن لم يكن في اليوم نفسه ، ولكن لليومين القادمين من اليوم) عن طريق نقل التطبيق إلى تقديم الخادم باستخدام riot.js. وفي نفس اليوم الذي حدث فيه هذا ، انتقل الموقع إلى الصفحات العشرة الأولى من نتائج البحث. وخلال أسبوع ذهبت إلى الصفحة الأولى ، حيث لم تغادرها منذ عدة سنوات.

هذا ينهي قصة النجاح ويبدأ تاريخ الهزائم. كان المشروع التالي أكثر تعقيدًا. صحيح ، كانت هناك نقطة إيجابية في أن 99 ٪ من شاشات التطبيق كانت في حساب المستخدم الشخصي ، لذلك ليست هناك حاجة لتقديم الخادم. مستوحاة من أول تجربة ناجحة لاستخدام riot.js ، بدأت في الترويج لفكرة دمج النجاح وتطبيق riot.js على الواجهة الأمامية. ثم بدا لي ، أخيرًا ، أنه تم إيجاد حل يجمع بين البساطة والوظائف ، كما وعدت وثائق riot.js. كيف الخطأ كنت!

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

ومع ذلك ، فإن المشكلة الرئيسية التي نشأت في هذه المرحلة لا تتعلق حتى بترجمة المخطط من تنسيق القالب إلى مكونات riot.js. فجأة ، اتضح أن riot.js يقدم رسائل غير معلوماتية بالكامل حول أخطاء تجميع القوالب ، وكذلك أخطاء وقت التشغيل (هذا صحيح بالنسبة لجميع إصدارات riot.js حتى الإصدار 4.0 ، الذي أعيد تصميمه بالكامل). لا توجد معلومات ليس فقط حول السطر الذي حدث فيه الخطأ ، ولكن حتى عن اسم الملف أو المكون الذي حدث فيه الخطأ. كان من الممكن البحث عن خطأ لعدة ساعات متتالية ، ومع ذلك لم يتم العثور عليه. ثم اضطررت إلى استعادة كل التغييرات إلى آخر حالة عمل.

ما يلي كان مشكلة في التوجيه. يأتي التوجيه في riot.js تقريبًا خارج المربع github.com/riot/route - على الأقل من نفس المطور. هذا سمح له بالأمل في عملية خالية من المتاعب. لكن في مرحلة ما لاحظت أن بعض الصفحات مثقلة بشكل غير متوقع. أي أنه في المرة التي يمكن أن يحدث فيها الانتقال إلى مسار جديد في وضع التطبيق أحادي الصفحة ، ومرة ​​أخرى ، زاد التحميل نفسه عن تحميل مستند HTML بأكمله ، كما هو الحال عند العمل مع تطبيق ويب كلاسيكي. في هذه الحالة ، بالطبع ، فقدت الحالة الداخلية إذا لم يتم حفظها بعد على الخادم. (في الوقت الحالي ، تم إيقاف تطوير هذه المكتبة ولا يتم استخدامه مع الإصدار 4.0 من riot.js.)

كان المكون الوحيد للنظام الذي يعمل كما هو متوقع هو github.com/jimsparkman/RiotControl ، مدير الحالة الذي يشبه التدفق في الحد الأدنى. صحيح ، للعمل مع هذا المكون ، كان من الضروري تعيين وإلغاء تغييرات مستمعي الحالة في كثير من الأحيان أكثر مما نود.

كانت الفكرة الأولية لهذه المقالة هي: إظهار مثال على تجربتنا الخاصة مع إطار عمل riot.js المهام التي يتعين على المطور حلها ، والذين قرروا (قرروا) تطوير تطبيق على إطار JS وليس من قائمة TOP-3. ومع ذلك ، أثناء عملية التحضير ، قررت تحديث بعض الصفحات من وثائق riot.js في ذاكرتي ، وعلمت أن إصدارًا جديدًا من riot.js 4.0 تم إصداره ، والذي تم إعادة تصميمه بالكامل (من البداية) ، والذي يمكن العثور عليه في مقالة مطور الشغب. شبيبة على medium.com: medium.com/@gianluca.guarini/every-revolution-begins- with-a-riot- js-first- 6c6a4b090ee . من هذا المقال ، علمت أن جميع المشكلات الرئيسية التي أثارت قلقي ، والتي كنت سأتحدث عنها في هذا المقال ، قد تم القضاء عليها. على وجه التحديد ، في الإصدار riot.js 4.0:

• تمت إعادة كتابة المحول البرمجي بالكامل (أو بالأحرى ، تمت كتابته أولاً لأن المحرك كان يعمل على تعبيرات عادية من قبل) - وهذا يؤثر ، على وجه الخصوص ، على محتوى معلومات رسائل الخطأ
  
• بالإضافة إلى تقديم الخادم ، تمت إضافة hydrate على العميل - هذا سمح لنا أخيرًا ببدء كتابة التطبيقات العالمية دون تقديم مزدوج (أول مرة على الخادم وهناك مباشرة على العميل بسبب نقص وظيفة hydrate () في الإصدارات الأقدم)
• إضافة مكون إضافي لمكونات التحميل الزائد github.com/riot/hot-reload
• والعديد من التغييرات المفيدة الأخرى

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

لسوء الحظ ، لم يتم تقييم العمل الذي قام به مطورو riot.js بشكل صحيح من قبل المجتمع. على سبيل المثال ، قام الخادم الذي يعرض مكتبة github.com/riot/ssr للأشهر الستة التي انقضت منذ بداية تطويره بتجميع ثلاثة مساهمين وثلاثة إعجابات على github.com (لا يتم إجراء جميع الإعجابات من قِبل المساهمين ، على الرغم من كون المساهم هو نفسه).

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

لذلك نحن هنا نذهب. على سبيل المثال ، تم تنفيذ تطبيق github.com/gothinkster/realworld . تمت مناقشة هذا المشروع أكثر من مرة على حبري. بالنسبة لأولئك الذين ليسوا على دراية به ، سوف أصف فكرته بإيجاز. يقوم مطورو هذا المشروع بمساعدة لغات وأطر عمل برمجة مختلفة (أو بدونها) بحل نفس المشكلة: تطوير محرك مدونة يشبه إصدار مبسط من medium.com في وظائفه. هذا حل وسط بين تعقيد التطبيقات الحقيقية التي يتعين علينا تطويرها على أساس يومي و todo.app ، والذي لا يسمح لنا دائمًا بتقدير العمل مع المكتبة أو الإطار. هذا المشروع محترم من قبل المطورين. تأكيدًا لما ذكر أعلاه ، يمكنني القول أنه يوجد تطبيق واحد من Rich Harris (المطور الرئيسي لـ sveltejs) github.com/sveltejs/realworld.

بيئة التطوير

بالطبع أنت مستعد للاندفاع نحو المعركة ، ولكن فكر في المطورين من حولك. في هذه الحالة ، ركز على مسألة بيئة التطوير التي يعمل فيها زملاؤك. إذا لم يكن هناك مكونات إضافية لبيئات التطوير الرئيسية ومحررات كود البرنامج للإطار الذي ستعمل به ، فمن غير المرجح أن يتم دعمك. على سبيل المثال ، استخدم محرر Atom للتطوير. بالنسبة له ، هناك github.com/riot/syntax-highlight/tree/legacy ، مكون إضافي للشغب ، لم يتم تحديثه خلال السنوات الثلاث الماضية. وفي نفس المستودع ، يوجد مكون إضافي لـ github.com/riot/syntax-highlight - وهو مكون حالي - وهو حالي ويدعم الإصدار الحالي من riot.js 4.0.

ومع ذلك ، فإن المكون riot.js هو جزء صحيح من مستند HTML حيث يوجد كود JS في نص عنصر البرنامج النصي. كل شيء يعمل فقط إذا قمت بإضافة نوع مستند html لملحق * .riot. بالطبع ، هذا قرار إجباري ، لأنه لولا ذلك كان من المستحيل الاستمرار هنا.

لدينا تسليط الضوء على بناء الجملة في محرر نصوص ، والآن نحن بحاجة إلى وظائف أكثر تقدما ، ما اعتدنا على الحصول عليه من eslint. في حالتنا ، يتم تضمين رمز JS المكون في النص الأساسي لعنصر البرنامج النصي ، وكنت آمل أن أجد ووجد مكونًا إضافيًا لاستخراج رمز JS من مستند HTML - github.com/BenoitZugmeyer/eslint-plugin-html . بعد ذلك ، بدأ تكوين eslint في الشكل التالي:

{ "parser": "babel-eslint", "plugins": [ "html" ], "settings": { "html/html-extensions": [".html", ".riot"] }, "env": { "browser": true, "node": true, "es6": true }, "extends": "standard", "globals": { "Atomics": "readonly", "SharedArrayBuffer": "readonly" }, "parserOptions": { "ecmaVersion": 2018, "sourceType": "module" }, "rules": { } } 

ربما لا يكون وجود المكونات الإضافية لتمييز بناء الجملة و eslint هو أول شيء يبدأ المطور في التفكير فيه عند اختيار إطار عمل JS. في هذه الأثناء ، بدون هذه الأدوات ، قد تواجه معارضة من الزملاء ونزوحهم الجماعي لأسباب "جيدة" من المشروع. على الرغم من أن السبب الوحيد والصحيح هو أنهم غير مرتاحين للعمل بدون ترسانة مطور كاملة. في حالة riot.js ، تم حل المشكلة بواسطة طريقة Columbus. بمعنى أنه لا توجد في الواقع إضافات لـ riot.js ، ولكن نظرًا لخصائص بناء جملة قالب riot.js ، التي تبدو وكأنها جزء من مستند HTML عادي ، فإننا نغطي 99٪ من الوظائف اللازمة باستخدام أدوات للعمل مع مستند HTML.

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

مشروع التجمع

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

لذلك ، سأحاول سرد قائمة التحقق ، ما تحتاج إلى إيلاء اهتمام خاص له عند تحليل أدوات بناء المشروع:

1. وجود وضع التنمية وتطبيق العمل
في وضع المطور:
2. رسائل إعلامية حول أخطاء تجميع المشروع (اسم الملف المصدر ، رقم السطر في الملف المصدر ، وصف الخطأ)
3. رسائل إخبارية حول أخطاء وقت التشغيل (اسم الملف المصدر ، رقم السطر في الملف المصدر ، وصف الخطأ)
4. إعادة التجميع السريع للوحدات المعدلة
5. الزائد الساخن للمكونات في المتصفح
في وضع التشغيل:
6. وجود إصدار في اسم الملف (على سبيل المثال 4a8ee185040ac59496a2.main.js)
7. تخطيط الوحدات الصغيرة في وحدة واحدة أو أكثر (قطع)
8. كود اقتحام أجزاء باستخدام الاستيراد الديناميكي

في الإصدار 4.0 من riot.js ، ظهرت الوحدة النمطية github.com/riot/webpack-loader ، والتي تتوافق تمامًا مع قائمة الاختيار المحددة. لن أدرج كل ميزات تكوين التجميع. الشيء الوحيد الذي سأهتم به هو أنه في المشروع قيد النظر ، أستخدم وحدات للتعبير عن الموقع الإلكتروني: webpack-dev-middleware و webpack-hot-softwareware ، والتي تسمح لك بالعمل على خادم كامل الوظائف على الفور ، من وقت التنضيد. هذا ، على وجه الخصوص ، يسمح بتطوير تطبيقات الويب العالمية / غير المتماثلة. أوجه انتباهكم إلى حقيقة أن وحدة التحميل الزائد الساخن للوحدة صالحة فقط لمتصفح الويب. في الوقت نفسه ، يبقى المكون الذي تم تقديمه على جانب الخادم كما هو دون تغيير. لذلك ، من الضروري الاستماع إلى التغييرات التي أجريتها ، وفي الوقت المناسب ، احذف جميع التعليمات البرمجية المخزنة مؤقتًا بواسطة الخادم وقم بتحميل رمز الوحدات النمطية التي تم تغييرها. كيفية القيام بذلك لفترة طويلة ، لذا سأوفر رابطًا للتنفيذ: github.com/apapacy/realworld-riotjs-effector-universal-hot/blob/master/src/dev_server.js

التوجيه

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

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

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

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

... يجعل من السهل إنشاء تطبيقات SPA. يشمل الميزات التالية

• مسارات متداخلة / طرق العرض
• تكوين جهاز التوجيه المعياري
• الوصول إلى معلمات الطريق ، الاستعلام ، أحرف البدل
• عرض انتقال الرسوم المتحركة على أساس Vue.js
• تحكم ملاحة مريح
• التثبيت التلقائي لفئة CSS النشطة للروابط
• أوضاع محفوظات HTML5 أو التجزئة ، مع التبديل التلقائي في IE9
• التمرير سلوك مخصص

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

1. يجب أن تعمل بنفس الطريقة على جانب عميل الويب وجانب خادم الويب لتطبيقات الويب العالمية / غير المتجانسة ؛
2. يجب أن تعمل مع أي إطار (بما في ذلك اختياري) أو بدونه.

لقد وجدت مثل هذه المكتبة ، هذه هي github.com/kriasoft/universal-router . إذا وصفنا فكرة هذه المكتبة لفترة وجيزة ، فإنها تقوم بتكوين المسارات التي تأخذ سلسلة من عناوين URL عند الإدخال وتستدعي وظيفة غير متزامنة في المخرجات ، والتي تمر على عنوان URL الذي تم تحليله كمعلمة فعلية. بصراحة ، أردت أن أسأل: هل هذا كل شيء؟ وكيف إذن يجب أن يعمل الجميع مع هذا؟ ثم عثرت على مقالة على medium.com medium.com/@ippei.tanaka/universal-router-history-react-97ec79464573 ، حيث تم اقتراح خيار جيد إلى حد ما ، باستثناء ربما إعادة كتابة طريقة محفوظات push () ، والتي لم تتضمن أحتاج والذي قمت بحذفه من الكود الخاص بي. نتيجة لذلك ، يتم تعريف تشغيل جهاز التوجيه على جانب العميل مثل هذا تقريبًا:

 const routes = new UniversalRouter([ { path: '/sign-in', action: () => ({ page: 'login', data: { action: 'sign-in' } }) }, { path: '/sign-up', action: () => ({ page: 'login', data: { action: 'sign-up' } }) }, { path: '/', action: (req) => ({ page: 'home', data: { req, action: 'home' } }) }, { path: '/page/:page', action: (req) => ({ page: 'home', data: { req, action: 'home' } }) }, { path: '/feed', action: (req) => ({ page: 'home', data: { req, action: 'feed' } }) }, { path: '/feed/page/:page', action: (req) => ({ page: 'home', data: { req, action: 'feed' } }) }, ... { path: '(.*)', action: () => ({ page: 'notFound', data: { action: 'not-found' } }) } ]) const root = getRootComponent() const history = createBrowserHistory() const render = async (location) => { const route = await router.resolve(location) const component = await import(`./riot/pages/${route.page}.riot`) riot.register(route.page, component.default || component) root.update(route, root) } history.listen(render) 

الآن أي دعوة إلى history.push () ستبدأ التوجيه. للتنقل داخل التطبيق ، تحتاج أيضًا إلى إنشاء مكون يلف عنصر HTML القياسي (مرساة) ، دون أن ينسى إلغاء سلوكه الافتراضي:

 <navigation-link href={ props.href } onclick={ action }> <slot/> <script> import history from '../history' export default { action (e) { e.preventDefault() history.push(this.props.href) if (this.props.onclick) { this.props.onclick.call(this, e) } e.stopPropagation() } } </script> </navigation-link> 

إدارة حالة التطبيق

في البداية ، قمت بتضمين مكتبة mobx في المشروع. كل شيء يعمل كما هو متوقع. إلا أنها لم تتوافق تمامًا مع المهمة - الدراسة التي قمت بتعيينها في بداية المقالة. لذلك تحولت إلى github.com/zerobias/effector . هذا مشروع قوي جدا. يوفر 100 ٪ من وظائف إعادة التشغيل (فقط بدون حمل كبير) ووظائف mobx بنسبة 100 ٪ (على الرغم من أنه في هذه الحالة سيكون من الضروري ترميز أكثر قليلاً ، ولكن لا يزال أقل إذا ما قورنت مع mobx بدون أدوات تزيين)

يبدو وصف المتجر كالتالي:

 import { createStore, createEvent } from 'effector' import { request } from '../agent' import { parseError } from '../utils' export default class ProfileStore { get store () { return this.profileStore.getState() } constructor () { this.success = createEvent() this.error = createEvent() this.updateError = createEvent() this.init = createEvent() this.profileStore = createStore(null) .on(this.init, (state, store) => ({ ...store })) .on(this.success, (state, data) => ({ data })) .on(this.error, (state, error) => ({ error })) .on(this.updateError, (state, error) => ({ ...state, error })) } getProfile ({ req, author }) { return request(req, { method: 'get', url: `/profiles/${decodeURIComponent(author)}` }).then( response => this.success(response.data.profile), error => this.error(parseError(error)) ) } follow ({ author, method }) { return request(undefined, { method, url: `/profiles/${author}/follow` }).then( response => this.success(response.data.profile), error => this.error(parseError(error)) ) } } 

تستخدم هذه المكتبة مخفضات كاملة (يطلق عليها في وثائق effector.js) ، والتي يفتقر إليها الكثير من الناس في mobx ، ولكن مع جهد ترميز أقل بكثير من الإعادة. لكن الشيء الرئيسي ليس حتى ذلك. بعد أن حصلت على 100٪ من وظائف redux و mobx ، استخدمت فقط عُشر الوظائف الموروثة في effector.js. من خلالها يمكننا أن نستنتج أن استخدامه في المشاريع المعقدة يمكن أن يثري بشكل كبير أموال المطورين.

تجريب

TODO

النتائج

لذلك ، اكتمل العمل. يتم تقديم النتيجة في مستودع github.com/apapacy/realworld-riotjs-effector-universal-hot وفي هذا المقال عن حبري.
موقع تجريبي في الآن realworld-riot-effector-universal-hot-pnujtmugam.now.sh

وفي النهاية سوف أشارك انطباعاتي عن التطور. تطوير على الإصدار 4.0 من riot.js مريحة للغاية. العديد من البنيات أسهل في الكتابة من React. استغرق الأمر أسبوعين بالضبط للتطور دون تعصب في ساعات ما بعد وفي عطلات نهاية الأسبوع. ولكن ... واحدة صغيرة ولكن ... لم تحدث المعجزة مرة أخرى. خادم تقديم في React 20-30 مرات أسرع. الشركات تفوز مرة أخرى. ومع ذلك ، تم اختبار مكتبات توجيه ومدير حالة مثيرة للاهتمام.

apapacy@gmail.com
17 يونيو 2019