Redux: طلب مناقشة: إعادة "المتداول" ، ومنحنى التعلم ، والتجريد ، والرأي

بعض الأفكار:

• حزمة الإعادة الرسمية المحددة مسبقًا التي تحتوي على إعادة ، رد فعل ، إعادة إحياء ، ردوكس ، ثانك سلكي بالفعل معًا
• dispatch(actionType, payload) إلى تقليل الحاجة إلى صانعي الإجراءات
• منشئو مخفض نمط Jumpstate المدمج ، على سبيل المثال createReducer({[actionType]: (state, payload) => state}, initState)

معظم الأشخاص الذين أعرفهم ممن يستخدمون redux بكثافة ، ينتهي بهم الأمر بالابتعاد عن redux-thunk لأنهم يجدون أنه لا يتسع بشكل جيد ، وينتهي بهم الأمر إلى إنشاء منشئي حركة يبدأون في فعل الكثير ، وبدلاً من ذلك يستخدمون شيئًا آخر لإدارة الجانب - تأثيرات مثل إعادة الملحوظة أو ملحمة الإعادة.

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

إذن ، هذا الجزء هو الأكثر أهمية بالنسبة لي (لن يكون هذا كثيرًا أفكارًا لحل المشكلة ، بل قيودًا ، على الأقل بالنسبة لي ، مهمة):

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

إن الشيء العظيم في Redux هو كيف أنه نمط تصميم أكثر منه إطار عمل ، وكل الكود الذي تراه (باستثناء المتجر و react-redux ) هو رمزك الخاص.

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

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

أخيرًا ، تحاول الكثير من مكتبات تقليل النماذج المعيارية إضافة علاقة 1: 1: 1 بين المكونات والمخفضات ومنشئي الإجراءات (ربما ليس كل 3 ، ولكن غالبًا 2 من هؤلاء) ، مما يجعل الوافدين الجدد ينسون أنه يمكن أن يكون لديهم مخفضات متعددة تتعامل مع إجراء ، ومكونات متعددة باستخدام الحالة من مخفضات متعددة ، وما إلى ذلك. هذا أحد الأسئلة رقم 1 التي أجيب عنها في العمل وأماكن أخرى ، وهو مفيد للغاية. لذا يجب ألا تفقد الأداة للمساعدة في هذا المجال هذا (أيضًا ، "التبديل رديء" ليس أفضل حجة في العالم).

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

"يجب تقليل جميع النماذج المعيارية بغض النظر عن التكلفة" هي مشكلة مع مجتمع هندسة البرمجيات ككل هذه الأيام ... من الصعب معالجتها.

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

// meta code
dispatch(ACTION);

onAction = {
  ACTION: [
    // handler 1: hide spinner here,
    // handler 2: change status there,
    // handler 3: update entity
  ],
};

في النهاية توصلت إلى redux-interactions + redux-tree وأنا سعيد جدًا بهذا الأمر حتى الآن.

النهج في مشروعنا الحالي:

ملاحظة ، سيكون مختلفًا تمامًا اعتمادًا على متطلبات التطبيق :) بمجرد أن نضيف تحديثات الكائنات في الوقت الفعلي ، فربما توفر القصص الملحمية أو المراقبات فائدة أكثر من الوعد / الوعد

• إعادة ثانك
• وعد برمجيات وسيطة
• "غلاف api" الخاص بنا ، وهو عبارة عن غلاف حول تطبيق ريش العميل ، service(name, method, ...opts) وهو منشئ الإجراءات مع الحمولة التي تعد بمثابة وعد باستدعاء API الخاص بنا (على سبيل المثال ، تلتقط البرامج الوسيطة الوعد ذلك وترسل x_FULFILLED و x_PENDING و x_REJECTED ). يمكن أيضا الكتابة فوق اسم الإجراء لهذا الغرض.

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

لقد لعبت مع redux-saga قليلاً ، ولكن نظرًا لأن التدفق غير المتزامن الأكثر تعقيدًا لدينا هو تسجيل الدخول / تسجيل الخروج ، والذي يعمل (والرمز ليس معقدًا بشكل رهيب) ، ليس سببًا كبيرًا للتبديل (ولكن قد يكون الأمر يستحق الاختبار الأسباب - التكرارات + السخرية طريقة لطيفة للاختبار). إعادة الملحوظة لا أرى فائدة فورية ما لم توفر الملاحظات نفسها فائدة ، على سبيل المثال ، إذا كنت تريد النقر نقرًا مزدوجًا فوق الأحداث بشكل جيد.

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

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

ما هو مناسب أيضًا هو الملخص الذي توصلت إليه للأنماط المستخدمة في تطبيق gothinkster / response-redux-realworld-example

معظم الأشخاص الذين أعرفهم ممن يستخدمون redux بكثافة ، ينتهي بهم الأمر بالابتعاد عن redux-thunk لأنهم يجدون أنها لا تتسع بشكل جيد

أفهم ما تقوله ، ولكن إليك ما يقلقني من الجانب الآخر: نشهد المزيد والمزيد من الأدلة القصصية على أن مجموعة ضخمة من مطوري JS لا تستخدم حتى وظائف السهم وغيرها من ميزات ES (6 | 2015) الأساسية حتى الآن ، بسبب نقص الفهم ، التخويف ، إلخ. توقع الأشخاص الذين يرغبون في البدء مع Redux ، والذين يمكنهم الاستفادة من تعلم _الأنماط_ التي يقدمها Redux ، لتعلم الملحوظات أو المولدات أولاً ، هل أعتقد أنه من المحتمل أن تطلب الكثير؟

يعد Redux-thunk أيضًا معقدًا بعض الشيء بمعنى أن البرمجيات الوسيطة redux بشكل عام من النوع الذي يثني عقلك ، ولكنها على الأقل مجرد وظائف / عمليات رد نداء ، والتي يسهل التقاطها إذا كنت تكتب JS على الإطلاق. تعجبني حقًا فكرة امتلاك حزمة كاملة من الأدوات ذات الصلة للبدء بها ، ومتاحة عبر تنزيل واحد ، حتى لو تم طرحها على أنها "Learn-redux" بدلاً من "best-Practice-always-redux". على غرار الطريقة التي يحتاج بها تطبيق create-react-app إلى التغيير والتبديل بينما تتعلم كل الأشياء التي تم إعدادها لك ، فقد يشجع ذلك على التغيير والتبديل الخاص بك ، وربما يُظهر كيفية تحويل إعداد بسيط للإعادة إلى استخدام الملاحم ، وما إلى ذلك كنموذج خاص به من "الإخراج" ...

فقط بعض الأفكار.

أفهم ما تقوله ، ولكن إليك ما يقلقني من الجانب الآخر: نشهد المزيد والمزيد من الأدلة القصصية على أن مجموعة ضخمة من مطوري JS لا تستخدم حتى وظائف الأسهم وغيرها من ميزات ES (6 | 2015) الأساسية حتى الآن ، بسبب نقص الفهم ، التخويف ، إلخ. توقع الأشخاص الذين يرغبون في البدء مع Redux ، والذين يمكنهم الاستفادة من تعلم الأنماط التي يقدمها Redux ، لتعلم الملحوظات أو المولدات أولاً ، هل أعتقد أنه من المحتمل أن يطلب الكثير؟

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

لاحظ أن مستندات Redux تحتوي بالفعل على قسم حول Reducing Boilerplate لأولئك الذين يقرؤون منكم ممن يبحثون عن شيء ما الآن ولا يريدون تبني مكتبة كاملة فوق Redux.

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

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

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

يمكن أن يكون منحنى التعلم Redux حادًا ، ولكن بمجرد فهم المفاهيم ، فإن الحاجة إلى ذلك
غالبًا ما تختفي طبقات التجريد

إنني أتساءل ، إذا كان هذا هو الحال ، فما أجزاء Redux التي نقترح تحسينها؟ ما الأجزاء التي تريد إزالتها أو تجريدها ولن تحتاج إلى إضافتها على الفور؟

هذا رسم تخطيطي لدورة حياة التفاعل / الإعادة الكاملة التي قمت بها للحديث في العمل منذ حوالي عام:

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

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

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

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

بعض المناقشات الجيدة حتى الآن. يلقي Lemme ببعض الأمثلة السريعة للشكاوى الشائعة ذات الصلة بـ "النموذج المعياري" التي أراها:

• "لماذا يجب علي كتابة وظائف" منشئ الإجراء "فقط لإرجاع كائن على الفور؟"
• "يجب أن أتطرق إلى العديد من ملفات SOOO فقط لإضافة ميزة جديدة بسيطة! أيضًا ، أستمر في تكرار نفس الأسماء مرارًا وتكرارًا للثوابت وأسماء الوظائف و ..."
• "لماذا أحتاج إلى أشياء" البرامج الوسيطة "هذه فقط لإجراء مكالمة AJAX؟"
• "لماذا علي استخدام عبارات التبديل لكل شيء؟"
• "لماذا أحتاج إلى هذا الشيء dispatch ؟ لماذا علي إنهاء كل هذه الوظائف لجعلها تعمل؟"

وبعض الأمثلة المحددة لهذه الأنواع من التعليقات:

• تنفيذ Redux أمر شاق.
• الحد الأدنى من إعداد Redux
• Jumpstate README و Jumpstate + Redux + CRA - لا حاجة لمنشئي الإرسال أو العمل!

ولإلقاء بعض الردود على هذه المخاوف "المعيارية" على الفور: من بين تلك الفئات الخمس المدرجة ، فقط "استخدام dispatch " هو في الواقع _ مطلوب _. بالنسبة لبقية:

