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

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

אני תמיד אוהב כששפת תכנות לוקחת עוד צעד בכיוון הפונקציונאלי, וזה יהיה הסיפור היום עם שתי פונקציות חדשות ב JavaScript - הפונקציות toReversed ו toSorted, הגירסאות הפונקציונאליות של reverse ו sort. בעוד שהפונקציות המקוריות שינו את מבנה הנתונים, הגירסאות החדשות שלהן מחזירות לנו עותק של מבנה הנתונים ממוין או הפוך.

הפונקציה reverse של JavaScript מופעלת על מערך והופכת את האיברים בו:

> const x = [1, 2, 3, 4];
undefined
> x.reverse()
[ 4, 3, 2, 1 ]

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

> const x = [1, 2, 3, 4]
undefined
> x.toReversed()
[ 4, 3, 2, 1 ]
> x
[ 1, 2, 3, 4 ]

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

> const x = [{a: 10}, {a: 10}, {a: 20}, {a: 30}]
undefined
> x.toReversed()
[ { a: 30 }, { a: 20 }, { a: 10 }, { a: 10 } ]
> x.toReversed()[0].a = 40
40
> x
[ { a: 10 }, { a: 10 }, { a: 20 }, { a: 40 } ]

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

> const values = [1, 10, 21, 2];
undefined

> values.toSorted()
[ 1, 10, 2, 21 ]

> values.toSorted((a, b) => a - b)
[ 1, 2, 10, 21 ]

אפשר לחשוב על שתיהן בתור גירסה מהירה וברורה יותר של array.slice().reverse() ו array.slice().sort:

> x.slice().reverse()
[ 9, 1, 2, 10 ]
> x
[ 10, 2, 1, 9 ]

> x.slice().sort()
[ 1, 10, 2, 9 ]
> x
[ 10, 2, 1, 9 ]

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

1. בחרו חבר או חברה עם רקע שונה משלכם. המטרה של Pair Programming היא לא לכתוב קוד כמה שיותר מהר אלא לדבר על הדברים המשמעותיים בתהליך הפיתוח. ככל שיש פער ברקע שלכם אפשר יהיה לקבל נקודת מבט נוספת ומעניינת על הארכיטקטורה.

2. בחרו טכנולוגיות אותן לפחות אחד הצדדים מבין או מבינה היטב. המטרה של Pair Programming היא הדיון, אז אנחנו רוצים לצמצם זמני Debug וזמני חיפוש באינטרנט.

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

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

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

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

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

ואם אנחנו כבר מריצים מערכת עם Docker Compose, מדי פעם אנחנו צריכים גם להעלות גירסה חדשה של אחד האימג'ים. בדיוק בשביל זה נוצר Watchtower.

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

איך זה עובד? יחסית פשוט. Watchtower הוא סרביס שאנחנו מוסיפים ל docker-compose.yml, אפשר בנוסף לסרביס שלנו או בקומפוז אחר לגמרי:

version: "3"
services:
  cavo:
    image: ynonp/myapp:latest
    ports:
      - "443:3443"
      - "80:3080"
  watchtower:
    image: containrrr/watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --interval 30

כן צריך לשים לב ל-3 נקודות שאפשר ליפול בהן:

1. אם האימג' שמור ברגיסטרי פרטי אז צריך להעביר פנימה לתוך הקונטיינר של watchtower את פרטי ההתחברות, בדרך כלל בצורת מיפוי הקובץ config.json של דוקר פנימה לתוך הקונטיינר.

2. האינטרוול קובע כל כמה זמן צריך לבדוק אם קיימת גירסה חדשה של האימג'. ברירת המחדל היא פעם ביום אז בשביל מנגנון של דיפלוימנט ב CI/CD כדאי להוריד את זה. המספר 30 בדוגמה מציין 30 שניות.

3. אם לא כתבתם אחרת ה watchtower יעדכן את כל האימג'ים בכל הקונטיינרים שרצים על המכונה. אפשר לסנן קונטיינרים אם נעביר אחרי האינטרוול את שם הקונטיינר שאנחנו רוצים לעדכן (שימו לב שזה שם הקונטיינר לא שם הסרביס בקומפוז), או שיטה יותר פשוטה לדעתי היא להגדיר label על כל קונטיינר שצריך עדכון. נשים לב שאם יש לנו מספר פרויקטים שונים עם קבצי docker-compose שונים אז עדיין watchtower של אחד עשוי לשדרג קונטיינרים של הפרויקט השני.

סך הכל שילוב שלושת הסעיפים מביא אותנו ל docker-compose.yml שנראה בערך כך:

services:
  db:
    image: postgres:16.3
    volumes:
      - ./tmp/db:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: ${DBPASSWORD}

  watchtower:
    image: containrrr/watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /home/ynon/.docker/config.json:/config.json
    command: --interval 30 --label-enable

  web:
    image: my.private.registry.com/webapp:latest
    labels:
      com.centurylinklabs.watchtower.enable: true
    environment:
      DATABASE_PASSWORD: ${DBPASSWORD}
      DATABASE_HOST: db
    ports:
      - "3000:3000"
    depends_on:
      - db

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

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

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

