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

פונקציות Ref Callback יכולות להיות תחליף טוב ויעיל ל useEffect, וכמו useEffect גם להן יש כמה פינות חדות. בואו נראה דוגמה ומה יכול להשתבש.

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

עם AI לכאורה אין לנו את הבעיה הזאת. בזריקה מהירה מהראש כשיש לי בעיה היום אני יכול להתייעץ עם Claude, grok, gemini, ChatGPT, perplexity, Copilot, DeepSeek וזה לפני שמחפשים סוכני AI מותאמים אישית לבעיות. כל AI מיוצר על ידי חברה אחרת, מאומן בדרך שונה ועל מידע שונה, ולכן אמור לתת תוצאות שונות לשאלות.

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

1. כדאי להחליף חברי AI מדי פעם, אבל לא בטוח שיש טעם "לחקור" בעיה באמצעות שליחתה לעוד ועוד מנועים.

2. רצוי לתת למנועים לעשות Code Review על קוד שלהם או של חבריהם. לפעמים הם מצליחים לזהות את הבאגים של עצמם ככה. לפעמים הם רק יוצרים באגים חדשים.

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

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

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

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

האם זה אומר שגם לי כדאי לבנות לבד את התשתית? פה התשובה קצת יותר מורכבת:

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

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

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

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

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

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

1. הפריימוורקים בנויים על אינטגרציה עמוקה עם ריאקט, אבל מפותחים על ידי חברות אחרות.

2. ריאקט = פגיעה בביצועים.

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

שלושת ההתנגדויות מבוססות ויש בהן יותר משמץ של אמת, ובכל זאת אני רוצה לחדד ולהוסיף:

1. נכון, נקסט ו React Router מפותחים על ידי חברות שונות, אבל ריאקט עצמה היא פרויקט קוד פתוח. בעמוד פגוש את הצוות אנחנו פוגשים את מפתחי הליבה של ריאקט. מתוך 21 מפתחי ליבה ברשימה 5 עובדים ב Vercel, עוד 2 עצמאיים ו 14 עובדי פייסבוק. זה אומר שהקשר בין נקסט לריאקט הוא די מבוסס.

2. נכון, ביצועים של אתרי ריאקט באופן כללי ונקסט באופן ספציפי נוטים להיות פחות טובים מביצועים של אתרי HTML בלבד או אפילו אתרי jQuery או XHTML. אתרי ריאקט מסובכים יותר ובנוסף בריאקט ו next יש הרבה מאוד מלכודות ביצועים, אם תשאלו אותי הרבה יותר ממה שצריך בפריימוורק מסוג זה. אבל האם היינו אומרים שיש לריילס בעיית ביצועים בגלל שמפתחים צעירים ישתמשו לא נכון ב ORM ויצרו יותר מדי שאילתות? כן יש בורות, צריך להכיר אותם, צריך לפעמים לעבוד קשה בשביל להימנע מהם. ועדיין כשמכירים את הבעיות ועובדים נכון אפשר לבנות אתרים שיעבדו מהר גם בריאקט. וכן יש בעיות וזה כנראה דברים שקשה לסדר וריאקט קומפיילר הוא לא צעד בכיוון הנכון, אבל עדיין עם עבודה נכונה ואופטימיזציה במקומות שצריך אפשר להגיע לתוצאות טובות.

3. נקסט הוא בסך הכל node.js. האם היו צריכים להוסיף ORM? ספריה לביצוע משימות ברקע? מערכת לוגים טובה יותר? אולי. אבל Node זה לא רובי ולא אותה אקוסיסטם. בעולם של JavaScript אנשים מעדיפים להרכיב הרבה ספריות קטנות וכל פרויקט הוא שונה, בעוד שבעולם של רובי סינטרה או הנמי לא הצליחו להתרומם ואנשים מעדיפים את הפריימוורק הגדול שפותר את כל הבעיות. זה לא שלא היו ניסיונות אבל איכשהו הם לא היו מספיק מוצלחים או מתוחזקים לאורך זמן. נכון אין לנו פיתרון מובנה מהקופסה לכל הבעיות אבל כל עוד אפשר למצוא שילוב טוב של ספריות או לפתח Serverless על מערכת ענן זה כנראה לא כל כך נורא.

למה בכל זאת צריך לזכור לפני שנכנסים לפרויקט next / react? הבעיה הכי גדולה שלהם היום היא ה Learning Curve, וזה לצערי רק מחמיר. ריאקט נראה פשוט במבט ראשון בגלל שהוא בכל מקום אבל כתיבה נכונה ומסודרת שלו היא עדיין מבלבלת והרבה מפתחי ריאקט מתיחסים לחלקים גדולים מהפריימוורק כמו קסם. אתגר נוסף הוא השינויים התכופים בסגנון העבודה, מה שמייצר צורך לשכתב קוד קיים רק בשביל שהמערכת לא תרגיש מיושנת ושיהיה קל יותר להשתלב באקוסיסטם. רק בשנים שאני עובד בריאקט עברתי מכתיב האוביקטים לכתיב הקלאסים, מכתיב הקלאסים לכתיב ה Hooks ועכשיו עדיין בעולם ה Hooks אנחנו רואים מעבר מעולם של אפליקציות צד-לקוח לאפליקציות Full Stack. כל שינוי כזה הוא רעידת אדמה וזה קשה במערכות גדולות להתבסס על פריימוורק שמשתנה בצורה כל כך דרסטית כל כך מהר.

קשה מאוד להבין את ריאקט היום מחוץ לקונטקסט של next. כתבתי כאן על הסירבול בפונקציה use בגלל הצורך להעביר את ה Promise מבחוץ והבעיה ביצירת Promise מתוך קומפוננטות. עכשיו בואו נראה את הסיפור במשקפיים הנכונות של next ונראה למה בשימוש מלא של הפיצ'ר אין שום בעיה.

בונים אפליקציית Client Side בלבד ב React? תשמחו לשמוע שאתם יכולים לעשות את זה עם next.js גם בלי להשתמש בשרת שלהם, ולבנות את האפליקציה בדיוק כמו שבונים אפליקציית vite רגילה. יותר מזה, עם next אתם כבר מקבלים Router צד לקוח ויכולת לשדרג בעתיד לאפליקציית נקסט הכוללת גם שרת. בואו נראה איך זה עובד.

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

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

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

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

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

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

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

אני חוזר לדבג את התקלה של המייל שלא נשלח. אצלי בפיתוח הכל עובד אז אני מנסה להריץ את התהליך ידנית ומקבל את הודעת השגיאה:

Template contains unsupported operations

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

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

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

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

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

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

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

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