javascript - لماذا استخدام Redux-Observable على Redux-Saga؟




reactive-programming (4)

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

لديّ 3 نقاط أود أن أذكرها هنا.

1. التعقيد ومنحنى التعلم

الإعادة-الملحمة يتفوق بسهولة الإعادة-ملاحظة هنا. إذا كنت تحتاج فقط إلى طلب بسيط لإنجاز التفويض ولا تريد استخدام thux-redux لبعض الأسباب ، فيجب عليك التفكير في استخدام redux-saga ، إنه أسهل للفهم.

إذا لم يكن لديك معرفة مسبقة بـ Observable ، فسيكون ذلك مؤلمًا لك وسيقوم فريقك بتدريسك :)

2. ما يمكن ملاحظته و RxJS تقدم لي؟

عندما يتعلق الأمر بمنطق عدم التزامن Observable هو سكينك السويسري ، فإن Observable يمكنه فعل كل شيء تقريبًا من أجلك. يجب ألا تقارنها أبدًا بالوعود أو المولدات ، فهي أكثر قوة ، مثل مقارنة Optimus Prime بشيفروليه.

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

3. رد الفعل التمديد

فقط تحقق من هذا الرابط

http://reactivex.io/languages.html

يتم تطبيق الامتداد التفاعلي لجميع لغات البرمجة الحديثة ، إنه مجرد مفتاح البرمجة الوظيفية.

لذلك اقضي وقتك في تعلم RxJS بحكمة واستخدم إعادة النسخ المتماثل :)

لقد استخدمت Redux-Saga . الرمز المكتوب به من السهل أن يكون سببًا حتى الآن ، باستثناء وظيفة مولد JS التي ترفع رأسي من وقت لآخر. من فهمي ، يمكن لـ Redux-Observable تحقيق المهمة المماثلة التي تتعامل مع الآثار الجانبية ولكن دون استخدام وظيفة المولد.

ومع ذلك ، لا توفر مستندات Redux-Observable العديد من الآراء حول سبب تفوقها على Redux-Saga. أريد أن أعرف ما إذا كان عدم استخدام وظيفة المولد هو الفائدة الوحيدة لاستخدام ميزة Redux-Observable. وما يمكن أن يكون السلبيات ، مسكتك أو تسويات من استخدام Redux-Observable بدلاً من Redux-Saga؟ شكرا لك مقدما.


أعتقد أن هناك أشياء تحتاج إلى أخذها في الاعتبار.

  1. تعقيد
  2. نمط الترميز
  3. منحنى التعلم
  4. قابلية الاختبار

دعنا نقول أننا نريد جلب المستخدم من API

// Redux-Saga

import axios from 'axios' 

function* watchSaga(){
  yield takeEvery('fetch_user', fetchUser) // waiting for action (fetch_user)
}

function* fetchUser(action){
    try {
        yield put({type:'fetch_user_ing'})
        const response = yield call(axios.get,'/api/users/1')
        yield put({type:'fetch_user_done',user:response.data})
  } catch (error) {
        yield put({type:'fetch_user_error',error})
  }
}

// Redux-Observable
import axios from 'axios'

const fetchUserEpic = action$ => 
    action$
        .ofType('fetch_user')
        .flatMap(()=>
          Observable.from(axios.get('/api/users/1')) // or use Observable.ajax
            .map(response=>({type:'fetch_user_done', user:response.data}))
            .catch(error => Observable.of({type:'fetch_user_error',error}))
            .startWith({type:'fetch_user_ing'})
        )

أيضًا ، لقد كتبت هذا المقال من أجل مقارنة الاختلافات بين Redux-saga و Redux-Observable بعمق. تحقق من هذا الرابط هنا أو presentation .


إخلاء المسئولية: أنا أحد مؤلفي عملية إعادة التكرار التي يمكن ملاحظتها ، لذا من الصعب بالنسبة لي أن أكون محايدًا بنسبة 100٪.

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

تل ؛ الدكتور هناك إيجابيات وسلبيات على حد سواء. سيجد الكثيرون أن أحدهم أكثر سهولة من الآخر ، لكن كلاهما معقد للتعلم بطرق مختلفة إذا كنت لا تعرف RxJS (مسترجع قابل للملاحظة) أو مولدات / "مؤثرات كبيانات" (redux-saga).

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