הקוד הבא בטייפסקריפט הצליח לבלבל אותי לרגע-

type MyItem = {type: 'a', url: string, id: number}

function go(item: MyItem) {}

const f = {type: 'a', url: 'url', id: 0}
go(f)

הוא לא מתקמפל.

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

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

const f: {
    type: string;
    url: string;
    id: number;
}

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

type MyItem = {type: 'a', url: string, id: number}

function go(item: MyItem) {}

const f = {type: 'a', url: 'url', id: 0}
f.type = 'b';

כשטייפסקריפט רואה את הקריאה:

go(f)

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

איך פותרים את זה? אז מסתבר שיש כמה דרכים - קודם כל אפשר להגיד לטייפסקריפט בצורה מפורשת מה הטיפוס של f:

type MyItem = {type: 'a', url: string, id: number}

function go(item: MyItem) {}

const f: MyItem = {type: 'a', url: 'url', id: 0}

עכשיו אפשר יהיה להעביר אותו לפונקציה go ואי אפשר יהיה לשנות את הערך של f.type.

עוד אופציה היא להגדיר ש type הוא קבוע בתוך הגדרת האוביקט:

const f = {type: 'a' as const, url: 'url', id: 0}

ודרך שלישית לקבל את אותו טיפוס היא להגדיר את type ממש להיות a:

const f = {type: 'a' as 'a', url: 'url', id: 0}

מכירים רעיונות נוספים? שתפו בתגובות אשמח לשמוע.

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

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

scala> Set(1, 2, 3).map(_ * 2)
val res1: Set[Int] = Set(2, 4, 6)

scala> List(1, 2, 3).map(_ * 2)
val res4: List[Int] = List(2, 4, 6)

קלוז'ר לעומתה שמה את הדגש על הפונקציה ולכן הפעלה של map על כל דבר מחזירה תמיד LazySeq:

user=> (type (map (partial * 2) #{1 2 3}))
clojure.lang.LazySeq
user=> (type (map (partial * 2) [1 2 3]))
clojure.lang.LazySeq

ו JavaScript מסכימה להגדיר map רק על רשימה ולכן:

new Set([1, 2, 3]).map(i => i * 2)
TypeError: new Set([1, 2, 3]).map is not a function. (In 'new Set([1, 2, 3]).map(i => i * 2)', 'new Set([1, 2, 3]).map' is undefined)

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

נ.ב. ומה מחזיר הקוד הבא ברובי? נסו לבדוק ותראו אם הבנתם למה:

3.1.1 :002 > [1, 2, 3].map { _ * 2 }

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

https://www.tocode.co.il/blog/2018-09-javascript-tco

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

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

הנה התוכנית:

function factors_of(number, i=2) {
    if (number < i) {
          return [];
        }

    if (number % i === 0) {
          return [i, ...factors_of(number / i, i)];
        }

    return factors_of(number, i+1);
}

console.log(factors_of(909090909090909090909090));

והרצה בצד שרת ב node:

node a.js
/Users/ynonp/tmp/a.js:1
function factors_of(number, i=2) {
                   ^

RangeError: Maximum call stack size exceeded
    at factors_of (/Users/ynonp/tmp/a.js:1:20)
    at factors_of (/Users/ynonp/tmp/a.js:10:12)
    at factors_of (/Users/ynonp/tmp/a.js:10:12)
    at factors_of (/Users/ynonp/tmp/a.js:10:12)
    at factors_of (/Users/ynonp/tmp/a.js:10:12)
    at factors_of (/Users/ynonp/tmp/a.js:10:12)
    at factors_of (/Users/ynonp/tmp/a.js:10:12)
    at factors_of (/Users/ynonp/tmp/a.js:10:12)
    at factors_of (/Users/ynonp/tmp/a.js:10:12)
    at factors_of (/Users/ynonp/tmp/a.js:10:12)

Node.js v21.7.1

ב Deno:

deno run a.js
error: Uncaught (in promise) RangeError: Maximum call stack size exceeded
function factors_of(number, i=2) {
                   ^
    at factors_of (file:///Users/ynonp/tmp/a.js:1:20)
    at factors_of (file:///Users/ynonp/tmp/a.js:10:12)
    at factors_of (file:///Users/ynonp/tmp/a.js:10:12)
    at factors_of (file:///Users/ynonp/tmp/a.js:10:12)
    at factors_of (file:///Users/ynonp/tmp/a.js:10:12)
    at factors_of (file:///Users/ynonp/tmp/a.js:10:12)
    at factors_of (file:///Users/ynonp/tmp/a.js:10:12)
    at factors_of (file:///Users/ynonp/tmp/a.js:10:12)
    at factors_of (file:///Users/ynonp/tmp/a.js:10:12)
    at factors_of (file:///Users/ynonp/tmp/a.js:10:12)

ורק bun מפתיע לטובה:

$ bun a.js
[
  2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
  71, 101, 251, 401, 9384251
]

נתונה קומפוננטת ריאקט:

function ItemData() {
    const { id } = useParams();
    const { data, error, isLoading } = useSWR('/api/user', fetcher);

    if (isLoading) return <p>Loading...</p>;
    if (error) return <p>Error</p>;

    return <ItemView item={data} />
}

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