• ليس عليك استخدام صانعي الإجراءات ، لكنها ممارسة جيدة لتحقيق الاتساق (لكل رسالتي Idiomatic Redux: لماذا أستخدم صانعي الإجراءات؟ )
• ليس عليك أن يكون لديك ملفات منفصلة تمامًا لمنشئي الإجراءات وثوابت الإجراء ومخفضات الأداء. يعد نمط "البط" أسلوبًا شائعًا لتجميع كل هؤلاء في ملف واحد معًا. هذا له جانب سلبي يتمثل في "إخفاء" القدرة على جعل العديد من المخفضات تستمع إلى إجراء واحد. لا يهتم Redux في النهاية بهيكل ملفك.
• يمكنك _ القيام بعمل غير متزامن خارج Redux تمامًا ، كما هو الحال في أحد المكونات. ولكن ، وفقًا لوصف دان في لماذا نحتاج إلى برمجيات وسيطة للتدفق غير المتزامن في Redux؟ ، عادةً ما يكون من الجيد استخراج هذا المنطق خارج المكونات ، وتوفر البرامج الوسيطة "ثغرة" للقيام بعمل غير متزامن أثناء الوصول إلى متجر Redux.
• ليس عليك بالتأكيد استخدام عبارات التبديل في المخفضات ، فهي الطريقة الأكثر "وضوحًا" للتعامل مع القيم المتعددة لمتغير معين. جداول البحث ، عبارات if / else ، وأي شيء آخر تريده على ما يرام (وفقًا للأسئلة الشائعة: هل يتعين علي استخدام عبارات التبديل؟ )
• أنت _do_ تحتاج فعليًا إلى الاتصال بـ store.dispatch() لتحقيق أي شيء مفيد - هذا هو قرار التصميم الأساسي لـ Redux. يجعل منشئو الإجراءات الملزمة من الممكن تمريرها إلى مكونات فرعية غير متصلة مع الاستمرار في إرسالها كلما تم استدعاء الوظيفة.

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

أعتقد أن الأسئلة التي طرحهاmarkerikson عادلة حقًا وقد طرحت عليهم بنفسي في وقت ما في الماضي أيضًا.

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

ربما يجب أن نعتبر أن المسار الصحيح قد يكون تطوير مكتبة جيدة واستقرارها أعلى Redux (مثل Jumpstate؟). نبدأ بتعليم الأشخاص ذلك ، ثم نمنحهم مسارًا سهلاً لاستخدام Redux مباشرةً عندما يحتاجون إلى ذلك.

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

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

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

يجب أن نتبنى نموذجًا مشابهًا.

لتوسيع بعض تعليقات sunjay :

كان هناك تعليق حديث في رقم 775 أعتقد أنه يلتقط الأشياء جيدًا:

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

