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

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

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

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

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

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

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

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

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

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

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

הבעיה שגילוי מה לעשות בזמן ריצה הולך נגד הרעיון של Type Safety - כי אם אני לא יודע מה יש לי ביד, איך אני יודע שמותר לי לעשות איתו את מה שרציתי לעשות.

לדוגמה נניח שאני קורא אוביקט מ local storage ואני חושב שהוא מכיל מחרוזת שהיא ייצוג JSON-י של אוביקט שיש בו שני שדות מספריים עם המפתחות x ו y. הקוד הבא ב JavaScript קורא את האוביקט הזה ומדפיס את סכום המספרים:

const stringifiedValue = localStorage.getItem('value');
const parsedValue = JSON.parse(stringifiedValue);
const sum = parsedValue.x + parsedValue.y;

console.log(`sum = ${sum}`);

אבל כשאדון טייפסקריפט קורא את הקוד הזה הוא חוטף חום: איך אתה יודע, הוא צועק עליי, שבאמת יש ב local storage אוביקט עם המפתח שכתבת? ואיך אתה יודע שהערך הוא באמת מחרוזת שתצליח לתרגם אותה ל JSON? ואם כבר פיענחת אותה ל JSON, איך אתה יודע שלאוביקט שקיבלת יש שדות בשם x ו y והם מספרים?

בתרגום ל TypeScript אני צריך להרגיע את כל הדאגות. ניסיון ראשון שלא עובד עשוי להיראות כך:

type TwoNumbers = { x: number, y: number };

const stringifiedValue = localStorage.getItem('value');
const parsedValue: TwoNumbers = JSON.parse(stringifiedValue);
const sum = parsedValue.x + parsedValue.y;

console.log(`sum = ${sum}`);

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

import './style.css'

type TwoNumbers = { x: number, y: number };

const stringifiedValue = localStorage.getItem('value');
if (stringifiedValue) {
  const parsedValue: TwoNumbers = JSON.parse(stringifiedValue);
  const sum = parsedValue.x + parsedValue.y;

  console.log(`sum = ${sum}`);
}

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

עבודה חכמה יותר עם טיפוסים תכריח אותנו לבדוק מה באמת פירססנו ושהוא באמת מתאים לטיפוס שלנו. בשביל זה הכי קל לעטוף את JSON.parse:

import './style.css'

type TwoNumbers = { x: number, y: number };

function safeJsonParse(text: string): unknown {
  return JSON.parse(text)
}

const stringifiedValue = localStorage.getItem('value');
if (stringifiedValue) {
  const parsedValue: TwoNumbers = safeJsonParse(stringifiedValue);
  const sum = parsedValue.x + parsedValue.y;

  console.log(`sum = ${sum}`);
}

כבר התקדמנו! עכשיו טייפסקריפט כבר כועס על ההשמה מ JSON.parse ל parsedValue בגלל שלא בדקנו שהאוביקטים מתאימים. בשביל הבדיקה אני יכול להגדיר פונקציה נפרדת:

type TwoNumbers = { x: number, y: number };

function safeJsonParse(text: string): unknown {
  return JSON.parse(text)
}

function isTwoNumbers(value: any): value is TwoNumbers {
  return (
    'x' in value &&
    typeof value.x === 'number' &&
    'y' in value &&
    typeof value.y === 'number'
  )
}

const stringifiedValue = localStorage.getItem('value');
if (stringifiedValue) {
  const parsedValue = safeJsonParse(stringifiedValue);
  if (isTwoNumbers(parsedValue)) {
    const sum = parsedValue.x + parsedValue.y;
    console.log(`sum = ${sum}`);
  }
}

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

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

price = float(input("Original price is: "))
price_after_discount = price * 0.9

print(f"After coupon discount you'll pay {price_after_discount}")

והפעלה לדוגמה תקינה היא:

$ python removedollar.py
Original price is: 15
After coupon discount you'll pay 13.5

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

Original price is: $10
Traceback (most recent call last):
  File "/Users/ynonp/tmp/blog/removedollar.py", line 1, in <module>
    price = float(input("Original price is: "))
ValueError: could not convert string to float: '$10'

מה עושים?

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

לא חשבתי על זה שאלמנט יכול להתכווץ אם הוא בתוך flex-box כי ברירת המחדל של flex-shrink היא 1.

לא חשבתי על זה שכמות השאילתות שכתבתי תלויה במספר השורות בטבלה.

לא חשבתי שקובץ הלוג יגיע לכזה גודל.

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

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

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

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

אני יכול להעביר חיים שלמים בכתיבת יישומי ריאקט בלי להשתמש ב Context, בלי Code Splitting, בלי Class Components, בלי CSS in JS ובלי עוד עשרות פיצ'רים שלו, וכך עם עוד טכנולוגיות רבות נוספות. הפער בין קורס לתיעוד הוא תמיד גדול וכך הוא צריך להיות.

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

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

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

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

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

type Letter<Word extends string, R extends string[] = []> = 
  Word extends `${infer H}${infer T}` ? Letter<T, [...R, H]> : R[number];

