React Context vs Redux

React Context vs Redux

במאמר זה, אנו נלחוק סקירה קצרה של ניהול state, API context וארכיטקטורת Flux. אנו נתמקד ביתרונות ובחסרונות של React Context ו-Redux כדי לסכם ולהבהיר מהו הכלי הטוב ביותר לאפליקציית React.

Redux היא ספריית JavaScript בקוד פתוח לניהול state יישומים. משמש בדרך כלל עם ספריות כמו React או Angular לבניית ממשקי משתמש.

מצד שני, עם הגרסה החדשה ביותר של React משיקה את Context API החדש. נראה שלשני הכלים הללו יכולה להיות אותה אחריות באפליקציה כמו redux, אבל האם זה נכון?

במאמר זה, אנו חולקים סקירה קצרה של ניהול state וארכיטקטורת Flux. לאחר מכן אנו נתמקד ביתרונות ובחסרונות של Redux ו-Context API 2020, ולבסוף, נסכם ונבהיר מתי המצב הטוב ביותר להשתמש בכלים אלה.

מהו ניהול state באפליקציה, ולמה (ומתי) נצטרך אותה?

ניהול state הוא מכריע בפרויקטים בינוניים וגדולים. זה שימושי בפרויקטים קטנים יותר וניתנים לניהול, אבל לפעמים אנחנו יכולים להתמודד עם זה ללא ספריות או דפוסים מיוחדים.

בדרך כלל, אנו מסבירים את ניהול ה state עבור יישומי front end כמעין היגיון ששומר ומרענן נתונים עדכניים. לדוגמה – האם כפתור הבחירה מסומן או לא, האם המשתמש מאומת או לא. באופן מופשט יותר, זה אומר לדאוג לשמור על קלט ממשק משתמש ואולי לסנכרן את הנתונים בין דפים, Back end ו Front end.

בנוסף, זהו נושא מצוין להפרדה בין רינדור (או תצוגה) של רכיבים נקיים מהשכבה העסקית.

לנקודת מבט יותר של React, ניהול נכון של ה state מונע מאיתנו להעביר הרבה אביזרים מגורמים ברמה העליונה לנכדי היעד שלהם. במקרים מסוימים, אנו זקוקים state גלובלי שבו כל המרכיבים יכולים לדרוש נתונים חיוניים. זה לא אומר שהכל צריך להיות אוניברסלי. חלק מהמשתנים המקומיים זמינים רק עבור אלמנט אחד ואולי לילדים שלהם, לכן כדאי לשמור אותם כפי שהם (לדוגמה – האם אימות שדה מקומי גלוי או לא).

מהי ארכיטקטורת Flux?

לפני שתקראו על React-Redux, בואו נעשה סקירה קצרה של קונספט ה-Flux, שהוא פופולרי ביישומי Front end, במיוחד אלו שהוכנו עם React או Vue. פייסבוק ממליצה על ארכיטקטורת flux ליצירת SPAs (זו הסיבה שספריות רבות תומכות בזרימת הנתונים הזו לאפליקציית React).

flux המבוסס על ארבעת חלקי היישום:

  • store

החלק הזה רק מנהל את ה state. כאן יש לנו ערכים מהממשק והשכבה העסקית. באפליקציה צריך להיות רק "מקור אמת" אחד: store (ויכולות להיות לנו חנויות רבות). חשוב לזכור ש store עושה מניפולציות על ה state (ה state רק שומר את הנתונים). ה store מנהלת את הנתונים הללו כדי לטפל בשכבה העיסקית.

אז איך משנים נתונים? זה פשוט. ה store שלנו מקשיבה לכל הפעולות. באמצעות לוגיקה מיושמת (לדוגמה, הצהרות מיתוג קלות המבוססות על שמות פעולות), ה store בוחרת אחת מהן לביצוע

  • action (עם יוצרי פעולה)

מה שצריך כדי לבצע פעולה צריך להיות בתוך אובייקט רגיל. בדרך כלל זהו סוג שדה עבור שם פעולה (מזהה) ומטען עבור נתונים נוספים.

יוצרי הפעולה הם עזרים קטנים אך מרשימים לספק פעולה. במקום לכתוב כל פעם את אותן שורות לשליחת אותה פעולה, נוכל להכין פונקציה שמחזירה את הסוג שלה ואולי מקבלת מטען.

  • Dispatcher

שכבה זו היא אובייקט יחיד לשיתוף פעולות עבור כל ה stores באפליקציה. השולח משדר את הפעולה שנקראה.

  • Viwe 

View פירושו אלמנט ממשק משתמש. בשלב זה, הרכיב צריך לעבד אלמנטים ולטפל בפעולות המשתמש (כמו לחיצה על כפתור, הקלדת טקסט או גרירה ושחרור). במקרה של שינויים, התצוגה תוצג מחדש.

  • Presentation Views