لذا ، نعم ، يعد Redux "مجرد نمط" من نواح كثيرة. المكتبة الأساسية مكتملة الميزات حقًا - التغييرات الحقيقية شبه المخطط لها هي أشياء مثل إعادة هيكلة المُحسِّن المقترحة (# 1702 ، # 2214) ، وربما تجعل combineReducers أكثر مرونة (# 1768 ، # 1792 ، إلخ. ).

لقد مر ما يقرب من عامين منذ إنشاء Redux ، ولدينا الآن فكرة جيدة عن كيفية استخدام الأشخاص لها. كمثال واحد ، جمعت jimbolla قائمة بجميع معززات المتاجر المعروفة في # 2214 ، وصنفت كيفية عملها وما تستخدم من أجله. ما زلت معجبًا كبيرًا بالبساطة والمرونة في Redux ، لكني أرغب في رؤية بعض التجريدات التي لا تزال اصطلاحية فوق Redux والتي من شأنها تبسيط الاستخدام العام وحل المشكلات للأشخاص.

مجموعة أخرى من الموضوعات شبه ذات الصلة ، والشيء الذي لدي اهتمام شخصي مميز به ، هو أفكار "المنطق / المكونات المغلفة" (لكل "الواجهة الأمامية القابلة للتطوير مع Elm / Redux" الخاصة بـslorber ) ، و "المكونات - وتشغيل إعداد Redux "(كما هو موضح في التجارب مثل https://github.com/brianneisler/duxtape/issues/1 ، https://github.com/jcoreio/redux-features/issues/7 ، إلخ). يعد إعداد الحالة العامة والتطبيق رائعًا لبعض حالات الاستخدام ، ولكن ليس كثيرًا بالنسبة للآخرين.

كنقطة مثيرة للاهتمام ذات صلة ، قام toranb ببعض الأعمال الرائعة في إنشاء غلاف Ember لـ Redux على https://github.com/ember-redux/ember-redux . عالم Ember _ حقًا _ في "اصطلاح فوق التكوين" ، ولذا فإن ember-redux يُنشئ تهيئة متجرًا افتراضية معقولة ، بما في ذلك redux-thunk وما شابه. قد يكون من المفيد اتباع نهج كهذا.

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

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

ومع ذلك ، يمكنك بناء تخصصات فوق واجهات برمجة التطبيقات العامة. على سبيل المثال ، أستخدم https://github.com/acdlite/redux-actions الذي يقلل من الصيغة المعيارية للحالات الشائعة. ما زلت أستخدم القوة الكاملة لإعادة التشغيل وببساطة لن يكون امتلاك هذه الواجهة كافياً لاحتياجاتي.

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

https://egghead.io/courses/getting-started-with-redux
https://egghead.io/series/building-react-applications-with-idiomatic-redux

المرجع: طيف التجريد: https://www.youtube.com/watch؟v=mVVNJKv9esE

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

Imho يجب أن تكون هناك آلية مضمنة (وسيطة رد الاتصال subscribe ؟) لمراقبة تدفق الإجراءات المرسلة (أعلم أنه يمكن إجراؤها في برمجية وسيطة ، لكن هذا تقييد تمامًا حالة الاستخدام ، حيث لا يمكن استخدامها في الخارج ، أي حسب المكونات أو connect )

غالبًا ما أقوم بتدريس إعادة القراءة للآخرين وقد يكون الأمر شاقًا للغاية للأسباب التالية

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

أعتقد أن redux هي مكتبة رائعة لها معنى كامل في حد ذاتها وأعتقد أنها تحتوي على تجريدات رائعة وقابلة للتطوير بشكل كبير عند استخدامها بشكل صحيح. أقدر أيضًا أنه يمكن استخدام redux مع أي مكتبة UI ولكن أعتقد أنه في معظم الحالات سيتم استخدامه مع رد الفعل.

بشكل عام ، أعتقد أن الكثير من الإحباط يأتي من العديد من الأجزاء المتحركة.

إليك بعض الأفكار التي كانت لدي. كل ذلك يمكن بناؤه فوق الإعادة حتى يظل كما هو.

• قم بتوفير مكتبة مثل رد الفعل الذي يأتي أيضًا مع دعم للإجراءات غير المتزامنة المضمنة.
• تتحدث الكثير من الإجراءات غير المتزامنة إلى واجهة برمجة تطبيقات REST ، لذا قم بتوفير برمجية وسيطة اصطلاحية لذلك
• اكتب المكونات الذكية كمكونات فعلية بدلاً من استخدام الاتصال. يمكنهم بعد ذلك تقديم مكونات غبية في طريقة render الخاصة بهم
• قم بوصف تخطيط ملف قابل للتطوير لـ _مكونات الحاوية _ و _ المكونات الذكية _ و _ المكونات البسيطة _ و _ منشئي الإجراء _ و _ المخفضات _.
• قم بتوفير _redux-cli_ لإنشاء كود مثل redux action loadUsers
• التوحيد القياسي على طبقة غير متزامنة مثل redux-saga أو redux-note التي يمكن ملاحظتها وتضمينها في المستندات (سيكون من الجيد أن يكون لديك مكان واحد للتشاور بشأن معظم مسائل الإعادة)
• افتراضيًا لميزات اللغة الموسعة (مثل الزخارف (connect)) أو TypeScript لتقليل الإسهاب في خريطة معينة

تي

متفق عليه ، redux-actions هو مثال جيد لبعض الأفكار التجريدية البسيطة التي تزيل الصيغة المعيارية.

اسمح لي أن أسأل هذا: يحتوي تطبيق Create-React-App على الحزمة react-scripts ، والتي تحتوي على تكوينات Babel و Webpack سابقة الإنشاء ، وتأتي مع مجموعة من الإعدادات الافتراضية المعقولة المضمنة. كيف يمكن أن تبدو حزمة redux-scripts المقابلة؟

أتفق مع بعض التعليقات الأخرى (السلبية) حول redux-thunk . لا أوصي به للمبتدئين (ربما لن أوصي به على الإطلاق):

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

لقد استخدمناه بكثافة في تطبيق React-Native ، وكان مفيدًا في الغالب ، ولكن واجهنا مشكلة في تكوين الإجراءات معًا (فكر في "تحميل الملف الشخصي بعد تسجيل الدخول الناجح") ، نظرًا لأن منشئو الإجراء redux-thunk يعيدون فعليًا void (أي عدم وجود شيء مثل الوعد باستخدامه لتسلسل الإجراء التالي).

تميل إلى تشجيع الناس على التفكير بأن "الطريقة الوحيدة لفعل أي شيء هي الحصول على dispatch فورًا من معالج حدث React / رد الاتصال". ونظرًا لأننا كنا نستخدم connect من react-redux ونعتمد بشدة على mapDispatchToProps ، فإننا نميل إلى نسيان أن معالجات الأحداث لدينا يمكن أن تكون مجرد وظائف بسيطة.

(لاحظ أن التطبيق أعلاه تمت كتابته في الغالب في أوائل العام الماضي ، ولم نواكب ما كان يحدث في النظام البيئي Redux الأكبر ، لذا فقد يكون قديمًا).

bodhi : بدون الخروج على الكثير من الظل ، سأختلف مع بعض هذه الاستنتاجات. redux-thunk يبلغ طوله 11 سطرًا ، وهناك بعض التفسيرات الرائعة مثل "ما هو Thunk؟" . Thunks _are_ قابل للتكوين إلى حد ما ، وأعتقد أنه من الأسهل عمومًا إخبار شخص ما "كتابة هذين السطرين من إعلانات الوظائف ، ثم إجراء مكالمات AJAX الخاصة بك وما شابه هنا". لدي منشور يناقش بعض المفاضلات المختلفة من thunks (وإلى حد ما sagas) في Idiomatic Redux: أفكار حول Thunks و Sagas و Abstraction و Reusability .

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

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

بودي: ربما يكون خارج الموضوع قليلاً ، لكن فكرت فقط أنه من الجدير بالذكر أن الإرسال لا يعيد الفراغ ، إنه يعيد نتيجة وظيفتك الداخلية. لذلك ، إذا وعدت على سبيل المثال بوعد ، يمكنك بسهولة تجميع الإجراءات معًا. انظر قسم التكوين في الملف التمهيدي:
https://github.com/gaearon/redux-thunk/blob/master/README.md

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

في 19 آذار (مارس) 2017 ، الساعة 23:48 ، كتب Bodhi [email protected] :

أتفق مع بعض التعليقات الأخرى (السلبية) حول redux-thunk. لا أوصي به للمبتدئين (ربما لن أوصي به على الإطلاق):

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

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

(لاحظ أن التطبيق أعلاه تمت كتابته في الغالب في أوائل العام الماضي ، ولم نواكب ما كان يحدث في النظام البيئي Redux الأكبر ، لذا فقد يكون قديمًا).

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بكتم صوت الموضوع.

(آسف لمواصلة الظل ، ولكن ...)

من الجدير بالذكر أن الإرسال لا يعيد الفراغ ، بل يعيد نتيجة وظيفتك الداخلية.

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

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

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

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

يؤدي هذا أيضًا إلى إزالة أي حالة لإرسال إجراءات متعددة بشكل متزامن.

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

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

هذا النهج القائم على السحب يجعل تدفق البيانات في اتجاه واحد حقًا ويتراكم بشكل طبيعي مع مكتبات إدارة الآثار الجانبية مثل redux-saga أو redux-observable .

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

blocka هناك دائمًا بعض الأحداث التي تؤدي إلى طلب الشبكة. يمكن تغليف الطلب نفسه في إجراءات FETCH_USER_STARTED و FETCH_USER_DONE / FETCH_USER_FAILED ، وهي الطريقة التي تنتهي بها نتيجة الطلب في الحالة.

👍 مقابل redux-actions

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

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

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

نفس الشيء مع إعادة. إذا كنت على ما يرام أنك بحاجة إلى إجراء FETCH_X_STARTED ، ومنشئ عمل fetchX() ، ومخفض للتعامل مع ذلك ، وما إلى ذلك ، فلا تتردد في عمل تجريدك الخاص!

إن Blaiming redux for boilerplate يشبه نسخ ولصق كل التعليمات البرمجية الخاصة بك ، ثم إلقاء اللوم على جافا سكريبت لامتلاكها الكثير من النصوص البرمجية.

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

لا يعد استخدام redux-thunk للتعليمة البرمجية المتزامنة فكرة رائعة ويجب ذكرها في المستندات.
إذا قمت بتكوين العديد من الوظائف معًا ، فأنت لست متأكدًا من أن تدفق الإرسال لا يعتمد على الطلب ، لذا يصعب التفكير والاختبار.

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

أوصي بنشر هذه المدونة للحصول على فهم أفضل: http://blog.isquaredsoftware.com/2017/01/idiomatic-redux- Thinkts-on-thunks-sagas-abstraction-and-reusability/

Machiaweliczny شكرا على المقال. أعتقد أن السؤال بالنسبة لي يتعلق أكثر بالمكان الذي ينتهي بك الأمر فيه إلى وضع منطق عملك (كما تمت مناقشته في https://medium.com/@jeffbski/where -do-i-put-my-business-logic-in-a- رد فعل-redux-application-9253ef91ce1 # .3ce3hk7y0). أنت لا تقول أن تدفق الإرسال الخاص بك (thunk ، epic ، saga ، أيًا كان) ، يجب ألا يكون له حق الوصول إلى حالة التطبيق الحالية ، أليس كذلك؟

تضمين التغريدة

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

المخفض ، الذي يكون (state, action) => state هو المكان الذي يجب أن يكون فيه "المنطق الذي يعتمد على الحالة" بشكل عام. وبالتأكيد ، في أشياء مثل Elm Architecture ، كل هذا المنطق موجود في وظيفة "التحديث" (المكافئة لمخفضنا).

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

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

Machiaweliczny : بصفتي مؤلف

مزيد من المناقشة الجيدة ، لكننا بدأنا في الابتعاد قليلاً عن الموضوع. (هل هذا دراجة نارية أراها هناك؟ :))

دعني أعود إلى الأسئلة الأصلية:

• كيف سيبدو استخدام Redux الاصطلاحي مع "لغة معيارية أقل"؟ كيف يمكننا تقديم حلول لتلك الشكاوى؟
• ما هي التجريدات الممكنة التي يمكن إنشاؤها والتي تبسط عملية التعلم والاستخدام ، ولكن دون إخفاء Redux فعليًا (ونأمل أن توفر مسارًا للانتقال / التعلم إلى "القاعدة" Redux)؟
• ما المقدار الذي يمكن حله من خلال المستندات المحسّنة بطريقة ما؟

ما هي الخطوات الملموسة التي يمكننا تنفيذها لمعالجة هذه؟

في عالم الخطوات غير المثيرة للجدل والقابلة للتنفيذ والقصيرة المدى ، أود أن أقول:

1) اجعل المتجر أسهل في التهيئة (ربما من خلال التكوين الافتراضي؟ لا أعرف ما إذا كانت هذه هي الحالة ، لكن Elm اعتاد أن يكون لديه نوع "تطبيق مبتدئ" ونوع تطبيق عادي. تم استخدام التطبيق المبدئي للتطبيقات البسيطة والمواد التدريبية لتغطية 90٪ حالة عندما يتعلم الناس فقط. حتى يومنا هذا ، سأعترف أنه لا يمكنني تكوين متجر Redux باستخدام البرامج الوسيطة الأساسية (أدوات التطوير ، ثانك) دون البحث عن المستند للحصول على التوقيعات. لا أعتقد أن الكثير من الناس قد يجادلون بأن الوافدين الجدد بحاجة إلى معرفة كيفية تكوين البرامج الوسيطة لمتجر لتعلم مفاهيم Redux الأساسية.

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

أعتقد أن هذا سيقودنا بعيدًا جدًا.

تحرير: من خلال تطبيق المبتدئين ، لا أعني تطبيق Boilerplate ، بل أعني "createStore" لا يمكن تهيئتها ولكن بها إعدادات افتراضية معقولة يمكن للأشخاص استيرادها والانتهاء منها. ثم يمكنهم فقط الانتقال إلى createStore "الحقيقي" عندما يكبرون عنها.

هذا يبدو وكأنه مفهوم رائع حقًا.

يوم الإثنين 20 مارس 2017 الساعة 10:02 صباحًا Francois Ward [email protected]
كتب:

في عالم الخطوات غير المثيرة للجدل والقابلة للتنفيذ والقصيرة المدى ، أود أن أقول:

1.

اجعل المتجر أسهل في التهيئة (ربما باستخدام ملف افتراضي
إعدادات؟ لا أعرف ما إذا كان هذا لا يزال هو الحال ، لكن إلم كان يفعل ذلك
نوع "تطبيق مبتدئ" ونوع عادي للتطبيق. تم استخدام تطبيق المبتدئين من أجل
تطبيقات بسيطة ومواد تدريبية لتغطية 90٪ حالة الأشخاص
مجرد تعلم. حتى يومنا هذا ، سأعترف أنه لا يمكنني تكوين متجر Redux
مع البرامج الوسيطة الأساسية (devtools ، thunks) دون البحث عن المستند
التوقيعات. لا أعتقد أن الكثير من الناس قد يجادلون بأن الوافدين الجدد يحتاجون
لمعرفة كيفية تكوين البرامج الوسيطة لمتجر لتعلم جوهر Redux
المفاهيم.
2.

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

أعتقد أن هذا سيقودنا بعيدًا جدًا.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/reactjs/redux/issues/2295#issuecomment-287806663 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AFUmCQYkUwjkCugevDBWC8TOu0HhWJTnks5rnqMWgaJpZM4MhnVF
.

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

const { makeIndicator, makePayloadAssignor } from '../shared/reducers';

const searchModule = combineReducers({
  searching: makeIndicator(c.SEARCH),
  results: makePayloadAssignor(c.SEARCH_RESPONSE, [])
});

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

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

إعادة هو مجرد جافا سكريبت. لا يوجد شيء سحري في ذلك.

يوم الإثنين ، 20 آذار (مارس) 2017 ، الساعة 12:44 ظهرًا ، Markus Coetzee [email protected]
كتب:

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

const {makeIndicator، makePayloadAssignor} من '../shared/reducers'؛
const searchModule = includeReducers ({
البحث: makeIndicator (c.SEARCH) ،
النتائج: makePayloadAssignor (c.SEARCH_RESPONSE، [])
}) ؛

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/reactjs/redux/issues/2295#issuecomment-287820595 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AACourLpL5--NJiRzrWmKFJ31cl5DXJrks5rnqzxgaJpZM4MhnVF
.

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

هذا موضوع قيم للغاية في Redux كمكتبة.

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

رائع ، @ blocka! أعتقد أن هذه الرسالة يجب أن تنتشر.

الإحياء هو شعور غير معتاد ونمط معياري للناس بسبب أسلوبه البسيط. يعتبر Minimal أمرًا غريبًا بالنسبة إلى "إطار العمل" بشكل عام (الحد الأدنى من التعليمات البرمجية ، والمبادئ الدنيا).

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

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

كتبت مقالًا قصيرًا حول هذا الموضوع بالأمس: لا تلومه على React أو Redux . بالطبع يمكن أن أكون مخطئا في كل هذا.

توجد سابقة لوجود طبقات تجريد أعلى مكتبة متقدمة. في الآونة الأخيرة ، جلبت Tensorflow Keras كتجريد فوق واجهة برمجة التطبيقات الأساسية: http://www.fast.ai/2017/01/03/keras/.

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

أشعر أن هذه تجربة مماثلة لمعظم أجهزة ضبط الوقت لأول مرة في Redux. استبدل Tensorflow بـ Redux و Keras بـ Jumpstate . يعد Redux قويًا جدًا ، ولكن ربما لا يحتاج غالبية المستخدمين إلى كل عناصر التحكم المتاحة. على الأرجح ، هم قادمون من Angular أو يتم تعليمهم React + Redux في معسكر تدريب أو من مشاهدة برامج تعليمية مختلفة. في حين أن Redux لا يحتاج إلى التخفيف للمستخدمين الجدد ، فإنه ليس أيضًا مضادًا للنمط لتوفير تجريد أسهل يمكن أن يغطي على الأرجح 80٪ من حالات الاستخدام المحتملة.

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

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

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

هل تحتاج حرفيًا إلى استخدام كل هذه الحزم الأخرى لاستخدام redux؟ لا.
هل سينتهي معظم مستخدمي redux باستخدام بعض أو كل هذه الحزم الإضافية؟ نعم فعلا.

هل عدد الحزم في package.json مهم؟ لا ليس بالفعل كذلك.
هل يؤثر عدد الحزم في package.json على شعور الناس؟ على الاطلاق.

الآن ، أعتقد أنه من العدل أن نصدق أن الإعادة نفسها يجب أن تظل كما هي ، ويجب على حزمة أخرى ( create-redux-app أو أيًا كان) أن تتعامل مع تجميعها معًا. لكن لدينا مشكلة تعقيد حقيقية بين أيدينا ولا يكفي إخبار المستخدمين بـ RTFM.

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

على الاطلاق. لكن ليس كل الناس يشعرون بهذه الطريقة. البعض يفعل. ضع في اعتبارك أنك لن تسمع أبدًا أي أخبار عن أشخاص ليس لديهم مشاكل. أنت ترى فقط الأشخاص الذين يطرحون عليك أسئلة ، أو يضربون stackoverflow / reviflux. من بين أولئك الذين لا يفعلون ذلك أبدًا ، يحتاج البعض أيضًا إلى المساعدة ولكن لا يعرفون كيف يطلبونها ... والبعض الآخر بخير أيضًا ، ولا تريد أن تجعل الأمر أسوأ بالنسبة لهم ... وإلا فسوف يفعلون كن من يأتي إلى المنتديات بدلاً من ذلك وسيكون صافي الربح صفرًا.

لم تحصل Redux على شعبية بدون سبب. اعتقد الكثير من الناس أنه يشعر بالارتياح وأوصى به للآخرين :)

الآن ، أعتقد أنه من العدل الاعتقاد بأن الإعادة نفسها يجب أن تظل كما هي ، ويجب على حزمة أخرى (create-redux-app أو أي شيء) أن تتعامل مع تجميعها معًا.

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

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

لا أعتقد أن تضمين حزم مثل redux-thunk في Redux core هو السبيل للذهاب هنا بالرغم من ذلك.

من أجل الوضوح فقط ، فإن نوع الأفكار التي أطرحها لا تتعلق في الواقع بتضمين الأشياء مباشرة في الجوهر. إنهم يدورون حول إنشاء نوع من "التكوين المسبق" أو "طبقة التجريد سهلة الاستخدام" التي قد تكون حزمة منفصلة أو أداة CLI أو شيء من هذا القبيل ، على غرار create-react-app .

أعتقد أنه من الأفضل أن أجري رنينًا بصفتي مؤلف كتاب Jumpstate / Jumpsuit.

TL ؛ DR:
من الصعب تعلم Redux ويصعب تكوينه / تكامله لأنه منخفض المستوى. يمكن أن يستفيد المجتمع من واجهة برمجة تطبيقات معيارية عالية المستوى تهدف إلى حالة استخدام بنسبة 90 ٪ لتسهيل منحنى التعلم وحتى العمل كحل لمشروعات أبسط. تحاول Jumpstate حل هذه المشكلة ، لكنها ليست حلاً طويل الأمد. نحن بحاجة إلى البدء في اقتراح أفكار محتملة (حقيقية أو كود تعريف) حول كيفية ظهور واجهة برمجة التطبيقات هذه.

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

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

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

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

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

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

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

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

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

بعض الأفكار الأخرى التي تتبادر إلى الذهن لهذه المناقشة:

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

ما المقدار الذي يمكن حله من خلال المستندات المحسّنة بطريقة ما؟

كثيرا. عندما يتعلق الأمر بوثائق Redux ، أشعر إلى حد كبير بأنها أسوأ من مستندات AngularJS 1 لأنها مثل AngularJS ، فهي مطولة بلا داع ولكن على عكس AngularJS ، فإنها تفشل في مبدأ "إظهار ، لا تخبر".

تفضل مستندات Redux مقتطفات الشفرة بدلاً من العرض التوضيحي الفعلي للرمز مما يعني أن هناك الكثير من اللحظات "إليك مجموعة من التعليمات البرمجية ؛ لن نخبرك بكيفية اتصالها ولكن ثق بنا أنها تعمل". يعني الافتقار إلى القدرة على تشغيل أمثلة داخل المتصفح أن المستخدم مجبر على الوثوق بحدسه بأن ما يفعله محليًا يعمل ، وإذا لم ينجح شيء ما ، فسيتم إيقافه بمفرده. حتى تطبيق Todo List البسيط الذي أشعر أنه ليس أفضل مثال على "hello world" لـ Redux - يمكن جعله أبسط بكثير.

سوف تساعد الرسوم البيانية هنا بالتأكيد. على سبيل المثال ، أنا أحب sunjay ، قد يكون من الأفضل تصميم واحد لمثال Todo List نفسه - كيف يتم توصيل الملفات ، وما إلى ذلك من عرض عالي المستوى. تكون الصور دائمًا أفضل لنقل نص طويل ويمكن أن تساعد في تقليل الإسهاب في المستندات. ستساعد الصور أيضًا المبتدئين في الحفاظ على تركيزهم وفهم Redux ككل بشكل أفضل.

سنتي: من فضلك لا تغير الأساسية. تألقها في بساطتها. في هذه المرحلة ، من المحتمل أن تؤدي إضافة شيء ما إلى استبعاد الكل.

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

يمكن أن يقف من تلقاء نفسه ، فلنكن ❤️

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

HenrikJoreteg ، لا تخف! أنا على يقين من أن لا شيء نناقشه هنا سيغير الجوهر. جوهر هو ميزة كاملة ويقف من تلقاء نفسه. :)

كثيرا. عندما يتعلق الأمر بوثائق Redux ، أشعر إلى حد كبير بأنها أسوأ من مستندات AngularJS 1 لأنها مثل AngularJS ، فهي مطولة بلا داع ولكن على عكس AngularJS ، فإنها تفشل في مبدأ "إظهار ، لا تخبر".

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

هناك شيء يمكن أن يقال عن "الأقل هو الأكثر"

@ Phhoenixmatrix ، Sylphony : إذن ، كيف سيبدو تجديد المستندات المحتمل؟

شخصيًا ، لدمجها مع اقتراحاتي أعلاه حول امتلاك "متجر مبتدئ" ، قمت بتقسيمه إلى قسمين (ليس موقعين / وثيقتين مختلفتين ، ولكن قسمين مختلفين).

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

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

تعد المستندات الأفضل دائمًا فكرة رائعة ، لكنني لا أعتقد أن هذا يحل المشكلة الأساسية هنا. تتم كتابة مكتبات التجريد واعتمادها بسبب الصيغة المعيارية والإسهاب في Redux api. تعمل هذه المكتبات نفسها على تفتيت مجتمع Redux لأنه من الواضح أن هناك حاجة إليها على مستوى أو آخر. إنه لأمر محبط أن نفس المؤلفين الذين يحاولون بنشاط المساهمة في النظام الإيكولوجي يتم إهمالهم ورفضهم علنًا لأنهم "لا يفهمون Redux". إذا كان بإمكان المجتمع بدلاً من ذلك إنشاء تجريد أبسط ، ليس جزءًا من قلب React ، ولكن "مبارك" إلى حد ما ، فحينئذٍ سيفوز الجميع. يستمر مستخدمو Hardcore في استخدام Redux كما هو ، ويمكن للآخرين استخدام فكرة مجردة مع واجهة برمجة تطبيقات أسهل / أقل مطولة.

derekperkins كيف نصل إلى إجماع حول مكتبة "مباركة"؟ كيف نقرر ما يدخل فيه ومن سيعمل عليه؟

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

xkcd ذات الصلة: https://xkcd.com/927/

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

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

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

الفكرة هنا ليست تجميع مجموعة أدوات تحل جميع المشاكل لجميع الناس. باستخدام CRA كمثال: هناك العديد من الطرق لتهيئة Babel و Webpack و ESLint. ما تقوم به CRA هو تقديم طريقة واحدة عنيدة لجعلهم جميعًا يعملون دون أي متاعب من جانب المستخدم ، ويختار عن عمد عددًا من الإعدادات التي تجعل الأمور أفضل للمتعلمين. ثم يسمح للمستخدم بالتحكم في التكوين إذا أراد ذلك.

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

هذه طريقة رائعة لوضعها. شيء لتنهض وتعمل بسرعة
يتضمن فقط تثبيت redux وطبقة التكوين الافتراضية هذه؟ الذي - التي
سيكون رائعا.

فكرة أخرى كانت لدي هي علم يمكنك تعيينه في وضع التطوير الذي يمكن
مشاهدة وكشف فرص التعلم الإضافية للمستخدم. في
بهذه الطريقة يمكن أن تكون طبقة التجريد بمثابة أداة تعليمية تفاعلية.
يوم الإثنين 20 مارس 2017 الساعة 4:14 مساءً Mark Erikson [email protected]
كتب:

الفكرة هنا ليست تجميع مجموعة أدوات تحل جميع المشاكل
لجميع الناس. باستخدام CRA كمثال: هناك العديد من الطرق للتهيئة
Babel و Webpack و ESLint. ما تفعله CRA هو تقديم واحدة ، عاقدة العزم
طريقة لجعلهم جميعًا يعملون دون أي متاعب من جانب المستخدم ، وذلك
يختار عمدًا عددًا من الإعدادات التي تجعل الأمور أفضل
المتعلمين. ثم يسمح للمستخدم بالتحكم في التكوين إذايريدون ذلك .

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

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/reactjs/redux/issues/2295#issuecomment-287914805 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AFUmCactFzsw7etmGGP8MFK6kfNaOzTJks5rnvorgaJpZM4MhnVF
.

sunjay كنت أعرف ما هو رابط xkcd الذي كان دون الحاجة إلى النقر فوق. :)

