[javascript] لماذا استخدام Redux عبر Facebook Flux؟



2 Answers

في Quora ، يقول شخص ما :

بادئ ذي بدء ، فمن الممكن تماما لكتابة التطبيقات مع React دون Flux.

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

ولكن إذا كنت لا تزال مهتمًا بمعرفة المزيد ، فاقرأ.

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

ربما ستشعر أن Redux مناسب تمامًا لتطبيقك وربما ستكتشف أن Redux يحاول حل مشكلة لا تعاني منها حقًا.

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

من مستندات Redux :

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

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

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

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

على خطى Flux و CQRS و Sourcing Event ، يحاول Redux جعل طفرات الدولة متوقعة عن طريق فرض قيود معينة على كيفية ووقت حدوث التحديثات. تنعكس هذه القيود في المبادئ الثلاثة لـ Redux.

أيضًا من مستندات Redux :

المفاهيم الأساسية
Redux نفسها بسيطة جدا.

تخيل أن حالة تطبيقك موصوفة ككائن عادي. على سبيل المثال ، قد تبدو حالة تطبيق todo كما يلي:

{
  todos: [{
    text: 'Eat food',
    completed: true
  }, {
    text: 'Exercise',
    completed: false
  }],
  visibilityFilter: 'SHOW_COMPLETED'
}

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

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

{ type: 'ADD_TODO', text: 'Go to swimming pool' }
{ type: 'TOGGLE_TODO', index: 1 }
{ type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL' }

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

function visibilityFilter(state = 'SHOW_ALL', action) {
  if (action.type === 'SET_VISIBILITY_FILTER') {
    return action.filter;
  } else {
    return state;
  }
}

function todos(state = [], action) {
  switch (action.type) {
  case 'ADD_TODO':
    return state.concat([{ text: action.text, completed: false }]);
  case 'TOGGLE_TODO':
    return state.map((todo, index) =>
      action.index === index ?
        { text: todo.text, completed: !todo.completed } :
        todo
   )
  default:
    return state;
  }
}

ونكتب مخفضًا آخر يدير الحالة الكاملة لتطبيقنا عن طريق استدعاء هذين المخفّضين لمفاتيح الحالة المقابلة:

function todoApp(state = {}, action) {
  return {
    todos: todos(state.todos, action),
    visibilityFilter: visibilityFilter(state.visibilityFilter, action)
  };
}

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

Question

لقد قرأت هذه الإجابة ، قللت من نمط معياري ، نظرت إلى أمثلة قليلة من GitHub وحاولت حتى إعادة الصياغة قليلا (تطبيقات todo).

كما أفهم ، توفر الدوافع الرسمية لمستند redux مزايا مقارنة مع معماريات MVC التقليدية. ولكن لا يقدم إجابة على السؤال:

لماذا يجب عليك استخدام Redux عبر Facebook Flux؟

هل هذا فقط مسألة أنماط برمجة: وظيفية مقابل غير وظيفية؟ أو السؤال هو في القدرات / أدوات التطوير التي تلي اتباع نهج إعادة؟ ربما التحجيم؟ أو اختبار؟

هل أنا على حق إذا قلت أن إعادة التكرار هو تدفق للأشخاص الذين ينتمون إلى لغات وظيفية؟

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

في ما يلي نقاط التحفيز من الدوافع الرسمية للمستند :

  1. التعامل مع التحديثات المتفائلة ( كما أفهم ، فإنه لا يكاد يعتمد على النقطة 5. هل من الصعب تنفيذه في fb التمويه؟ )
  2. التقديم على الخادم ( fb flux أيضاً يمكنه القيام بذلك. أي فوائد مقارنة بالإعادة )
  3. إحضار البيانات قبل إجراء التحولات في المسار ( لماذا لا يمكن تحقيقها باستخدام fb flux؟ ما هي الفوائد؟ )
  4. إعادة تحميل ساخنة ( من الممكن مع React Hot Reload . لماذا نحتاج إلى إعادة تشغيل؟ )
  5. تراجع / إعادة الوظائف
  6. أي نقاط أخرى؟ مثل الدولة المستمرة ...



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




أنا متبني سابق ونفذ تطبيقًا متوسط ​​الحجم في الصفحة الواحدة باستخدام مكتبة Facebook Flux.

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

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

قررنا أن نتحرك للأمام إلى Redux وأقترح عليك أن تفعل الشيء نفسه ؛)




Related