تنصل
عزيزي القارئ! إذا لم تكن لديك أي فكرة عن ماهية React و Redux ، فإن القراءة بشكل أكبر لا معنى لها ، كما أنها لا معنى لها. إنني بجدية ، مع فهم الغرض من هذه المذكرة ، يتطلب العمل مع هذه المكتبات - على الرغم من حقيقة أنني سأحاول الكتابة بوضوح ، فإن هذه المقالة ليست مقالة دخول. وهذه هي التجربة الشخصية والرأي القائم على الممارسة.
ما هو الخطأ في استخدام Redux؟
بعد ذلك قررت أن أكتب ، ولكن ما الخطأ فعلاً في استخدام الإعادة في مشروعي وآلاف الآخرين؟ كنت أكتب طلبات الرد / الإعادة منذ أبريل 2016 (ثلاث سنوات). لقد حان الوقت لاكتشاف بعض الأشياء المثيرة للاهتمام ... ثم كانت هناك محاضرات وتقارير ، ولا سيما موجهة للمبتدئين ، ولكن لم يكن هناك أي بالغ ينظر إلى الوراء وليس له أثر رجعي. في هذه الأثناء ، يضع شخص ما النجمة في عبوات تتفحص "ألا تكونين في الثالثة عشرة من كل ساعة" ، وسأكسر جدار الصور النمطية السائدة.
ولكن ليست هناك حاجة الإعادة!
أنت تقول ، وفي بعض النواحي سوف تكون على حق. لا يمكن استخدامه منذ عام 2018 - هناك الكثير من المقالات حول هذا الموضوع على الإنترنت ، ولكن حتى الآن مع "عدم الاستخدام" يتم الحصول على مزرعة جماعية ، سوف يصبح من الواضح أدناه. وعدد البدائل هو خارج النطاق وحتى أكثر من ذلك.
نحن نستخدم Redux ، لأنه معيار مقبول (على الأقل للرد) ، فإن القدرة على التنبؤ والموثوقية التي يتمتع بها Redux مهمة بالنسبة لنا. لكننا نفتقدها بجدية ، في الواقع في هذا
مطالبة
ربما ، لتوضيح ماهية الادعاء حول النقاط ، فأنت بحاجة أولاً إلى العودة إلى الماضي ، إلى الجذور ، كما تريد ، أي فتح وثائق الإعادة المجيدة وقراءة المسلمات. سوف ننظر فقط أول منهم. إذا كان ذلك مثيراً للاهتمام لك - شارك في التعليقات ، سأحلل المزيد من النقاط.
المصدر الوحيد للحقيقة ...
هنا لدينا كمين. بطبيعة الحال ، فإنه يقول أنه يمكن أن يكون هناك قصة واحدة ، تعلن شركة redux عن اختلافها عن هندسة التدفق في هذه الطريقة. لكن إذا نظرت على نطاق أوسع: هل تمت ملاحظة القاعدة في مشروع حقيقي؟ ستقول: تماما. أعلن (أعلن) جانب واحد ، وأنا أنقله إلى المزود ومن ثم ...
من الناحية الفنية ، يتم وصف العملية بشكل صحيح. لكن يمكنني أن أقول إن الأشخاص يخضعون لتشويهات في الإدراك والمنطق ، ولأن المبرمجين ما زالوا أشخاصًا ... حسنًا ، أنت تفهم ما الذي أفضي إليه (إذا لم تفهم: المبرمجون عرضة لتشويهات الإدراك والمنطق وما إلى ذلك)
التشويه الرئيسي هنا هو أنني ، مثل العديد من زملائي ، معتادون على حقيقة أننا إذا لم نستخدم مصطلح "مخزن" فيما يتعلق بأي شيء آخر غير الإعادة ، فلن يكون هناك آخرون.
وهنا يأتي رد الفعل
أرادت ميزة تقنية واحدة تسمى الحالة الداخلية البصق على هذه الفرضية. إنه ببساطة يخلق حالة تخزين من النوع الداخلي في أي مكان مناسب. هناك مكون - هناك حالة لديها آلية لتحديث المكون والتأثير عليه. الفرق في الاستخدام (حالة المتجر وتحديث وتغييرات البث) غير مرئي تقريبًا. يمكنك الاعتراض: ليس واضحًا تمامًا لماذا لا تحب حالة المكون. إنه ليس مثل المحررين ، كيف يمكن مقارنتهم! إنه داخلي ، حسناً ، ما هي الأعلام التي يجب تخزينها هناك.
افهم أن الجوهر لا يتغير عن حقيقة إعادة تسمية العنصر. هناك مطرقة ثقيلة الاثنين ، وهذا لا يجعلها يوم من أيام الأسبوع. نعم ، الاثنين صعبان ، والأيام الأخرى ومطرقة المطرقة أسهل. لكن من اسمها ، مطرقة ثقيلة لا تتوقف عن كونها أداة قرع.
مقياس مكون رد الفعل واستعادة الحالة مختلف ، ولكن الجوهر ، عند استخدامه اليوم ، واحد.
سأشرحها بهذه الطريقة: في معظم الحالات ، يتم نقل البيانات من الحالة الداخلية للمكون إلى الطفل عبر الدعائم ، ولكن ، بغض النظر عن مدى وضوحها ، فإن بيانات الإعادة ، عند دمجها مع رد الفعل ، تدخل أيضًا في المكونات من خلال الدعائم. من وجهة نظر المكون الذي يقبل الدعائم ، لا يهم ما هو في الخارج. وهذا هو ، بالنسبة للمستخدم النهائي - متجر الإرجاع هذا الحالة الداخلية - هو نفسه.
أيضًا ، قد لا تعتمد هذه الحالة الداخلية على الدعائم الخاصة بالمكون الذي تم إعلانه فيه. ثم نحصل على العزلة التي تجعل مثل هذه الحالة الداخلية متجراً أكبر مما تتخيل.
من أجل أن يكون داخليًا فعليًا ، يجب أن يؤثر فقط على المكون الذي تم إعلانه فيه ، دون تسريب المكونات الفرعية. هل هو صعب؟ تماما ، لأن معناه ضاع تماما تقريبا. هذه علامة أخرى على أن الحالة الداخلية هي متجر. بعد كل شيء ، قمنا ببساطة بإزالة نقطة واحدة من غرض "تخزين الحالة وتحديث وتغيير البث" - بث التغييرات. كل شيء ، الدولة ضائعة.
أي أن المشكلة الرئيسية في وجود حالة داخلية هي أنها تتنافس مع الإعادة على البيانات ، وتفقد على المدى الطويل ، وهراء. لدينا جميع أنواع التقنيات مثل حالة الرفع لأعلى (وهذا هو عندما تكون هناك حاجة لعنصر عنصر المضيف ، لذلك يتم نقل جزء الحالة وكل منطق العمل معه إلى الوالد ، وقضاء الكثير من الوقت في إعادة كتابة واختبار منطق العمل) ، إلخ. في التحسينات والكثير من الفرح. هذا هو كل الضوضاء التي تفسد برنامجنا في مرحلة التطوير. لم نصل إلى المبيعات ، لكن البرنامج بالفعل هكذا.
هذا هو ، على الرغم من جميع العلامات والمشاكل ، لدينا أكثر من قصة واحدة والعديد من المشاكل المرتبطة بهذا. الشيء الأخير ، على الأرجح ، هو ما يلي:
أنا أيضا أحب الإعادة لهذا النوع من devtools لديها. عندما بدأت ، استخدمنا المسجل الذي قام بتوحيد جميع الإجراءات ، دون إعطاء صورة كاملة لما كان يحدث. الآن - هذا هو المساعد الرئيسي والصديق. في React ، يتم تمثيلهم أيضًا. بشكل عام ، devtools هو السبب وراء كون pubsub بعيدًا عن Redux. مثل نملة لحوت أزرق.
مشاكل (لن يكون هناك دليل على الحمض النووي):
- في بعض الأحيان لا يؤدي تغيير الحالة الداخلية من خلال devtools للرد إلى تحديث أو النتيجة المرجوة - أخطئ في التكامل مع الإعادة.
- فواصل الحالة الداخلية timetravel في devtools التراجع. الميزة الفائقة مع السفر عبر الزمن المتاح من خلال بنية redux لا تعمل بفضل بنية الحالة الداخلية المتفاعلة. الحالة الداخلية فقط لم تهتم بتغيير في التكرار ، لديها حالتها الخاصة. Timetravel فقط لا يعمل بها. بعض العناصر ببساطة لا يتم تحديثها أو تحديثها جزئيًا أو ما إلى ذلك. كل هذه الملحمة مع تزامن الكود غير المتزامن أسفل الصرف.
مثال ، بالطبع ، امتص من الممارسة
أنت تعمل في مشروع جديد من أجلك ، أو كتب زميلك بعض الوظائف قبل عام ، والآن تحتاج إلى توسيعه. بشكل عام ، هناك مهمة وضع اللمسات الأخيرة على رمز شخص آخر. تبدأ بالتحقيق وتفهم أنه لا توجد بيانات في المحررين. لا توجد إجراءات ، مخفضات في الكود تخزن البيانات التي تحتاجها. وتبدأ الرحلة عبر شجرة المكونات بحثًا عن الكنز وتجدهم (!!!) حتى بضع قطع. أنت تسأل الزملاء ، ولكن الإجابة قياسية: لا أتذكر الكتابة إلى الدولة بشكل أسرع ، ولم يكن لدينا وقت وما إلى ذلك. تذهب إلى المصدر وتفهم أن حالته الحالية لا تتضمن مراجعة. أنت تعيد كتابة العمل ، وتم اختبار الكود لإجراء تغييرات وإضافة وظائف جديدة.
وجود بديل خبيث في شكل دولة داخلية يقوم بعمله القذر. بعد كل شيء ، الآن أصبح رخيصًا ، ولا يهم ما يحدث خلال عام.القليل من الاستعارات
يبدو الطعام سيئًا - يبدو لذيذًا ورخيصًا ، ولكن بعد عام أو 3 - تتوقف القناة الهضمية عن الانصياع لحياتها. تقضي الكثير من الوقت والمال لاستعادة صحتك السابقة ولا تنجح دائمًا في ذلك.
Redux و React Internal State من المنافسين ، مثل الشركات الكبيرة والصغيرة في مكان واحد. المنتج الرئيسي هو البيانات والتأثير. البرنامج هو المستهلك لمنتجاتها. هناك العديد من أوجه التشابه ، لكن يبقى الجوهر كما هو - عندما نطور البرامج - لا نحتاج إلى منافسة.
نحن "الديكتاتوريون" في كود البرنامج ، ويجب قمع أي منافسة ، ويجب حظر السوق الحرة ، وينبغي أن يهيمن الاقتصاد المخطط للدولة واحتكار الدولة على المستهلك.مهم ، شيء حملني. كل شيء يجب أن يذهب وفقا للخطة ، بشكل عام. لدينا سرعات وإصدارات وأكثر من ذلك ، وللبرنامج تكلفة محدودة وعمر / دخول إلى السوق. هذا مهم للغاية ، ولا يمكننا السماح لأحداث الشغب على متن السفينة ، وانتفاضة المكتبات.
الاستنتاج بسيط.
لا تستخدم مستودعات أخرى مع الإعادة. يمكن أن تجعل الاستثناءات فقط حالات معزولة للغاية. على سبيل المثال ، لا يتم التحكم في المكونات التي من حيث المبدأ من خلال الإعادة دون الطبقة المقابلة ولا تؤثر عليها.
مثال
لقد قمت بتطوير الوحدة النمطية المستقلة في أحد الفروع وإعادة إنشاء المتجر في فرع آخر - بشكل عام ، فإن نهجي في إدارة المتجر والحالة موضوع منفصل للنشر. لقد بدأت إعادة بيع الوحدات النمطية للوحدة النمطية ، ولكن في وقت بداية ونهاية كتابة الوحدة النمطية ، لم تتلاشى إعادة بيع العقارات إلى الاختبار وإلى المعالج. إعادة بيع المباني كبيرة وتتطلب اللجوء إلى التفكير المدروس الذي يجب التخطيط له - بشكل عام ، لا يمكنك أن تأخذ وتعيد رد الفعل.
لذلك ، لمعرفة التغييرات القادمة في المتجر ، لم أستخدمها لتطوير ميزة جديدة. هذا من شأنه أن يزيد من تكاليف تحديث إعادة هيكلة المهجورة والاختبارات في بعض الأحيان.
ماذا فعلت: لقد قمت بالتسجيل للحصول على الحد الأدنى من البيانات. لم تكن البيانات وهيكلتها تعاني من إعادة البناء ، فقد عانت الكود الذي أنشأها وحفظته ، وما إلى ذلك. لم أكتب بايت للمحررين. أتحقق مما إذا كان المستخدم قد قام بتسجيل الدخول وحقول أخرى.
لاحتياجاتي ، قمت بغسل PubSub مع القنوات وواجهة برمجة تطبيقات بسيطة. نعم ، نعم ، pubsab. عدم وجود ألم مؤلم طبيعي. السفر عبر الزمن - الألم. بشكل عام ، أخطط لكتابة ملحق لـ chrome في شكل devtools ومن الممكن نشر إعادة التنفيذ كمنافس لإعادة في github. لدي الكثير من الشكاوى حول الإعادة ، والتي لن أثيرها في هذه المقالة ، لكن PubSub لا يمتلكها عملياً. إلى جانب حقيقة أنني تذكرت مسجل إعادة ...
وبالتالي فإن الوحدة لديها وحدة تخزين خاصة بها ، واتصالها بالخادم.
وهذا يعني أن الإعادة لا تؤثر على الوحدة على الإطلاق ، ولا يمكن عملياً التأثير على وحدة التخزين هذه (هناك ثلاثة حقول فقط في الاشتراك) ، لكن الوحدة النمطية وحانة PubSub لا تؤثران على الإعادة بأي طريقة. هذا الفصل يستبعد المنافسة.
السؤال "أين لتخزين البيانات؟" عند تطوير الوحدة ، لم أصادفها مطلقًا. ولكن عندما يتعلق الأمر بإعادة التراجع إلى الحالة الداخلية - بالنسبة للكثيرين ، فإن هذا السؤال ينشأ باستمرار تقريبًا. قررت الإجابة على هذا السؤال مرة واحدة وإلى الأبد.
رأيي المعماري هو:
قم بتخزين البيانات فقط في حالة الإعادة (جميعها ، حتى "داخلية") ، إذا كان متصلاً بمشروع تفاعلك باعتباره المستودع الرئيسي ، فلا تستخدم المستودعات التي ستنافسه. سيؤدي ذلك إلى زيادة موثوقية وتأثير هذه المكتبة وأدواتها devtools (تتبع الوقت وتتبع جميع البيانات في خطوات تسريع عملية التطوير والبحث عن المشاكل المحتملة - التغييرات المتزامنة أكثر حدة وأسهل للتزامن).
ربما يستحق الأمر إضافة مكتبة تستبعد تمامًا الحالة الداخلية من التطوير؟ أو يستبدل الحالة الداخلية باختيار من التكرار ، على سبيل المثال؟ لقد بدأت في كتابة واحدة قبل عام ، وحصلت على نسبة 90٪ ، وأجرت تقريرًا واحدًا. ماذا تقول؟ بحاجة الى هؤلاء؟
آمل أن تستمتع هذه المذكرة :)