أنا أتفق معmarkerikson. هذه ليست محاولة للتعامل مع كل حالة متطرفة لكل شخص. إنه تصريح عنيد من مطوري Redux الأساسيين يقول ، "هذه طريقة جيدة لجعل الأمور تعمل". هناك افتراضات عقلانية يمكن تجاوزها إذا لزم الأمر ، لكنني أراهن على أن الإعدادات الافتراضية ستعمل مع 80٪ من المطورين.

قد يكون أو لا يكون مكتوبًا على core Redux. ما زلت أعتقد أن هناك مكانًا لشيء مثل Jumpstate يقوم بأكثر من تسريع منحنى التعلم.

يمكن أن يكون منحنى التعلم Redux حادًا ، ولكن بمجرد فهم المفاهيم ، غالبًا ما تختفي الحاجة إلى طبقات التجريد

أعتقد أن هذا صحيح إلى حد ما ، لكن لا يعني بالضرورة أنك تريد دائمًا إزالة طبقة التجريد. على الرغم من أنني كتبت لغة C في الماضي وأفهمت تخصيص الذاكرة ، إلا أنني أفضل الكتابة في Go حيث يتم التعامل مع جمع البيانات المهملة من أجلي. وفقًا لمثال Tensorflow الخاص بي سابقًا ، سيكون من الأفضل الكتابة إلى المستوى الأدنى من Apis ، ولكن هناك أيضًا الكثير مما يمكن قوله لسهولة استخدام تجريد Python keras. وبالمثل ، بالنسبة إلى Redux vs Jumpstate (أو أيًا كان التجريد الناتج عن هذه المشكلة) ، فليس من الصعب بالضرورة كتابة الصيغة المعيارية ، إنها مرهقة فقط لمعظم حالات الاستخدام التي لا تحتاج إلى كل مرونة Redux الخام.

