Redux: لماذا لا يمكن تحور الدولة ....

https://github.com/rackt/redux/issues/328

الأمر كله يتعلق بإمكانية التنبؤ والموثوقية.

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

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

وستحصل على ميزات مجانية مثل السفر عبر الزمن وهو سهل للغاية.

إغلاق كنسخة مكررة من رقم 328.

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

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

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

بالضبط ، يستخدم react-redux shouldComponentUpdate قويًا تحت الغطاء بفضل ضمان الثبات.

gaearon آسف

علاوة على ذلك ، عندما تصبح باهظة الثمن (مثل التغييرات السريعة في المصفوفة) ، يمكنك البدء في استخدام مكتبة مثل Immutable.js التي تتمتع بنسخ سريع جدًا بفضل المشاركة الهيكلية.

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

dougajmcdonald : سؤالي الأول هو ، هل يمكن تجميع أي من هذا العمل بطريقة ما؟ هل تحتاج _ حقًا_ إلى تمثيل كل تحديث فردي كإعادة رسم منفصلة لواجهة المستخدم؟

أبعد من ذلك ، أقترح عليك إلقاء نظرة على هذه الموارد حول الأداء المرتبط بـ Redux:

• إدخالات الأسئلة الشائعة حول Redux حول الأداء والقياس وتقليل إشعارات الاشتراك واستخدام المحددات
• رسالتي إعادة إحياء عملية ، الجزء 6: القوائم والنماذج والأداء المتصلة
• قسم أداء الإحياء في قائمة روابط React / Redux

سأكون سعيدًا أيضًا للدردشة حول هذا الأمر أكثر في قنوات الدردشة Reactiflux .

markerikson للأسف نعم ، يتضمن مفهوم اللعبة العديد من التحديثات السريعة لهيكل بيانات كبير نسبيًا.
أدرك أنني لم أكن واضحًا تمامًا في تعليقي الأصلي ، عندما أقول 10-100 تغيير ، لن تؤدي جميعها إلى إعادة رسم. التغييرات 10-100 هي تغييرات الحالة التي سيتم تمثيلها بإعادة رسم واحدة لكل 100 مللي ثانية.
لذا ، فإن سؤالي هو حقًا ، إذا كنت سأقوم بدفع تحديثاتي إلى 10-100 تغيير حالة لكل 100 مللي ثانية ، فهل ستتمكن إدارة الحالة داخل redux من معالجة هذه التغييرات بفعالية بطريقة يمكن إكمالها بشكل معقول ضمن نافذة 100ms'esque السماح بإعادة الرسم دون أن تتأخر الأشياء.
ستشمل تحديثات الحالة بشكل أساسي تغيير 3-4 خصائص في مصفوفة بحجم 8000 ، لذلك سنتحدث عن إنشاء مصفوفة جديدة 1-10 مرات لكل مللي ثانية (بافتراض أننا نريد إبقاء الأشياء ثابتة) مع بعض التغييرات على واحدة من الكائنات داخل فهرس الصفيف. الأشياء صغيرة جدًا (3-4 خصائص ، زوجان من الأرقام وسلاسل صغيرة)

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

dougajmcdonald : حسنًا ، "إدارة الدولة في Redux" هي في الحقيقة مجرد وظيفة مخفض جذر واحدة _ قدمتها :)

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

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

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

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

markerikson jibe خفية اتخذت على الأنف! : p نعم ، أنت على حق ، فإن الجانب المخفض للأشياء في الوقت الحالي هو في الأساس إنشاء وتدمير مصفوفة كبيرة إلى حد ما ولكن أعتقد أن المشكلة الحقيقية هي على الأرجح دورة حياة مكون التفاعل بتات وبوبز عندما يكون الهدف النهائي عنصر قماش يتم عرضه بشكل مثالي عند 60ish FPS.
شكرًا على النقطة المتعلقة بالثبات والنقاط المتعلقة بالطفرة المباشرة ، سأقرأها قليلاً وأعتبرها أيضًا.
في الوقت الحالي ، تتمثل عملية تفكيري في فصل حالة إعادة الإرسال عن اللوحة القماشية وتمرير الرسائل إليها عبر pub / sub (وهي الطريقة التي تم بها توصيلها بالفعل) فقط مع المزيد من الأجزاء المتحركة

أفكر في التغيير من:
pubsub> إرسال ()> المخفض> حالة إعادة الإرسال> عناصر مكون التفاعل> عرض قماش.

إلى:
pubsub> حالة المكون المحلي> عرض اللوحة

سأستمر في استخدام redux لبقية واجهة المستخدم ، ربما ليس فقط جزء اللوحة من التطبيق.

أسئلتك صحيحة تمامًا. في الواقع ، يعمل تطبيق vuejs للإعادة المسمى vuex تحت مفهوم الطفرة. لذا فإن "المخفضات" تسمى في الواقع الطفرات وطالما قمت بتعديل الحالة في مكان مركزي ، يجب أن يكون كل شيء على ما يرام. يحدث هذا لأن vue يضيف مراقبين وأشياء أخرى إلى حالة التطبيق ، لذا كما ذكرت ، يكون الأمر أكثر منطقية في cae of vue لتعديل الكائن بدلاً من استبداله. لا يمكن تغيير Redux ، وفي النهاية يكون أداء كلا الأسلوبين رد فعل تحديثات DOM الافتراضية VS vue هو نفسه في الغالب عند النقطة التي لا يمكن أن نقول إن أحدها أفضل من الآخر في جميع الحالات