כל הערכים מועברים דרך props. רכיבים אלו לא צריכים לקרוא להם ישירות ל store. אותו דבר לגבי פעולות – הם לא יכולים לקיים אינטראקציות עם השולח. הכל, אפילו פונקציות, מגיע מה props.

  • Container Views

תצוגות אלה חזקות יותר מ Presentation Views. לאחר פעולות משתמש שולחות פעולות, כך שהן מחוברות לשדר ול store. המשימה של Container Views היא לשים לב לשינויים ב store ולאכלס נתונים עבור Container Views.

React Context לעומת Redux (סקירה כללית)

Redux היא עדיין הדרך הפופולרית ביותר לניהול state ככלי מבוסס fkux.

המהדורה הראשונה של Redux הייתה ביוני 2015, שנתיים לאחר ההשקה הראשונית של React. דן אברמוב ואנדרו קלארק הם המחברים המקוריים של פתרון זה.

  1. store מרכזי אחד בלבד. איננו יכולים לשנות את ערכיו, כי state זה אינו ניתן לשינוי.
  2. שלבים לעדכון ה state הגלובלי נמצאים בתוך פונקציות ה reducer. ה state החדש מוחזר כתוצאה מפעולותיה.
  3. השתמש במינויים לנתונים כדי לקבל ערכים רעננים.
  4. actions נשלחות לפונקציות reducer.

יתרונות (+)

  • נפוץ בשימוש (פופולריות) – הרבה בעיות נפתרות על ידי הקהילה
  • Redux Toolkit – תכונה מרשימה חדשה להגבלת קוד ה-boilerplate
  • מיועד לנתונים המשתנים (מתרעננים) לעתים קרובות
  • חבילת Good React Redux לשילוב עם React
  • איתור באגים טוב יותר – ישנה אפשרות לרישום state ופעולות
  • ארגון קוד – לאפליקציות עם Redux יש בדרך כלל ארכיטקטורה דומה, כך שקל יותר להבין את הפרויקט הבא עבור מפתחים מנוסים
  • עיבוד בצד השרת זמין עם Redux

חסרונות (-)

  • לא מובנה ב-React (מגדיל את גודל החבילה הסופי)
  • עלול להטעות למתחילים (הרבה היגיון נסתר) אפילו עם Redux Toolkit
  • יותר הגדרה מאשר Context API (ועוד מונחים להבנה)
  • שימוש חוזר ברכיבים קשים יותר מכיוון שחלק מהנתונים מגיעים מה state הגלובלי, לא מ props
  • תוכנת אמצעית למשימות אסינכרוניות.

React Context API 2020 מובנה (סקירה כללית)

מאז React v16.3.0 אנחנו יכולים להשתמש לא רק בשיטות מחזור חיים חדשות. Context API מגיע גם עם גרסה זו. לפני האירוע הזה ל-React הייתה תמיכה ניסיונית בתכונה שלו, אבל עכשיו יש ממשק API יעיל יותר ל context API.

מהו ה context? זוהי תכונה מובנית חכמה לפתרון בעיות בשיתוף נתונים בין רכיבים מקוננים (לא מחוברים ישירות) באמצעות Context API.

יתרונות (+)

  • הכלי React המובנה לא השפיע על גודל החבילה הסופי, והוא משולב בעיצובו עם כל חבילת npm
  • קל יותר להבנה ולטפל למתחילים בהשוואה לזרימת נתונים Redux
  • מצוין עבור נתונים סטטיים יותר – לא כל כך מתעדכן בתדירות כמו ב-Redux
  • חלק מתועד היטב של React
  • הרבה הקשרים מקומיים לטיפול במשימות לוגיות נפרדות יכולים להיות באפליקציה.

חסרונות (-)

  • Context-API אינו מיועד לנתונים המתרעננים או משתנים לעתים קרובות
  • יכולה להיות תחזוקה קשה יותר ביישומי חזית מורכבים יותר, במיוחד אם יש לנו פתרונות ועזרים מותאמים אישית
  • שימוש חוזר ברכיבים קשים יותר, מכיוון שחלק מהנתונים מגיעים מה context, לא תמיד מה Props.

Reactjs Context ו-Redux – מתי להשתמש באיזה מהם?

 מתי להשתמש ב- Redux?

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

מנקודת המבט של ארכיטקטורה, Redux עוזר לנו לשמור על סדר תיקיות וקבצים של הפרויקט ולהפוך את האפליקציה שלנו לקריאה לפיתוח נוסף. כלי זה מציע פיצול קוד לחלקים לוגיים, כ reducer או action. זה מאפשר למפתחים להבין מבנה יישומים ויש לו השפעה על צמצום הזמן לכניסה לחברי צוות חדשים (אם למפתחים אלה יש ידע בסיסי על Redux).

בנוסף, ל- Redux יש תמיכה מצוינת בעדכוני נתונים בתדירות גבוהה. ביישום כלשהו, ​​יש הרבה ערכים שמתרעננים בכל פעם. זה יכול להיות אינטראקציות רבות של משתמשים או אולי קבלת נתונים מ-API. במקרה זה, Redux יכול לעזור.