إذا كان الأمر متروكًا لي ، فأنا أرغب في رؤية هذا:

• مجموعة فرعية ملائمة Flow / TypeScript يسهل كتابتها أكثر من Vanilla Redux.
• عدم التأكيد على الثوابت كثيرًا (فقط اجعل استخدام حرفية السلسلة أكثر أمانًا).
• الحفاظ على الاستقلال عن React أو مكتبات العرض الأخرى مع تسهيل استخدام الارتباطات الحالية (على سبيل المثال ، تقديم mapStateToProps التنفيذ).
• الحفاظ على مبادئ Redux (الإجراءات القابلة للتسلسل ، والسفر عبر الزمن ، وإعادة التحميل السريع يجب أن تعمل ، ويجب أن يكون سجل الإجراءات منطقيًا).
• دعم تقسيم الكود بطريقة أكثر وضوحًا خارج الصندوق.
• تشجيع التوزيع المشترك للمخفضات مع المحددات ، وجعلها أقل صعوبة في الكتابة معًا (فكر في حزم المخفض - المحدد التي يسهل كتابتها وتكوينها).
• بدلًا من الاستعانة بمنشئي الإجراءات مع المخفضات ، تخلص من صانعي الأحداث تمامًا ، واجعل تعيين العديد من الإجراءات لمخفّضاتها أمرًا طبيعيًا (بدلاً من الابتعاد عنها كما تفعل معظم المكتبات).
• عمل إعدادات افتراضية معقولة للأداء بحيث يتم الحفظ عبر إعادة تحديد "يعمل فقط" لحالات الاستخدام الشائعة دون أن يكتب المستخدمون هذا الرمز.
• تحتوي على مساعدين مدمجين للفهرسة والتطبيع والمجموعات والتحديثات المتفائلة.
• وجود دعم تدفق غير متزامن مدمج قابل للاختبار.

علاوة على ذلك ، بالطبع ، على الرغم من أنه من الجيد تصنيفها على أنها ميزة Redux رسمية.
أيضًا ، لن أكتب هذا. ولكن يمكنك.

بالنسبة لي ، قبل بضعة أشهر عندما تعلمت redux ، قرأت المستند ولكني لم أفهم جيدًا ، لذلك أمضيت يومين لقراءة كود src ، ثم كل وصف عن api من يصبح المستند واضحًا .

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

لذلك ، أعتقد أن قراءة كود src هو الخطوة المناسبة لتعلم redux ، وبعد ذلك فقط ، يمكنك فهم واستكشاف بيئة redux أكثر سلاسة.

دعم غير متزامن بشكل افتراضي.

أعني أنه لا داعي لاستخدام مكون إضافي آخر مثل redux-thunk, redux-saga .

دعم غير متزامن بشكل افتراضي

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

تعليق gaearon مثالي ، من حيث أنه يسلط الضوء على مدى

أنا في الواقع أجد ذلك رائعا.

مكتبة Redux التجريدية الخاصة بي تفعل العكس تمامًا تقريبًا. أجد قيمة هائلة في إجراءات المخفض الأحادي ، في تجميع وظائف المخفض الذري مع أكواد العمل الخاصة بهم ومحدداتهم ، في قتل السلاسل بالكامل لصالح مفاتيح الكائنات. إنه الحل الخاص بي بنسبة 90٪ ، وهو أكثر شبهاً بـ CRA في الموقف من أي شيء آخر.

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

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

ما هي المشاكل التي نحاول حلها؟

الحالة العالمية للتطبيق. R eliable وE sthetics D elivered U nified ه X tensible: القلب:

لا أحد يريد الكرات الأرضية. لكن كل شخص يحتاج إلى واحد: tm:

من فضلك ، حافظ على إعادة بسيطة كما هي الآن. إنه نمط. ستظهر كتب الطبخ دائمًا حول: 100:

markerikson هل ستكون فكرة جيدة أن تبدأ مستندًا / جدول بيانات لتنظيم هذه الأفكار؟ كانت هناك بالفعل بعض الأفكار المذهلة وقد مرت 48 ساعة فقط

بالنسبة لي ، أنا لا أوصي الناس باستخدام thunks أو sagas. بدلاً من ذلك ، تعلم تقنيات حقن التبعية في JavaScript.

تصبح عملية Redux أسهل بمجرد معاملتها كقاعدة بيانات عادية:

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

بالنسبة لي ، هذا كل ما يخص Redux (لا أتوقع أن تقوم قاعدة بيانات بإجراء مكالمة HTTP). بالنسبة للإدخال / الإخراج والأشياء غير المتزامنة ، أقوم بتنفيذها خارج Redux. هذا يجعل متجر Redux الخاص بي متوقعا. توقيع النوع دائمًا هو store.dispatch(actionObject) . لا توجد وظائف إرسال ولا معنى مخفي داخل الإجراء (على سبيل المثال ، لن يؤدي إرسال إجراء إلى إجراء استدعاء لواجهة برمجة التطبيقات).

tannerlinsley : نعم ، اذهب لذلك.

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

أريد بكل تأكيد أن أشارك في هذه الجهود الممكنة ، لكني سأحتاج إلى مشاركة الآخرين والعمل معًا. (الكلمات الأخيرة الشهيرة لكل مشرف صيانة OSS ... :))

يصبح Redux أسهل بمجرد معاملته كقاعدة بيانات عادية

هذا ما أوصي به!

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

FWIW ، لقد كنت أستخدم Redux مع D3.js (بدون مكون d3 .

أكثر ما أفتقده في ارتباطات React Redux هو connect . النقطة التي سأهتم بها أكثر من المخطط / الرؤية أعلاه من تطبيقات mapStateToProps ".

يمكنك تحضير البيانات - مثل طرق العرض. قم بذلك عن طريق مخفضات مخصصة - فلن تحتاج بعد ذلك إلى إعادة التحديد. انصح.

نعم ، هذا ما يفعله Twitter في متجره ، على الأقل أعتقد ذلك - لديهم فرع entities يحتوي على معرفات منتظمة لخرائط البيانات ، أي timeline view وهو في الأساس الخلاصة الرئيسية لك انظر أيها يحمل المراجع المعرفية لفرع الكيانات ولكن سبق احتسابه بالفعل.

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

stefensuhat عندما حاولت تنفيذ Redux بنفسي ، استخدمت حلقة الوعد لجعل الإجراءات غير المتزامنة ممكنة. يمكنك التحقق من ذلك على https://github.com/iddan/delux

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

أود بالتأكيد المساهمة في هذه الفكرة الجيدة!

تضمين التغريدة

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

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

يقع عبء تحويل هذه الاقتراحات إلى واقع على عاتقنا جميعًا المهتمين بكل ميزة أو نهج جديد. على الرغم من أن مارك بدأ المناقشة ، فأنا متأكد من أن لا أحد يتوقع منه أن يذهب وينفذ كل شيء. :)

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

