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

בעבודה על פרויקט Node.JS לבחירה בטייפסקריפט יש גם יתרונות וגם חסרונות עליהם נדבר בשיעור זה.

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

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

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

3. אפשר לקבל תוצאות טובות ובזול עם VPS או שרתים פיזיים - לינוד עדיין משכירים שרת VPS זול ב 5 דולר בחודש, ומכונות טובות ב 40$ בחודש. כן, נצטרך לעבוד קשה בשביל לקבל High Availability במובן שאם Region שלם נופל המערכת אוטומטית תתחיל לעבוד מ Region אחר או מ VPS אחר, אבל גם זה אפשרי ובכל מקרה לעסקים קטנים לא בטוח כמה זה הכרחי.

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

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

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

לא מזמן נתקלתי בטריק החמוד הזה בריאקט שרציתי לשתף, לא בשביל שתשתמשו בו בפרודקשן אלא יותר כ Proof Of Concept, כדי להבין עוד דבר או שניים על פורטלים ו ref.

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

אתם כבר יודעים להשתמש ב useEffect כדי להריץ קוד כשמשהו משתנה, ולהשתמש ב useRef כדי לתפוס אלמנט ב DOM אחרי render, אבל בשילוב בין השניים יש טעות שמאוד קל לעשות. בואו נראה קצת קוד.

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

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

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

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

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

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

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

כתובת אינטרנט יכולה להכיל פרמטרים אחרי סימן שאלה שמגיעים בפורמט של שם הפרמטר ואז סימן שווה ואז הערך שלו - למשל בכתובת הבאה יש שני פרמטרים בשמות foo ו bar עם הערכים 10 ו 20:

http://www.tocode.co.il?foo=10&bar=20

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

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

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

3. פונקציית set שמעדכנת ערך של פרמטר ומשאירה רק מופע אחד שלו.

את שאר הפונקציות אפשר למצוא בתיעוד כאן: https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams

בעזרת אותן פונקציות אני יכול לשלוף ולהדפיס את הערכים של foo ו bar מהכתובת הקודמת:

const url = new URL("http://www.tocode.co.il?foo=10&bar=20");

> url.searchParams.get('foo')
'10'

> url.searchParams.get('bar')
'20'

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

> url.searchParams.set('foo', 'new value')
> url.searchParams.set('newKey', 12)

> url.toString()
'http://www.tocode.co.il/?foo=new+value&bar=20&newKey=12'

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

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

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

אולי. אבל יש עוד אפשרויות-

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

אולי הדרך השניה באמת יותר טובה?

אולי היכרות עם עוד דרך תעזור לך להבין טוב יותר את הקוד של הדרך הראשונה?

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

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