הבלוג של ינון פרק

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

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

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

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

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

את הבאג הבא לקח לי יותר מדי זמן למצוא, נראה אם תצליחו להיות מהירים יותר.

ריאן ומייקל, אני לא עומד בקצב שלכם. בפעם הראשונה ששיניתם את כל ה API במעבר מ 0.13 ל 1.0 עוד זרמנו עם זה, ברור שעוד לא היתה גירסא 1 ושום דבר עוד לא סופי. כשפחות משנה אחרי באתם עם גירסא 2 שמשנה את כל ה API שדרגתי, אבל ההודעה האחרונה על שינוי נוסף ב API בגירסא 4.0 היא כבר שדרוג אחד יותר מדי.

אומנם אין הרבה חלופות ל react-router, אבל אחרי עצה טובה מבנג'מן הצלחתי לחבר את ה router של express כתחליף. תשמעו איך זה עובד.

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

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

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

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

תוספת של פיצ'ר לאתר שברה לי חלק מהקישורים הפנימיים, והסימן המזהה של הנזק היה סימן שאלה שהופיע פעמיים ב URL. לא לקח הרבה זמן להבין שהאשמה בהתמודדות מוזרה של אלמנט Link של ריאקט-ראוטר עם נתיבים עם פרמטרים. כדי שאתם לא תיפלו באותו הבור, תוכלו למצוא כאן המחשה של הבעיה ואת המעקף שאני כתבתי.

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

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

קחו למשל את הקוד הבא עבור פלאגין למונה לחיצות.