כלי הפיתוח של Redux שימושיים ומשולבים עם דפדפנים. זה קל לשימוש ועל זה ניתן לשמוע עוד  ב קורס REACT

מתי להשתמש ב context?

אנחנו יכולים למצוא את התשובה בתיעוד React ישירות. כפי שנכתב במאמר זה, ה context הוכן לבחינת נתונים גלובליים ניתנים לשיתוף – כמו ערכי נושא או אימות משתמשים באפליקציה.

הכלי המובנה הזה פותר בעיה ענקית: props drilling. הקוד שבו אנחנו צריכים להעביר הרבה ערכים וזה עדיין קורה לא נכון להבין ולתחזק.

ה context הוא דרך טובה לחלוק ערכים בין ה props שלנו מבלי להשתמש ב props בכל פעם, אבל הקריטריונים האלה לא צריכים להיות רק אחד. אם יש צורך בכמה ערכים ברמות שונות של עץ ה Props ועבור אלמנטים רבים, יהיה זה רעיון טוב להשתמש ב context עבור נתונים אלה. עם ה context, יש לנו דרך נוספת לשתף ערכים ושינויים שלהם. כל ה props מתחת לספק ה context מסוגלים לקרוא נתונים אלה, לטפל בהם או לשכתב. במצבים מסוימים, זה יכול להיות נוח יותר משימוש בכלים אחרים, במיוחד עבור אספקת ערכות נושא או שמירה במטמון.

אם אתה חושב רק להרחיק יישום מבעיית props drilling, שקול את דפוס הרכב ה props (מודגש בתיעוד React על הקשר).

Redux או Context API? מי המנצח?

האם React Context עובד בצורה יעילה יותר מאשר Redux? האם זה פשוט יותר, מובנה וקל יותר ללמידה ויש לו אינסוף יתרונות? לא תמיד. לפי הציטוט של Sebastian Markbage, חלק מצוות React: Context לא מיועד לטיפול בעדכונים בתדירות גבוהה. זה לא אומר שהתכונה הזו לא תעבוד. כמובן, זה יהיה, ואתה יכול להחליט להשתמש בו בהצלחה (במיוחד בפרויקטים קטנים יותר).

יתר על כן, Context תומך בצורה עדינה יותר על ידי עיצוב עדכונים בתדירות נמוכה (שפה נבחרת, ערכת צבעים) מאחרים. מצד שני, Redux עדיף בתחום נתוני העדכון בתדירות גבוהה.

לסיכום

לאחר קריאת המאמר הזה, אולי יש לך שאלה אחת – אז מה טוב יותר עבור האפליקציה העתידית שלך? Redux או Context API? התשובה אינה פשוטה וקלה.

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

נראה שה context נוח יותר וגמיש יותר מאשר Redux. אתה יכול לבחור וליישם מעטפת מותאמת אישית לטיפול בעדכונים או פעולות קריאה. הקשר עם React Hooks הוא תכונה חזקה שנראית טוב מאוד לתחזוקה והבנת זרימת הנתונים באפליקציה. אנחנו לא צריכים קוד boilerplate, החבילה הנוספת (אפילו עבור פעולות אסינכרוניות), או קבצים נוספים. הכל מובנה ומוכן לשימוש.

Redux היא ספרייה מבוססת flux ישירות לניהול state ביישומים. ראוי לציין קהילה מאוד פעילה ועוזרת וחבילות עדכונים שוטפות. הודות לשילוב הזה, הרבה אתגרים ובעיות נפתרות במהירות ונרשמות למשתמשים הבאים. חלק ניכר מקוד ה-boilerplate כבר לא נחוץ עם Redux Toolkit, אבל זה מגיע עם עלויות. פחות קוד לוח אומר שהלוגיקה מוסתרת יותר. גישה זו עלולה להפריע למתחילים להבין את המערכת במהירות.

בנוסף, מפתחים צריכים להבין מונחים חדשים של Redux, כגון "store" או " dispatcher ". חוץ מזה, תוכנת הביניים נדרשת כדי להפעיל פעולה אסינכרונית .

לא קל להחליט איזה כלי מתאים יותר. לפעמים Redux הוא יתר על המידה עבור יישומים פשוטים, אפילו עם Redux Toolkit. ה context, לעומת זאת, אינו תחליף ל-Redux. לפעמים עבור יישומים מורכבים יותר עם יותר מפתחים, זה יכול להיות קל יותר להתחיל עם Redux עקב תחזוקה חלקה יותר.

בסופו של דבר, "מה עדיף" צריך להיות מובן כ"מה טוב יותר עבור האפליקציה שלנו והצוות שלנו". זה תמיד תלוי בניסיון של המפתחים, בידע שלהם בשני הפתרונות ובמקרי השימוש בפרויקטים בודדים נושאים אלו ועוד נמצאים  ב קורס REACT

 

העתיד שלך בהייטק מתחיל כאן
צור איתי קשר עוד היום

דילוג לתוכן