בעבודה עם Redux אולי המידלוור הכי פופולרי היה תקופה ארוכה Redux Thunk. וכמו שהוא היה פופולרי כך הוא גם הזיק לאקו-סיסטם. בימים הקרובים אני הולך להשיק כאן קורס ריאקט חדש לגמרי ואחרי התלבטות החלטתי לוותר על Redux Thunk בסידרת השיעורים על Redux. הנה הסיבות המרכזיות:

1. מעבר לפעולות Ajax בתוך הקומפוננטות

עם הכניסה של React Hooks ובעיקר useEffect, הכתיב של יצירת בקשות Ajax מתוך קומפוננטה הפך הרבה יותר קל ועם הרבה פחות מקום לטעויות. יצירה של Custom Hooks כמו use-http רק הפכה את המשחק הזה לעוד יותר אטרקטיבי. וכשאנחנו מסתכלים קדימה כלים כמו Suspense הולכים לפתור את מעט בעיות הביצועים שעוד נשארו בגישה זו.

מסיבה זו בראיה קדימה ארכיטקטורה שבה כל קומפוננטה מביאה את המידע שהיא צריכה מאפשרת הרבה יותר גמישות ביישום בהשוואה לארכיטקטורה בה פעולות ה Ajax נשלחות מ Actions של Redux ובצורה מערכתית.

2. כפל קוד וקושי לשתף התנהגות בין Actions

הבעיה האמיתית עם Redux Thunk היא שהוא מעודד כפל קוד: כמעט בכל Thunk אנחנו צריכים לכתוב את הקוד שמוציא בקשת תקשורת, מתרגם אותה לאירועי Redux ויודע לטפל נכון בכשלונות.

זה אומר שכמעט כל Thunk הולך לכלול קוד Boilerplate שנראה כך:

function myThunkActionCreator(someValue) {
    return (dispatch, getState) => {
        dispatch({type : "REQUEST_STARTED"});

        myAjaxLib.post("/someEndpoint", {data : someValue})
            .then(
                response => dispatch({type : "REQUEST_SUCCEEDED", payload : response}),
                error => dispatch({type : "REQUEST_FAILED", error : error})
            );
    };
}

לאורך זמן ה Thunk-ים האלה ממלאים את המערכת והופכים את הקוד להרבה פחות קריא והרבה יותר קשה לתחזוקה.

3. העדפה ל Middlewares יותר ספציפיים

גם כשכבר יש לנו פעולות אסינכרוניות שאנחנו רוצים להפעיל ברמת המערכת כמעט תמיד נקבל תוצאה יותר טובה אם נכתוב Redux Middleware ספציפי בעצמנו. בקורס החדש בחלק על Redux אני מתמקד ביצירת Middleware ספציפי עבור כל Use Case, לדוגמא בעבודה עם פיירבייס במקום לקחת משהו קיים אני מראה איך לכתוב את המידלוור שמטפל בנושא התקשורת.

ברוב המקרים כתיבת קוד Middleware אומרת שנכתוב את הקוד פעם אחת ברמת המערכת במקום לכתוב אותו שוב ושוב בכל Action, וכך הופכת את כל המערכת להרבה יותר קלה לתחזוקה.

מידלוורים כמו redux-saga או redux-observable הפכו בשנים האחרונות להרבה יותר פופולריים מ Thunk בדיוק מסיבה זו: הם מאפשרים בניה של מנגנונים יותר ספציפיים, כל אחד עם הגישה הייחודית שלו.

בשורה התחתונה - בפיתוח מערכת חדשה היום הייתי חושב פעמיים (או עשר פעמים) לפני שהייתי מכניס Redux Thunk וברוב המקרים גם ממליץ להשאיר את פעולות ה Ajax בתוך הקומפוננטות ורחוק מה Redux Store.