مع ذلك ، عندما / إذا حاول شخص ما مهاجمة تلك القائمة بأكملها ، ضع في اعتبارك أيضًا الأدوات والأطر الأخرى الموجودة خارج Redux ، وحتى خارج React. يحتوي React / Redux على مجموعات مثيرة للاهتمام من الفوائد على Vanilla Flux ، و MobX ، و VueJS ونظامه البيئي ، على Angular. مهما كان ما يفعله المجتمع ، فمن المحتمل أنه يريد التركيز على بعض هذه الفوائد (بعضها جزء من قائمة gaearon ) ، والتأكد من أن أي طبقة تم إنشاؤها في الأعلى لن تصبح زائدة عن الحاجة تمامًا. تتوفر الكثير من الأشياء مثل تصحيح أخطاء السفر عبر الزمن والأنظمة البيئية للبرامج الوسيطة وما إلى ذلك في مكان آخر.

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

Phoenixmatrix ، نعم ما أعنيه هو أن redux بها

لا أرى أي خطأ في التنفيذ الحالي لـ Redux. توجد Boilerplate ولكنها في الحقيقة ليست مشكلة كبيرة إذا كان لديك نظام كتابة.

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

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

عندما تم إنشاء Redux ، حاول الكثير من الأشخاص ( بمن فيهم أنا) بناء هذا الشيء ، وحصل

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

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

ما الذي نبنيه بالضبط عندما نبني تطبيق الواجهة الأمامية؟

• نبني عضوًا في نظام موزع
• هذا العضو يحمل فقط مجموعة فرعية من بيانات النظام الأكثر عمومية
• يتمتع هذا العضو بقدرات محدودة للغاية (التخزين ، وعرض النطاق الترددي ، واستقرار الشبكة ...)

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

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

لسوء الحظ ، يريد الأشخاص تخطي الخطوات واستخدام Redux دون معرفة أي شيء عن الأنماط الأكثر عمومية المعنية.

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

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

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

الكثير من التعليقات الجيدة في كل مكان. هناك الكثير من الأفكار هنا يمكننا ويجب علينا استكشاف المزيد.

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

قم بإنشاء حزمة جديدة تسمى ، لا أعرف ، redux-starter أو شيء من هذا القبيل. قد تعتمد هذه الحزمة على redux-actions و redux-thunk و redux-logger وربما على برمجيات وسيطة قائمة على الوعد. سيوفر وظيفة بالتوقيع function createReduxStore({reducers, middleware}) {} (بناءً على تعليق Phoenixmatrix سابقًا ). قد لا يكلف نفسه عناء قبول البرمجيات الوسيطة؟

ستهتم الوظيفة createReduxStore() بمعالجة applyMiddleware وإعداد إعادة التحميل الساخنة لمخفض الجذر ، بالإضافة إلى تكوين امتداد Redux DevTools. إذا لم يتم توفير برمجيات وسيطة ، فسيتم تكوين البرامج المضمنة افتراضيًا. قد يبدو هذا مشابهًا لكود إعداد خدمة المتجر في ember-redux أو الوظيفة configureStore في نموذج التطبيق "Project Mini-Mek" الخاص بي .

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

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

يمكنك أيضًا استبدال combedReducer ، لذا يمكنك ببساطة القيام بما يلي:

const store = createStarterStore({
   foo,
   bar,
   baz
});

حيث foo bar baz هي مخفضات.

درات. أدركت للتو أن "وظيفة المكتبة التي تقوم بإعداد HMR لمخفض الجذر" ربما لن تعمل ، لأنه حتى لو سمحنا للمستخدم بالمرور في المسار إلى ملف مخفض الجذر الخاص به ، فإن أحدهما أو كلاهما من module.hot.accept() API وخطوة إعادة الاستيراد require(path) مسارات قابلة للتحليل بشكل ثابت في وقت الإنشاء وليست متغيرات. (أعتقد ... قد أكون مخطئا.) أوه ، حسنا.

لكن نعم ، يمكن أن يقبل createStarterStore() إما مخفض الجذر أو كائن الشرائح.

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

slorber أتفق معك في هذا الجزء.

لسوء الحظ ، يريد الأشخاص تخطي الخطوات واستخدام Redux دون معرفة أي شيء عن الأنماط الأكثر عمومية المعنية.

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

في المكان الذي أعمل فيه ، استخدمنا Redux لمدة عام الآن ، ووجدنا أنفسنا نقوم بنسخ / لصق نفس الكود (تعديله قليلاً فقط) لإضافة موارد جديدة إلى المتجر ، وهذا هو السبب في أننا شعرنا في وقت ما الحاجة إلى تنفيذ طبقة أعلى Redux ، لاستخلاص هذه النمذجة الزائدة عن الحاجة.
في رأيي ، هذه الفكرة لا تقوم فقط بتبسيط استخدام Redux ، ولكن أيضًا تقليل الصيغة المعيارية للأجزاء الأكثر شيوعًا (بنفس الطريقة ، يقلل react-redux من الصيغة المعيارية عند استخدام Redux جنبًا إلى جنب مع React).

مناقشة ممتعة للغاية. سنتي كمستخدم مسترجع منذ الأيام الأولى:

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

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

تحقيقًا لهذه الغاية ، ربما يمكن أن تصبح إعادة التشغيل الحالية حزمة مثل redux-core ، و redux نفسها ترفع مستوى التجريد لإعطاء طريقة موصى بها لبناء التطبيقات. بالطبع ، يمكن أن يكون هناك أي عدد من البدائل ذات المستوى الأعلى لهذا redux (مثل Apollo ، أو شيء يستخدم sagas؟) باستخدام redux-core ...

إعادة صياغة الأشياء للتوضيح والتأكيد:

لن يتضمن أي عمل من هذا الموضوع redux ستبقى كما هي.

أي شيء مثل الحزمة redux-starter التي وصفتها للتو ، أو نهج "Framework" الذي حدده دان ، سيكون حزمة جديدة تعتمد على redux .

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

يمكنك استخدام Delux كمبتدئ (jk)

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

طريقة طويلة متعرجة للقول: يبدو رائعًا ، أنا مشترك ، لست متأكدًا من مقدار المساهمة (سأحاول) ولكن لديك بالتأكيد قائد مشجع.

لقد استخدمت Jumpstate لتدريس Redux عدة مرات الآن ويمكنني أن أقول بثقة أنه قد اختصر منحنى التعلم بشكل كبير. أفكر في Redux مثل HTTP و Jumpstate مثل الجلب. أنا أحب Redux وقد كتبت بعض الأشياء المعقدة (بشكل يبعث على السخرية) ، لكنني أعلم أيضًا أن 90٪ حالة أكثر من كافية لتدريس معظم الأشياء.

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

رد: منحنى التعلم والرأي والتجريد:

يبدو أن Ajax منطقة يتعثر فيها المتعلمون الجدد ، سواء كانوا يتعلمون استخدام thunks أو sagas أو الملاحم. إحدى المناطق التي لا يبدو أنها تواجه صعوبة كبيرة هي إنشاء الإجراءات - لأنها مجرد كائنات جافا سكريبت قديمة بسيطة ، ولدينا الوضوح الإضافي الذي توفره مواصفات إجراءات Flux القياسية. قادني هذا الخط في التفكير إلى السؤال - لماذا لا أطور إجراء Ajax القياسي Flux ؟

على سبيل المثال

function fetchPosts(page) {
  return {
    type: 'FETCH_POSTS_REQUEST',
    // Ajax request setup
    ajax: {
      url: `/api/posts`,
      method: 'GET',
      data: { page },

      // Optional ajax meta attributes
      meta: {
        // Amount of time to debounce the execution of the request
        debounce: 400,
        // Amount of times to retry the request on failure
        retry: 2,
        // Amount of time before timing out
        timeout: 10000,  
        // The action type that cancels the request
        cancelType: 'CANCEL_FETCH_POSTS',
        // Strategy when multiple FETCH_POSTS_REQUESTs are in flight
        resolve: 'LATEST'
      }
    }
  };  
}

سيتم التعامل مع إجراء ajax بواسطة البرامج الوسيطة (والتي ستتفاعل مع المفتاح ajax في الإجراء).

كنت أحاول التفكير في الأسباب التي تجعل هذا النهج فكرة سيئة ، لكنني لم أفكر بعد في أي كسر للصفقات.
بعض الفوائد في تقديري:

• انخفاض كبير في مقدار الإجراءات غير المتزامنة المطلوبة في متوسط ​​التطبيق الخاص بك (حيث ستنهار الإجراءات غير المتزامنة المتعلقة بـ ajax)
• سهل الفهم لأننا نتعامل فقط مع كائنات جافا سكريبت عادية
• إنه إعلاني ، تفاصيل التنفيذ ليست مهمة
• يمكن تشغيل تطبيقات مختلفة للداخل / للخارج دون انقطاع
• إنها Redux اصطلاحية (سجل الإجراءات لا يزال منطقيًا ، قابل للتسلسل ، إلخ)

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

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

في الختام - يبدو من الممكن تمامًا أن يساعد مثل هذا التجريد في تسهيل منحنى التعلم ومقدار الكود اللازم لكتابة تطبيقات Redux الشائعة. هل لدى أي شخص أي أفكار حول هذا النهج - أي تعطل للصفقات يمكن أن يخطر ببالك؟ تضمين التغريدة

الفن السابق: redux-axios-middleware

الكثير من الاشياء تحدث في هذا الموضوع.

فيما يتعلق بالمناقشة حول تعقيد إعادة التشغيل. أنا شخصياً لا أتفق مع الناس الذين يشكون من تعقيد Redux وإسهابه. إنها مقايضة تقوم بها عند استخدام مكتبة منخفضة المستوى تعتمد على معماريات Flux & Elm. مذكور في صفحة Redux الرئيسية أنك قد لا تحتاجها. لكن لا يزال لدينا أشخاص يشكون من تعقيد الأمر.

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

