[javascript] إيجابيات وسلبيات استخدام red-saga مع مولدات ES6 مقابل redux-thunk مع ES2017 async / await



1 Answers

سأضيف تجربتي باستخدام القصة في نظام الإنتاج بالإضافة إلى إجابة مؤلفها بشكل واضح.

برو (باستخدام الملحمة):

  • قابلية الاختبار. من السهل جدًا اختبار sagas حيث تقوم call () بإرجاع كائن نقي. عادةً ما يتطلب اختبار thunks تضمين MockStore داخل الاختبار الخاص بك.

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

  • تقدم Sagas مكانًا مستقلاً للتعامل مع جميع الآثار الجانبية. عادة ما يكون من الأسهل تعديلها وإدارتها من الإجراءات الشديدة في تجربتي.

يخدع:

  • بناء جملة مولد.

  • الكثير من المفاهيم للتعلم.

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

Question

هناك الكثير من الحديث عن أحدث طفل في مدينة Redux الآن ، redux-saga/redux-saga . ويستخدم وظائف مولد للاستماع إلى إجراءات / إيفاد.

قبل أن أضع رأسي حوله ، أود أن أعرف إيجابيات وسلبيات استخدام redux-saga بدلاً من النهج أدناه حيث أستخدم redux-thunk مع async / await.

قد يبدو أحد المكونات كهذا ، حيث يتم إرسال إجراءات كالمعتاد.

import { login } from 'redux/auth';

class LoginForm extends Component {

  onClick(e) {
    e.preventDefault();
    const { user, pass } = this.refs;
    this.props.dispatch(login(user.value, pass.value));
  }

  render() {
    return (<div>
        <input type="text" ref="user" />
        <input type="password" ref="pass" />
        <button onClick={::this.onClick}>Sign In</button>
    </div>);
  } 
}

export default connect((state) => ({}))(LoginForm);

ثم أفعالي تبدو كهذا:

// auth.js

import request from 'axios';
import { loadUserData } from './user';

// define constants
// define initial state
// export default reducer

export const login = (user, pass) => async (dispatch) => {
    try {
        dispatch({ type: LOGIN_REQUEST });
        let { data } = await request.post('/login', { user, pass });
        await dispatch(loadUserData(data.uid));
        dispatch({ type: LOGIN_SUCCESS, data });
    } catch(error) {
        dispatch({ type: LOGIN_ERROR, error });
    }
}

// more actions...
// user.js

import request from 'axios';

// define constants
// define initial state
// export default reducer

export const loadUserData = (uid) => async (dispatch) => {
    try {
        dispatch({ type: USERDATA_REQUEST });
        let { data } = await request.get(`/users/${uid}`);
        dispatch({ type: USERDATA_SUCCESS, data });
    } catch(error) {
        dispatch({ type: USERDATA_ERROR, error });
    }
}

// more actions...



أسهل طريقة هي استخدام redux-auto .

من وثيقة

قام redux-auto بتثبيت هذه المشكلة غير المتزامنة ببساطة عن طريق السماح لك بإنشاء وظيفة "إجراء" تعيد الوعد. لمرافقة منطق إجراء الوظيفة "الافتراضي" الخاص بك.

  1. لا حاجة للبرامج الوسيطة الأخرى. على سبيل المثال thunk ، الوعد ، الوسيطة ، الملحمة
  2. يسمح لك بسهولة لتمرير الوعد إلى redux وتمكنت من إدارتها لك
  3. يتيح لك المشاركة في تحديد موقع مكالمات الخدمات الخارجية مع المكان الذي سيتم تحويلها إليه
  4. تسمية الملف "init.js" ستطلق عليه مرة واحدة عند بدء التطبيق. هذا جيد لتحميل البيانات من الخادم في البداية

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

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




Related