// works! h is one of the letters in "hello"
const x: Letter<"hello"> = "h";

// compilation error! x is not one of the letters in "hello"
const y: Letter<"hello"> = "x";

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

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

הטיפוס מוגדר בתור Conditional Type. זה אומר שאם Word באמת מתאים לצורה:

`${infer H}${infer T}`

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

// compiles OK
const a: "a" = "a";

// compilation error - expecting only the letter "a"
const b: "a" = "b";

לכן H יהיה טיפוס של האות הראשונה במחרוזת, ו T יהיה טיפוס של מחרוזת שמורכבת מכל האותיות פרט לראשונה. המילה hello מתאימה לזה ועבורה ה H יהיה האות h קטנה וה T יהיה המחרוזת ello.

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

Letter<T, [...R, H]>

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

Letter<"hello", []> => Letter<"ello", ["h"]>

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

Letter<"", ["h", "e", "l", "l", "o"]>

ואז מגיעים לחלק שאחרי הנקודותיים:

R[number]

בגלל ש R הוא מערך עם אותיות שידועות כולן בזמן קומפילציה, אנחנו יכולים לדבר על הטיפוס R[0] שהוא האות h, או הטיפוס R[1] שהוא האות e. אנחנו גם יכולים לדבר על הטיפוס R[number] שהוא איחוד של כל האותיות במערך, כי number יכול להתאים לכל מספר שהוא אינדקס חוקי במערך.

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

את הרעיון קיבלתי מוויליאם קנדילון, ואתם מוזמנים להמשיך לראות אותו גם בוידאו בו הוא בונה משחק וורדל שלם בעזרת טיפוסים בטייפסקריפט: https://www.youtube.com/watch?v=JT30j4nhej4

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

ומחכות.

ומחכות.

ומחכות.

יש מעל 30 מיליון הורדות בשבוע של טייפסקריפט, אבל רק 4,000 אנשים צפו בהרצאת הפתיחה מכנס TSConf האחרון.

בריאקט היחס יותר טוב - להם יש 16 מיליון הורדות בשבוע וכמעט 80 אלף צפיות בהרצאת הפתיחה של כנס React Conf האחרון. ואלה עדיין מספרים מאוד קטנים.

גם אם נסתכל רק על מספרים בתוך יוטיוב התמונה נשארת דומה. לקורס ריאקט למתחילים של Free Code Camp יש מיליון וחצי צפיות. עוד חמש מיליון צפיות הלכו ל mosh בקורס React For Beginners שלו, ו Ben Awad משך מיליון וחצי צפיות לראיון העבודה בריאקט שהוא העביר לקלמנט מיולשקו.

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

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

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

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

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

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

הצד השני של האתר, קוד ריילס שמפעיל אותו, קיבל ממני רוב השנים כתף קרה, ואפילו תיפקד בתור שפן ניסיונות שלי בלימוד טכנולוגיות: כתבתי מחדש את שיכבת ה Front End עם ריאקט ו react router בתור Single Page Application; אחרי זה החלפתי אותו בראוטר שלי שסינכרנתי לבד עם שרת הריילס; בדרך הקשה למדתי על האתגרים ב Server Side Rendering ואיך לפתור את רובם; מה זה Cache ואיך לבנות אחד ואיך לנהל נכון משימות רקע.

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

1. לבנות מערכת שצריכה הרבה פחות תחזוקה, ושהתחזוקה שלה תהיה קלה. זה אומר פחות JavaScript ופחות תלויות.

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

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

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

5. לרענן את העיצוב שיתאים לשנת 2022.

6. לסדר את מערכת ה Deployment כדי לקבל Zero Downtime Deployments רצוי דרך שרת CI/CD.

התחלתי את הפרויקט במרץ בעזרת מעצב אוקראיני, מתכנת מבנגלדש ועוד מתכנת מהודו. הבחירה לעבוד עם פרילאנסרים מהצעד הראשון היתה הדרך לוודא שיהיה קל לאנשים אחרים להיכנס ולעזור בקידוד. מבחינת הטכנולוגיות נפרדתי מריאקט ומכל מה שקשור ל Single Page Application ועברתי לריילס נקי עם erb-ים כמו פעם. גם ב CSS ויתרתי על קבצי ה CSS הענקיים של האתר הנוכחי ועברתי ל Tailwind CSS, כדי שכל דף יעמוד בפני עצמו ויהיה יותר קל לשנות עיצוב של דף מסוים בלי לשבור את כל האתר. וכמובן באיחור של שנתיים גם אצלנו יהיה "מצב חשוך" לטובת אלה שאוהבים לקרוא במיטה בחושך.

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

https://v2.tocode.co.il/

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

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

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

עבודה עם ריאקט נייטיב יכולה להיות מבלבלת מכמה סיבות:

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

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

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

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

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

פרטים נוספים והרשמה בדף הוובינר בקישור: https://www.tocode.co.il/workshops/118

נתראה בחמישי בבוקר.