أرى أن المشكلة ليست في مسترجع نفسها ولكن من عدم وجود تقدمية، والعمل التدريجي من المربع، وسيلة لمعرفة ذلك. كما ذكر البعض ، واجهت React نفس المشكلة وكان الحل هو create-react-app .

ربما لا تكون هذه هي المشكلة حتى نظرًا لوجود موارد رائعة لذلك (مثل سلسلة egghead من Dan). ربما يكون الأشخاص الذين يرغبون في استخدام مكتبة تحل المشكلات المعقدة دون أي منحنى تعليمي هو المشكلة.

على أي حال ، ليس هذا ما يدور حوله هذا الموضوع.

markerikson أنا شخصياً مستعد للمساعدة في تطوير هذا redux-starter .

_أحب اسمًا أكثر برودة على الرغم من _: عالق في الخارج _ اللسان:

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

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

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

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

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

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

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

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

إذا كان بإمكاني الحصول على شيء مثل Elm code تمت ترجمته إلى Redux الاصطلاحي ... فلا يزال قلبي النابض.

إليكم بعض أفكاري ، آمل ألا أكرر التعليقات السابقة:

يمكن استخدام منشئو الإجراءات كأنواع إجراءات

الإجراءات. js

export function increase() {}

المخفض. js

import { increase } from './actions.js';
export default handleActions({
    [increase]: (state) => state + 1
}, 0);

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

يمكن إرسال الإجراءات بشكل غير متزامن

async function a() {

}
async function b() {
}
store.dispatch(a());
store.dispatch(b()); // b() will be dispatched after a() resolves

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

إعادة === النمطي

https://github.com/Emilios1995/redux-create-module

لكني أعتقد أن هذه الوظيفة يمكن أن تنقذ حياتك تمامًا.

يجدر التمييز بين مجموعتين مختلفتين من الأفكار التي تحدث في هذا الموضوع:

• إطار عمل يستند إلى إعادة "خدمة كاملة"
• ميزات إضافية في redux core

أتفق مع markerikson على أن نواة

يحتوي Redux على مساحة سطح API صغيرة إلى حد ما: createStore ، applyMiddleware ، combineReducers ، bindActionCreators ، و compose . لكن معظم هذه وظائف ملائمة. فقط createStore ضروري لعمل Redux. لماذا ينتمي أي من هؤلاء إلى جوهر؟

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

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

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

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

• إذا كانت البرمجيات الوسيطة تبسيطًا لمُحسِّن المتجر ، فهل هناك تبسيطات أخرى يمكن أن تكون مفيدة على نطاق واسع؟
• ما هي الأشكال الأخرى لتكوين المخفض التي يمكن تنفيذها بدلاً من مجرد توثيقها؟ كائنات المخفض ؟ مخفضات تعتمد ؟ تكوين خطي ؟
• هل سيؤدي دمج إعادة التحديد إلى إنشاء وتكوين محددات حيث لم يفعلوا ذلك من قبل؟ هل سيكون هذا صافي إيجابي؟

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

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

• المنشور الرئيسي: ما هو الشيء العظيم في Redux؟
• نسخة مخزنة من سلسلة محادثات Twitter التي أدت إلى المنشور: https://storify.com/acemarke/redux-pros-cons-and-limitations
• بعض الأفكار الإضافية بعد ذلك: https://twitter.com/modernserf/status/886426115874717697

