Redux ו-Context API הם שני כלים שונים לניהול state באפליקציות צד-לקוח, ולמרות שלעיתים מציגים אותם כתחליפים, הם פותרים בעיות שונות. Context API הוא מנגנון מובנה של React שמיועד להעברת נתונים דרך עץ הקומפוננטות (props drilling solution). Redux היא ספרייה חיצונית לניהול state מרכזי במבנה של חנות יחידה (store) עם רינדור סלקטיבי לפי חלקי state.
הכלל המעשי: אם ה-state שלכם יציב יחסית ומשותף לעץ קטן של קומפוננטות (theme, locale, משתמש מחובר) - Context API יספיק. אם ה-state מתעדכן תכופות, מורכב, ומשפיע על קומפוננטות רבות - Redux (ובמיוחד Redux Toolkit) ייתן ביצועים טובים יותר וכלים מתקדמים יותר.
Context API הוא חלק מובנה של React (זמין מאז React 16.3, מרץ 2018) שנועד לפתור את בעיית ה-prop drilling - העברת props דרך שכבות רבות של קומפוננטות. הוא מורכב משני חלקים: Provider שעוטף תת-עץ ומספק ערך, ו-useContext (או Consumer) שצורך את הערך בכל קומפוננטה בתוך התת-עץ.
הנקודה הקריטית לביצועים: לפי התיעוד הרשמי של React (react.dev), כל קומפוננטה שצורכת Context תרונדר מחדש כאשר ערך ה-Provider משתנה - גם אם הקומפוננטה משתמשת רק בחלק קטן מהערך. אם יש לכם Context יחיד עם אובייקט גדול ועץ של מעל 30 קומפוננטות צרכניות, עדכון של שדה אחד יגרום לרינדור של כולן.
אפשר לצמצם את הבעיה על-ידי פיצול ל-Contexts קטנים יותר (אחד ל-theme, אחד ל-user, אחד לעגלה) - אבל הפיצול עלול להוביל למבנה מסובך ולאיבוד הקונספט של 'single source of truth' - מקום מרכזי ואמין שבו נשמר המידע של האפליקציה.
Redux מאחסן את כל ה-state במקום מרכזי יחיד הנקרא store. ה-store מחולק ל-slices (בלוקים) נפרדים, כאשר כל slice מכיל רק את הנתונים הרלוונטיים לתחום מסוים (cart, user, products וכן הלאה). קומפוננטות נרשמות לחלקי state ספציפיים באמצעות useSelector, ומקבלות עדכון רק כאשר אותו חלק שהן בחרו משתנה בפועל.
המנגנון הזה - שנקרא selective subscriptions - הוא יתרון הביצועים העיקרי של Redux מול Context API. בנוסף, Redux כולל מערכת middleware מובנית (Redux Thunk, Redux Saga) לטיפול ב-side effects כמו קריאות API, ו-Redux DevTools - הרחבת דפדפן שמציגה כל פעולה ושינוי state בזמן אמת.
מאז שנת 2020, צוות Redux ממליץ רשמית על Redux Toolkit (RTK) כדרך הסטנדרטית לכתיבת קוד Redux חדש. RTK מצמצם משמעותית את כמות הקוד (boilerplate) שהיה ידוע לשמצה ב-Redux קלאסי, כולל את ספריית immer מובנית לעדכוני state בלתי-משתנים בכתיב מוטבי, ומפשט את הגדרת ה-store באמצעות configureStore ו-createSlice.
עבור אפליקציות קטנות עד בינוניות, עם עץ קומפוננטות שאינו מאוד עמוק או מורכב (לדוגמא, פחות מ-30 קומפוננטות), Context API יהיה בחירה טובה. עבור אפליקציות בינוניות עד גדולות, עם עץ קומפוננטות שגדול ועמוק או מורכב (לדוגמא, מעל מ-30 קומפוננטות) שחולקות מידע משותף, Redux יהיה מתאים יותר.
כאשר הנתונים שלנו אינם רבים והשימוש בהם הוא מוגבל לכמה קומפוננטות בלבד, Context API יכול להיות מספיק טוב ויעיל, כי גם אם חלק או כל הקומפוננטות יתרנדרו, זה לא יכביד יותר מידי על התוכנה שלנו כי מספר הנתונים מצומצם. כאשר יש לנו לא מעט נתונים והשימוש בהם משותף להרבה קומפוננטות, כאן אנחנו כנראה צריכים לתעדף את Redux כדי לשמור על אופטימיזציה טובה.
אם עדכוני הנתונים באפליקציה שלנו אינם תדירים ומורכבים, השימוש ב-Context API יכול להיות פשוט יותר. כי רק מדי פעם נעדכן את הנתונים וזה לא כזה נורא. אבל אם עדכוני הנתונים הם כן תדירים ומורכבים, השימוש ב-Redux יהיה טוב יותר כדי למנוע רנדורים מיותרים, במיוחד באפליקציות שמשותף להם הרבה נתונים.
אין תשובה אחת נכונה לכל אפליקציה. ההחלטה בין Redux ל-Context API היא תמיד פונקציה של שלושה משתנים: גודל (כמה קומפוננטות צורכות את ה-state), תדירות (כמה פעמים בשנייה ה-state מתעדכן), ו-מורכבות (האם יש side effects, async flows, או דרישה ל-time-travel debugging).
אם אתם פותחים אפליקציה חדשה היום וצופים שהיא תגדל - השקעה ב-Redux Toolkit מההתחלה תחסוך לכם migrations מאוחר יותר. אם אתם בונים פרויקט קטן או POC - Context API לבד או יחד עם useReducer יספיק לחלוטין. כלל אצבע מעשי: ברגע שאתם מוצאים את עצמכם מפצלים Context-ים רק בשביל ביצועים, זה הסימן שהגיע הזמן ל-Redux.
כדאי להשתמש ב-Context API באפליקציות קטנות עד בינוניות (עד כ-30 קומפוננטות), כאשר ה-state המשותף מצומצם ועדכוניו אינם תכופים. דוגמאות טיפוסיות: theme (מצב כהה/בהיר), locale (שפה), או אובייקט המשתמש המחובר - נתונים שנקבעים פעם אחת ולא משתנים לעיתים קרובות.
כן, בתנאים מסוימים. כל קומפוננטה שצורכת Context באמצעות useContext תרונדר מחדש בכל פעם שערך ה-Context משתנה - גם אם החלק הספציפי שהיא משתמשת בו לא השתנה. זו הסיבה ש-Context API פחות מתאים ל-state שמתעדכן תכופות באפליקציות גדולות.
כן. Redux Toolkit (RTK) הוא הדרך המומלצת רשמית של צוות Redux מאז 2020 לכתיבת לוגיקת Redux. הוא מצמצם משמעותית את כמות הקוד הנדרש (boilerplate), כולל immer מובנה לעדכוני state בלתי-משתנים בכתיב מוטבי, ומפשט את הגדרת ה-store וה-slices באמצעות configureStore ו-createSlice.
בהחלט. גישה מקובלת היא להשתמש ב-Redux ל-state גלובלי מורכב (נתוני שרת, cart, אובייקטי domain) ו-ב-Context API ל-state יציב או מקומי לתת-עץ (theme, locale, dependency injection של שירותים). השניים אינם מתחרים אלא משלימים - לכל אחד יש את ה-use case שלו.
useReducer + Context מספק תבנית דומה לניהול state עם actions ו-reducers, אך ללא יתרונות הביצוע של Redux: אין רינדור סלקטיבי לפי חלקי state (כל הצרכנים מתרנדרים), אין middleware מובנה (כמו Thunk/Saga), ואין כלי DevTools מתקדמים. זו אפשרות טובה לאפליקציות קטנות, אך ב-state מורכב Redux Toolkit עדיף.