redux- ملاحظتها تؤجل كل شيء تقريبًا إلى RxJS الاصطلاحي. لذا ، إذا كان لديك معرفة بـ RxJS (أو اكتسبتها) ، فإن تعلم واستخدام طريقة redux يمكن ملاحظتها أمر طبيعي للغاية. هذا يعني أيضًا أن هذه المعرفة قابلة للتحويل إلى أشياء أخرى غير الإعادة. إذا قررت التبديل إلى MobX ، إذا قررت التبديل إلى Angular2 ، إذا قررت التبديل إلى بعض درجات الحرارة في المستقبل X ، فستكون الفرص جيدة للغاية حيث يمكن أن يساعدك RxJS. هذا لأن RxJS هي مكتبة عامة غير متزامنة ، وتشبه في كثير من الأحيان لغة البرمجة في حد ذاتها — نموذج "البرمجة التفاعلية" بأكمله. RxJS موجودة منذ عام 2012 وبدأت كمنفذ لـ Rx.NET (هناك "منافذ" بكل اللغات الرئيسية تقريبًا ، إنها مفيدة ).

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

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

غالبًا ما يسأل الناس لماذا لا نفعل شيئًا كهذا من خلال إعادة الإعادة الملحوظة: بالنسبة لي لا يتوافق بشكل أساسي مع Rx الاصطلاحي العادي. في Rx ، نستخدم عوامل التشغيل مثل .debounceTime() التي تتضمن المنطق المطلوب للخصم منه ، لكن هذا يعني أننا إذا أردنا عمل نسخة منه لا تؤدي فعليًا إلغاء الإرسال ثم تنبعث منها كائنات مهمة بقصد ، لقد فقدنا الآن قوة Rx لأنه لا يمكنك فقط تشغيل مشغلي السلسلة لأنهم سيعملون على كائن المهمة هذا ، وليس النتيجة الحقيقية للعملية. من الصعب حقًا شرح هذا بأناقة. يتطلب الأمر مرة أخرى فهمًا شديدًا لـ Rx لفهم عدم توافق النهج. إذا كنت ترغب حقًا في شيء من هذا القبيل ، فراجع redux-cycles إعادة التكرار التي تستخدم cycle.js ولديها في الغالب تلك الأهداف. أجد أن الأمر يتطلب الكثير من الاحتفالات لأذواقي ، لكنني أشجعك على إعطائها تدورًا إذا كان ذلك يثير اهتمامك.

كما ذكر ThorbenA ، لا أخجل من الإقرار بأن الملحمة المسترجعة (10/13/16) هي الرائد الواضح في إدارة الآثار الجانبية المعقدة للإعادة. لقد بدأ في وقت سابق ويحتوي على مجتمع أكثر قوة. لذلك هناك الكثير من الجاذبية لاستخدام المعيار الواقعي على الطفل الجديد في الكتلة. أعتقد أنه من الآمن القول إذا كنت تستخدم إما دون علم مسبق ، فأنت في حالة من الالتباس. كلانا يستخدم مفاهيم متقدمة إلى حد ما والتي بمجرد "الحصول عليها" ، تجعل إدارة الآثار الجانبية المعقدة أسهل بكثير ، ولكن حتى ذلك الحين يتعثر الكثيرون.

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


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

من أجل قيمتها ، أنا أستخدم sagas في الإنتاج في تطبيق ويب.

Sagas مقابل Thunk

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

منحنى التعلم لساجاس

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

أساليب الملحمة الأساسية هي (في تجربتي):

  • call - اتصل بأي جزء من الشفرة واحصل على قيمة الإرجاع. يدعم الوعود. تآزر كبير بين معالجة المتزامن و sagas.
  • select - استدعاء محدد. هذا قليلا رائعة نوعا ما. محددات هي الأساسية لإعادة ، وأنها مدعومة بنسبة 100 ٪!
  • put - ويعرف أيضا باسم dispatch العمل. في الواقع إرسال ما تريد!

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

خاتمة

السبب في أنني اخترت sagas هو سهولة الاستخدام. بدا redux- ملاحظ مثل التحدي. أنا راض بنسبة 100 ٪ مع الملحمة. أكثر سعادة مما كنت أتوقع.

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





redux-observable