من المثير للاهتمام جدًا طرح هذه الأفكار ، نظرًا للتاريخ المتضمن (الذي قضيت وقتًا طويلاً في البحث عن رسالتي The Tao of Redux ، الجزء 1 - التنفيذ والنية . على وجه الخصوص ، redux-thunk كان تم إنشاؤه في الأصل مباشرةً في Redux ، ولم يتم فصل react-redux إلا لاحقًا أيضًا .

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

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

لكل أسئلتك الثلاثة الأخيرة:

• أعتقد أنه يمكنك القول أن البرامج الوسيطة هي "تبسيط لمعززات المتجر" ، على الرغم من أنني لا أعتقد أن هذا ينصفها. بدلاً من ذلك ، إنه مُحسِّن للمخزن لغرض متخصص للغاية. فيما يتعلق بالعمل المرتبط بمُحسِّن المتجر الآخر: قال دان إن الجزء الرئيسي الوحيد من قلب Redux الذي لا يزال يرغب في تعديله يتعلق بكيفية تهيئة المعززات. هناك في الواقع اثنان من العلاقات العامة "المتنافسة" لتغيير تطبيق مُحسِّن المتجر ظل مفتوحًا لفترة طويلة جدًا: إصدار acdlite في # 1706 ، ونسخةjimbolla في # 2214. من المثير للاهتمام أيضًا ملاحظة أن Jim وضع قائمة بجميع معززات المتاجر المعروفة للمساعدة في تحليل كيفية استخدام المجتمع لها بالفعل. أعلم أن اقتراح جيم كان يهدف إلى مساعدة المؤلفين المحسنين على تبسيط السلوكيات الشائعة. لذلك ، هذا هو الاتجاه الذي يمكن استكشافه بشكل أكبر.
• هناك بالتأكيد الكثير من الأنماط الأخرى لتكوين المخفض وهيكله هناك. لست متأكدًا تمامًا مما يمكننا فعله فيما يتعلق بالمخفضات "التابعة" ، نظرًا لأن هذه حالة استخدام أكثر تخصصًا ويبدو أنها خاصة بالتطبيق. في ملاحظة ذات صلة ، لفترة طويلة ، كان دان قد أغلق أي علاقات عامة تقترح إضافة نوع من الوسيط الثالث إلى combineReducers (وكان هناك عدد كبير منهم) ، لكنه سمح أخيرًا برقم 1768 للمضي قدمًا للحصول على في حين. هذا العلاقات العامة قد توقفت أيضا.
• يبدو أن حالة الاستخدام الأكثر شيوعًا للمحددات هي استخراج أجزاء من الحالة بشكل مباشر وتمريرها على أنها دعائم مسماة. لقد حصلنا أيضًا على علاقات عامة مفتوحة لـ React-Redux لإضافة صيغة مختصرة للكائن مقابل mapState ، ولدينا طلبات عديدة لذلك على الرغم من أنه يمكنك فعل الشيء نفسه مع Reselect's createStructuredSelector .

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

كما قال gaearon ذات مرة ، (لا أتذكر أين ... ربما Slack) نحن نهدف إلى أن نكون مثل مكتبات Koa of Flux. في نهاية المطاف ، بمجرد أن يصبح المجتمع أكثر نضجًا ، فإن الخطة هي الحفاظ على مجموعة من الإضافات والإضافات "المباركة" ، ربما تحت مؤسسة reduxjs GitHub.

في وقت سابق ، كنت قد اقترحت نوعًا من "إعداد إعادة التشغيل السهل" أو شيء من هذا القبيل. هل شيء من هذا القبيل ، أو على الأقل تلك القائمة من الإضافات "المباركة" ، ستكون كافية على غرار ما تفكر فيه؟ (وفي الواقع ، فعلت ذلك أيضًا في التعليق الأول من هذا الموضوع.) إذا لم يكن الأمر كذلك ، فهل هناك أي مقترحات أو أفكار إضافية؟

في نهاية المطاف ، بمجرد أن يصبح المجتمع أكثر نضجًا ، فإن الخطة هي الحفاظ على مجموعة من الإضافات والإضافات "المباركة" ، ربما تحت مؤسسة reduxjs GitHub.

هذا ما سأفعله أيضًا ، على الرغم من أنني سأخطو خطوة أخرى إلى الأمام: سأعيد هيكلة المشروع إلى monorepo ، حيث تصبح الحزمة الحالية redux شيئًا مثل @redux/core ، مبارك يتم إحضار مكتبات مثل reselect و redux-action إلى repo ومساحة الاسم ، وتقوم الحزمة redux نفسها بإعادة تصدير كل هذه الحزم في مساحة اسم واحدة.

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

لدينا أيضًا علاقات عامة مفتوحة لـ React-Redux لإضافة صيغة مختصرة للكائن لـ mapState ، ولدينا العديد من الطلبات لذلك على الرغم من أنه يمكنك فعل الشيء نفسه مع Reselect's createStructuredSelector .

أعتقد أن هذا يجب أن يخبرك بشيء.

هيكل monorepo الذي أقترحه هو في الأساس الهيكل الذي يستخدمه Lodash. الآن - تعتبر Lodash مكتبة مثيرة للاهتمام يمكن تصميمها على النحو التالي: إنها مجموعة هائلة من الوظائف ، العديد منها تافه لتنفيذها بنفسك. تقريبًا كل وظيفة في لوداش يمكن أن تكون أكثر مرونة باعتبارها "وصفة" - groupBy هو حقًا _نمط_ بعد كل شيء ؛ من نحن لنقول ما هي هياكل البيانات التي تستخدمها؟

كما تتوفر كل وظيفة لوداش في مكتبة _a la carte_ الخاصة بها. لا توجد فائدة _ وظيفية_ لـ import { groupBy } from "lodash" على import groupBy from "group-by" . لماذا يجب علي التعامل مع اهتزاز الأشجار بينما يمكنني فقط تثبيت ما أحتاجه؟

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

آمل ألا تمانع في إضافة سنتي الخاصة بي ، من منظور مختلف.

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

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

أظن أن Event Sourcing كنمط معماري سيكتسب شعبية على مدار العقد المقبل ، وأعتقد أن Redux يمكن أن يكتسب بعض قابلية الاستخدام والوضوح وسهولة الاستخدام من خلال مواءمة API والمناقشة بشكل أوثق مع المجتمع الأوسع.

أعتقد أن هذا النقاش قد تعرض للضرب حتى الموت: https://github.com/reactjs/redux/issues/351

أوه ، لم أكن على علم بذلك ، شكرًا! : +1:

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

يمكنني أن أكون أكثر صلابة.

إليكم فكرتي عن الشكل الذي قد تبدو عليه واجهة برمجة التطبيقات المستوحاة من مصطلحات " مصادر الأحداث" :

المفاهيم

• دفق حدث يمكن ملاحظته
• يحتوي Event Stream على مجموعة مكتوبة جيدًا من الأحداث المدعومة
• يتم إرسال الأوامر إلى حدث البث
• عميل واحد أو أكثر يستهلك تدفق الأحداث

API

import { createEventStream, createProjection } from 'redux';

// Initialize the event stream separately from the store.  This becomes the one
// true source of truth for your application.
const eventStream = createEventStream({
  // Commands are the only thing that we want to couple to the eventStream.  The 
  // set of events which may end up in an eventStream should be easy to predict.
  //
  // A definition like this supports static analysis inference well for 
  // consumers that can leverage it.
  increment: () => ({ type: 'INCREMENT' }),
  decrement: () => ({ type: 'DECREMENT' }),
});

// Multiple stores with disjoint or overlapping data can be used to consume the 
// same event stream.
const store = createProjection(eventStream, reducer, init);
const adminStore = createProjection(eventStream, adminReducer, init);

// We don't need a jargon term ("Middleware"), or a dedicated hook to handle 
// async anymore.  We just register more subscribers to the eventStream.
eventStream.subscribe(myCustomMiddleWare);
eventStream.subscribe(sendEventsToAnalytics);
eventStream.subscribe(logEventsForPlayback);

// Calls to commands can be wrapped with React Providers or container components 
// in the same way that Redux currently does.  They can also be called directly.
eventStream.increment();

ajhyndman : بينما أنا أقدر الاقتراح والمناقشة ، فقد تم رسم هذه الدراجة بالكامل وهرب الحصان من الحظيرة (لخلط الاستعارات تمامًا). اختار دان استخدام مصطلحات Flux بدلاً من مصطلحات CQRS / ES ، ولا توجد خطط لتغيير واجهات برمجة التطبيقات الأساسية أو المصطلحات المستخدمة لمفاهيم Redux.

(أيضًا ، بينما ليس لدي أي إحصائيات لإثبات ذلك ، أعتقد أنه في هذه المرحلة ، يوجد عدد أكبر من الأشخاص على دراية باستخدام Redux لـ "الإجراءات" و "صانعي الإجراءات" مقارنة بمصطلحات CQRS / ES ، على الأقل داخل مجتمع JS. )

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

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

ما زلت أجادل بأن هناك فرصة لمجتمعات Event Sourcing و Redux للتعلم من بعضهما البعض.

• ما هي التجريدات الممكنة التي يمكن إنشاؤها والتي تبسط عملية التعلم والاستخدام ، ولكن دون إخفاء Redux فعليًا (ونأمل أن توفر مسارًا للانتقال / التعلم إلى "القاعدة" Redux)؟

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

بالنظر إلى المستقبل ، أعتقد أنه من الممكن تمامًا تنفيذ وتجريد بنية أساسية للخادم تشبه الإعادة (انظر: الأعمال الأخرى من فريق LinkedIn الهندسي). إذا كنا نطمح إلى ذلك ، فيجب أن يكون من الممكن أيضًا استخدام تجريدات مماثلة لإدارة حالة العميل والخادم! إذا تمكنا من تحقيق ذلك ، فلماذا لا يكون متجر Redux متماثل الشكل ومستمر؟

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

أعتقد أنني أتحمس قليلاً لبعض هذه الأفكار! آمل أن تغفر لي كلمة تفريغ.

ملاحظة جانبية: يبدو أنه من الممكن إنشاء واجهة برمجة تطبيقات غلاف تشبه دفق الأحداث لـ Redux والتي تنفذ السطح الذي اقترحته أعلاه!

https://github.com/ajhyndman/redux-event-stream

ajhyndman أعتقد أن الغلاف هو الطريقة الصحيحة لمتابعة فكرتك هناك 👍

فيما يتعلق بالعمل الهندسي samza و linkin الذي ذكرته ، إذا لم يقرأ الآخرون / يشاهدوا الحديث الرائع ، قم تخصيص ساعة للقيام بذلك في وقت ما! أعتقد أنني رأيت دان يذكره في رسالة تمهيدية أو تغريدة في مرحلة ما ، لقد غيّر هذا الحديث كيفية رؤية قواعد البيانات وإدارة الدولة إلى الأبد وهو ابن عم مثالي للغاية لإعادة القراءة.

هذا الفيديو رائع! إنه أيضًا العنصر الثاني في قائمة Thanks on the redux repo README.

مرحبا جميعا!

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

المكتبة تسمى Kea :

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

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

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

بالنسبة لي ، قللت هذه المكتبة دائمًا بشكل كبير من الصيغة المعيارية ، بينما بقيت وفية لجوهر الإعادة نفسها.

على أي حال ، يكفي الحديث ، إليك بعض التعليمات البرمجية. هذا مثال على ما أسميه "inline kea" - حيث يتم إرفاق المنطق بالمكون الخاص بك مباشرة. يعد هذا الوضع رائعًا عندما تبدأ للتو أو كبديل لـ React's setState .

import React, { Component } from 'react'
import PropTypes from 'prop-types'
import { kea } from 'kea'

@kea({
  actions: () => ({
    increment: (amount) => ({ amount }),
    decrement: (amount) => ({ amount })
  }),

  reducers: ({ actions }) => ({
    counter: [0, PropTypes.number, {
      [actions.increment]: (state, payload) => state + payload.amount,
      [actions.decrement]: (state, payload) => state - payload.amount
    }]
  }),

  selectors: ({ selectors }) => ({
    doubleCounter: [
      () => [selectors.counter],
      (counter) => counter * 2,
      PropTypes.number
    ]
  })
})
export default class Counter extends Component {
  render () {
    const { counter, doubleCounter } = this.props
    const { increment, decrement } = this.actions

    return (
      <div className='kea-counter'>
        Count: {counter}<br />
        Doublecount: {doubleCounter}<br />
        <button onClick={() => increment(1)}>Increment</button>
        <button onClick={() => decrement(1)}>Decrement</button>
      </div>
    )
  }
}

في حالة نمو تطبيقك واحتاج المزيد من الأماكن إلى الوصول إلى الإجراءات increment و decrement أو الخاصية counter ، يمكنك فقط تقسيم الكود الخاص بك على النحو التالي:

// counter-logic.js
import PropTypes from 'prop-types'
import { kea } from 'kea'

export default kea({
  actions: () => ({
    increment: (amount) => ({ amount }),
    decrement: (amount) => ({ amount })
  }),

  reducers: ({ actions }) => ({
    counter: [0, PropTypes.number, {
      [actions.increment]: (state, payload) => state + payload.amount,
      [actions.decrement]: (state, payload) => state - payload.amount
    }]
  }),

  selectors: ({ selectors }) => ({
    doubleCounter: [
      () => [selectors.counter],
      (counter) => counter * 2,
      PropTypes.number
    ]
  })
})

// index.js
import React, { Component } from 'react'
import { connect } from 'kea'

import counterLogic from './counter-logic'

@connect({
  actions: [
    counterLogic, [
      'increment',
      'decrement'
    ]
  ],
  props: [
    counterLogic, [
      'counter',
      'doubleCounter'
    ]
  ]
})
export default class Counter extends Component {
  render () {
    const { counter, doubleCounter } = this.props
    const { increment, decrement } = this.actions

    return (
      <div className='kea-counter'>
        Count: {counter}<br />
        Doublecount: {doubleCounter}<br />
        <button onClick={() => increment(1)}>Increment</button>
        <button onClick={() => decrement(1)}>Decrement</button>
      </div>
    )
  }
}

يرجى تجربته وقراءة المستندات لمعرفة المزيد عن الآثار الجانبية من خلال redux-saga والميزات الأخرى التي يمكنك استخدامها.

كانت التعليقات الخاصة بـ Kea إيجابية للغاية حتى الآن ، مقتبسة من إحدى المشكلات: "يجب على المزيد من الأشخاص استخدام KeaJS لأنه يجعل عالم إعادة الإنتاج مكانًا أفضل!" :)

شكرا لك على وقتك وعلى قراءة هذا الآن! :)

يبدو جميل! لا أحب حقا الخيوط السحرية على الرغم من 'increment'

هل تقدمت هذه المناقشة في مكان آخر؟ من هو Kea النتيجة الأكثر صحة المقبولة بشكل عام؟

lucfranken : لا ،

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

ارمي قبعتي في الحلبة هنا. هذه هي الطريقة التي أعالج بها هذه المشكلة: https://github.com/HenrikJoreteg/redux-bundler

أنا شخصياً أعتقد أنه تبسيط كبير وتقليل للنمط المعياري.

إنها الطريقة التي أبني بها كل شيء أقوم ببنائه مؤخرًا.

أعتقد أنه سيساعد:
https://github.com/anish000kumar/redux-box

مرحبًا ، في شركتي ، قمنا للتو بفتح مكتبة من المصادر التي تدير طبقة الشبكة وتزيل الكثير من النماذج المعيارية من Redux. لقد أثبت نجاحه بالنسبة لنا ، ولكن جربه بنفسك: https://github.com/Brigad/redux-rest-easy/ (مقال متوسط: https://engineering.brigad.co/introducing-redux-rest-easy -6e9a91af4f59)

هذا هو أسلوبي لتقليل الصيغة المعيارية للإرجاع

https://github.com/zhDmitry/restate

كتقرير متأخر جدًا للخيط ، طلبت بعض التعليقات على Twitter لما تعنيه كلمة "boilerplate" للناس:

https://twitter.com/acemarke/status/969040835508604929

عودة الخيط Necro!

وفقًا لتعديلي للتعليق الأول في هذا الموضوع ، تم تحويل الأفكار التي تمت مناقشتها هنا إلى حزمة Redux-Starter-Kit الخاصة بنا . يرجى تجربته ومعرفة مقدار ما يمكن أن يساعد في تبسيط استخدام Redux الخاص بك!