ToCode

קומפוננטות ווב Web Components עובדים ממש טוב הרבה זמן שמרתי מרחק מ Web Components כי היה ריאקט ו vue ולא בטוח כמה תמיכה טובה היתה להם והיו ריבים וכל מיני שטויות. אם גם אתם איכשהו פספסתם את מה שקרה ברשת בשנים האחרונות תשמחו לשמוע שבתחום של Web Components כל הסיפור נפתר והיום הם עובדים די טוב. נכון הם לא נותנים את כל מה שריאקט נותנת והם דורשים הרבה עבודה ידנית בעיקר בחיבור קוד לטיפול באירועים, אבל אין לי ספק שאם הם היו קיימים ב 2015 לא היו לנו את כל ה JavaScript Frameworks שאנחנו רואים היום (או מצד שני, אולי רק בזכות ריאקט וחבריו כותבי התקנים הצליחו להגיע להסכמה על Web Components). בכל מקרה כתבתי דוגמה קטנה של מונה לחיצות ב Web Component בשביל לשחק עם ה API. ה HTML הוא:

<my-counter></my-counter>
<my-counter></my-counter>
<my-counter></my-counter>

<template id="counter">
  <p>I'm a counter. value = <span class="value">0</span>
    <button class="inc">+1</button>
    <button class="dec">-1</button>
  </p>
</template>

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

customElements.define(
  "my-counter",
  class extends HTMLElement {
    connectedCallback() {
      let template = document.getElementById("counter");
      let templateContent = template.content;
      const shadowRoot = this.attachShadow({ mode: "open" });
      
      shadowRoot.appendChild(templateContent.cloneNode(true));
      
      let value = 0;
      const valueSpan = shadowRoot.querySelector('.value')
      shadowRoot.querySelector('.inc').addEventListener('click', () => {
        value += 1;
        valueSpan.textContent = value;
      })
      
      shadowRoot.querySelector('.dec').addEventListener('click', () => {
        value -= 1;
        valueSpan.textContent = value;
      })
    }
  }
);

וכן צריך ידנית לקחת את הטמפלייט, לשכפל אותו ולהוסיף אותו ל DOM ואז להגדיר את קוד הטיפול לכפתורים. אין מנגנון מובנה של State ו Props וכל ה Virtual DOM שאנשים רגילים לראות, אבל כן יש מידול והפרדה בין קוד הקומפוננטה לקוד של קומפוננטות אחרות ואפשר גם להפריד את העיצוב מהעיצוב הכללי של העמוד ולהדביק קובץ CSS ספציפי לקומפוננטה. גירסה 19 של ריאקט שתבוא עלינו לטובה באזור יוני או יולי כוללת לפי הסיפורים תמיכה מלאה ב Web Components כך שנוכל לשלב אותם ביישום ריאקט בלי בעיה. יהיה מעניין. נ.ב. זה הלינק לקודפן עם הקומפוננטת ווב, תרגישו חופשי לשחק ולשבור: https://codepen.io/ynonp/pen/qBGWQEw

אני כזה מקסים פשוט תנו לי את העבודה למה תהליכי גיוס בהייטק כל כך ארוכים? למה כל כך קשה למצוא עבודה? למה ראיונות עבודה כל כך מתישים? למה אני נבחן בשאלות "ראיונות עבודה" שאף אחד בחברה לא יודע לפתור? אני הרי כזה מקסים - למה שלא תתנו לי פשוט את העבודה? דרן קופ כותב אחרי שנכשל בראיון: > I understand the problems associated with hiring the wrong people as well, which may well be the actual reason we are rightfully stuck with such fearful/timid hiring practices. ובמקום אחר באותו פוסט הוא מספר על אחד האתגרים בגיוס לא נכון: > I’ve also spent hours fixing code that had issues directly stemming from not using the correct data structure/algorithm that I may not have had to if we had been better at screening the employees during the interview process. אני חושב שזה החלק הכי קטן בסיפור. כן גיוס אנשים לא נכונים יכול להביא לקוד לא אופטימלי ולחייב סבבים של Refactoring על דברים שאולי היה אפשר לראות קודם. אבל בסוף ריפקטורינג תמיד יקרה ולשפר תמיד אפשר. תהליכי עבודה טובים יכולים לעזור והרבה פעמים כשאנחנו מכניסים מתכנתים בינוניים למקומות עבודה טובים הם משתפרים בזכות תהליכי העבודה באותם מקומות, תהליכים שכוללים הכשרות, Code Reviews ובעלות על מוצר. האנשים שאנחנו רוצים לסנן החוצה בתהליך הגיוס הם לא אלה שכותבים קוד גרוע מחוסר ידע. אלה כמה בעיות לדעתי יותר משמעותיות בגיוס גרוע- 1. גיוס אנשים שפשוט מדביקים קוד מ Stack Overflow או מנועי AI בלי להבין מה הם כותבים וכתוצאה מכך מייצרים ערימות בוץ שאי אפשר לנקות. 2. גיוס אנשים שיתווכחו על כל דבר וימצאו עשרות סיבות למה לא לעשות, כשרק הוויכוח לוקח יותר זמן ממה שהיה צריך בשביל לפתור את הבאג או לתת פיתרון מהיר ללקוח. 3. גיוס אנשים שיגרמו לכל האחרים להרגיש טפשים, לא יהיו מוכנים להקשיב ותמיד ימצאו מישהו אחר להאשים. 4. גיוס אנשים שמתעקשים על טכנולוגיה ספציפית או שיטת עבודה ספציפית ולא יכולים או רוצים לנסות גישה אחרת. 5. גיוס אנשים שבטוחים שתהליכי העבודה הארגוניים רק מאטים אותם ולכן ימצאו דרכים "לקצר תהליכים" על חשבון איכות. קיצור שנשלם עליו את המחיר בעוד חודשים או שנים. אפילו גיוס גרוע אחד יכול להרוס מוצר, וכמעט תמיד כשאנחנו מבינים שעשינו טעות זה כבר מאוחר מכדי לתקן. הלוואי שהיתה דרך קלה לחזות את העתיד אבל בינתיים ראיונות עבודה מתישים הם המנגנון הכי פחות רע שמצאנו.

היום למדתי: למה לשים מרכאות מסביב לפורטים ב docker-compose בואו נשחק עם רובי, כי היא קלה ויש תמיכה מובנית ב YAML. זאת התוכנית:

require 'yaml'
require 'pp'

data = YAML.safe_load(<<-END
  apache:
  image: httpd:latest
  container_name: my-apache-app
  ports:
    - 80:80
    - 24:42
  volumes:
    - ./website:/usr/local/apache2/htdocs
END
)

pp data

אפשר לראות אותו לייב ב URL הזה: https://tinyurl.com/mwk97ybd עכשיו התוכנית בסך הכל לוקחת YAML, קוראת אותו ומדפיסה אותו כמילון. יכולים לנחש מה יהיה במפתח ports של המילון? רמז: לא מה שאתם חושבים. זה נראה ככה:

"ports"=>["80:80", 88920],

אני מבין מאיפה הגיע ה 80:80, אבל מה הסיפור עם ה 88920? מה קרה ל 24:42? נו התשובה בכותרת הפוסט. כשקוראים YAML שיש בו שני מספרים נקודותיים ואז עוד שני מספרים המפענח חושב שזה תיאור זמן (שעות ודקות). אז הוא מכפיל את 24 ב 60 ומוסיף 42 וכך מקבל 1482, ואז הופך את זה לשניות ומקבל 88920 שזה המספר שאנחנו רואים כאן. מה עושים? נזכרים ש YAML הוא שדה מוקשים אחד גדול ותמיד כותבים מחרוזות בתוך מרכאות.

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

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

export function TopProducts() {
    const {data} = useSWR('/top-products');
    // render the list
    return <>...</>
}

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

export function TopProducts() {
    const topProducts = useSelector(state => state.topProducts);
    // render the list
    return <>...</>;
}

כשאנחנו מתרכזים בקומפוננטה קל לכל מפתח להוסיף קומפוננטת פרסומת כזאת לכל דף באתר וכשמוחקים את כל הקרוסלות מדף אוטומטית הדף מפסיק למשוך את הרשימה מהשרת. אבל בלי טיפול מיוחד המנגנון הזה יביא לאפקט מפל מים במשיכת המידע, כשרק כשקומפוננטת הקרוסלה מתרנדרת מתחילים למשוך את המידע שהיא צריכה (וכך גם לגבי כל הקומפוננטות האחרות שצריכות מידע מהשרת), מה שפוגע בביצועים. כשאנחנו מתרכזים בכל דף ומושכים את כל המידע שהדף צריך בכניסה אליו קל מאוד למקבל בקשות וכך למשוך את כל המידע שכל הקומפוננטות צריכות במכה אחת, אבל הוספה של קומפוננטה דורשת שינוי של המידע הגלובאלי ומשיכה של יותר מידע. שיפור ביצועים על חשבון חווית פיתוח. וזה הטרייד אוף שבריאקט לא מצליחים לצאת ממנו, המעגל שכולם מנסים לרבע. אז לרמיקס יש מנגנון שאוטומטית אוסף את כל משיכות המידע (ה loaders) מכל הילדים כדי לנסות למקבל אותם, ו React Server Components ו next מנסים לבטל לגמרי את קריאות ה API בעלייה כי הכל יתרנדר על השרת, אבל זה בסך הכל להזיז את הבעיה מצד לצד. בסוף יש לנו בעיה מהותית במודל ו Trade Off אמיתי שצריך להחליט לגביו: חווית פיתוח או ביצועים.

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

ומה אם שתי קומפוננטות מקשיבות לאותו SSE ? כשהייתי צריך לכתוב קומפוננטת ריאקט שמקשיבה ל Server Sent Events ומעדכנת את התצוגה לפי האירוע שמגיע האינטואיציה הראשונה שלי היתה להוסיף אפקט:

useEffect(() => {
  const evtSource = new EventSource("/notifications");
  const handler = (e: MessageEvent) => {
    setPosts(p => [...p, JSON.parse(e.data)]);
  };
  evtSource.addEventListener('message', handler);

  return () => {
    evtSource.close();
  }
}, []);

ואז העולם הגיע והיה צריך לעדכן קומפוננטה נוספת כשרשימת הפוסטים מתעדכנת. עכשיו מה עושים? התשובה כשצריך לשתף מידע בין קומפוננטות היא תמיד זהה - שומרים את המידע במקום מרכזי ברמת האפליקציה (מה שנקרא Store) וכל קומפוננטה לוקחת משם את המידע. דרך אחת לבנות State גלובאלי לאפליקציה היא לשלב פריימוורק כמו רידאקס (או Jotai או preact-signals או zustand או אפילו מובאקס). פריימוורק לניהול סטייט מכריח אותי לכתוב את הקוד שמתחבר ל SSE Endpoint ולהחליט איפה יישמר המידע ומתי מפסיקים להקשיב לאירועים. דרך שנייה לבנות State גלובאלי היא לשים את המידע ב Context ולמשוך אותו דרך Hook. הרבה פעמים נראה את הפיתרון הזה ב Hooks מוכנים, למשל use-event-source. אני מדביק כאן את הקוד שלו כי זה מעניין:

import { createContext, useContext, useEffect, useState } from "react";

export interface EventSourceOptions {
 init?: EventSourceInit;
 event?: string;
}

export type EventSourceMap = Map<
 string,
 { count: number; source: EventSource }
>;

const context = createContext<EventSourceMap>(
 new Map<string, { count: number; source: EventSource }>(),
);

export const EventSourceProvider = context.Provider;

/**
 * Subscribe to an event source and return the latest event.
 * @param url The URL of the event source to connect to
 * @param options The options to pass to the EventSource constructor
 * @returns The last event received from the server
 */
export function useEventSource(
 url: string | URL,
 { event = "message", init }: EventSourceOptions = {},
) {
 let map = useContext(context);
 let [data, setData] = useState<string | null>(null);

 useEffect(() => {
  let key = [url.toString(), init?.withCredentials].join("::");

  let value = map.get(key) ?? {
   count: 0,
   source: new EventSource(url, init),
  };

  ++value.count;

  map.set(key, value);

  value.source.addEventListener(event, handler);

  // rest data if dependencies change
  setData(null);

  function handler(event: MessageEvent) {
   setData(event.data || "UNKNOWN_EVENT_DATA");
  }

  return () => {
   value.source.removeEventListener(event, handler);
   --value.count;
   if (value.count <= 0) {
    value.source.close();
    map.delete(key);
   }
  };
 }, [url, event, init, map]);

 return data;
}

ה Hook יוצר מפה גלובאלית של Event Listeners שמקשיבים לאירועים לפי ה URL. כל פעם שקומפוננטה צריכה להתחבר ל SSE Endpoint הנתיב מצטרף למפה ואם הוא כבר קיים שם אז ערך ה count עולה ב-1. כשאף קומפוננטה לא מקשיבה לאירועים ה SSE נסגר ונמחק מהמפה. השימוש ב Hook נראה כך (מתוך הדוגמה שלהם ב Readme):

// app/components/counter.ts
import { useEventSource } from "remix-utils/sse/react";

function Counter() {
 // Here \/sse/time\ is the resource route returning an eventStream response
 let time = useEventSource("/sse/time", { event: "time" });

 if (!time) return null;

 return (
  <time dateTime={time}>
   {new Date(time).toLocaleTimeString("en", {
    minute: "2-digit",
    second: "2-digit",
    hour: "2-digit",
   })}
  </time>
 );
}

עבודה עם מידע בינארי ב JavaScript מערכים בינאריים מזמן נכנסו לשפת JavaScript ויכולים לעזור לנו בפיתוח קוד צד שרת וגם צד לקוח. אלה העקרונות המרכזיים שצריך להכיר בעבודה איתם. מערכים ב JavaScript התקן של JavaScript מגדיר שני מבנים שחשוב להכיר. הראשון הוא Buffer שזה אוסף של ביטים בזיכרון, והשני הוא Typed Array, שזה ממשק שעוטף את ה Buffer ומאפשר לנו לגשת לביטים כשאנחנו מתיחסים אליהם בתור מספרים. חוצץ יש רק אחד אבל Typed Arrays יש הרבה לפי סוגי המידע שיכולים להיות שמורים בחוצץ: הרבה ממשקים של Deno ו Node יחזירו לכם Buffer ואתם תצטרכו לבנות מערך של בתים סביבו כדי לגשת אליו. אפשר גם ליצור Buffer בצורה ידנית כדי לראות איך המערכים השונים ניגשים לאותו מידע. בואו ננסה את זה, אפשר בחלון Console של דפדפן או ב REPL של דינו:

> const buffer = new ArrayBuffer(16);
> buffer.byteLength
16

// create arrays around the buffer
> const a = new Uint8Array(buffer)

// or around just part of the buffer
> const b = new Uint8Array(buffer, 0, 4)
> const c = new Uint16Array(buffer)
> const d = new Float32Array(buffer)

// look at the sizes
a.length === 16
b.length === 4
c.length === 8
d.length === 4

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

d[0] = 2.5

// a is:
0, 0, 32, 64, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

// b is:
0, 0, 32, 64

// c is:
0, 16416, 0, 0, 0, 0, 0, 0

// d is:
2.5, 0, 0, 0

הסיבה היא שאותם הביטים שמייצגים את המספר 2.5 במערך של Float מייצגים מספרים אחרים במערך של Int-ים. בדרך כלל אנחנו ניצור רק מערך אחד מסביב ל Buffer לפי צורת העבודה שהכי מתאימה לקוד שנכתוב. בניית מערך של בתים ראינו איך לבנות מערך של בתים מתוך Buffer אבל האמת שאפשר לבנות את שני הדברים ביחד עם הבנאי של המערך. הקוד הבא בונה מערך של 10 בתים וחוצץ באותו גודל:

const a = new Uint8Array(10)

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

a[0] = 1
a[1] = 2

עוד כמה פונקציות ששווה להכיר: 1. fill - מקבל ערך ומכניס אותו לכל התאים במערך. 2. at - מחזיר איבר מהמערך ותומך באינדקסים שליליים כדי לקבל איברים מהסוף 3. slice - מחזיר מערך חדש שמכיל רק חלק מסוים מהמערך 4. with - מחזיר מערך עם עדכון לתא בודד באינדקס שבחרנו דוגמה לשימוש בפוקנציות אלה:

> const a = new Uint8Array(8)
undefined
> a.fill(4)
Uint8Array(8) [
  4, 4, 4, 4,
  4, 4, 4, 4
]

> const b = a.slice(0, 4)
undefined
> a[0] = 10
10
> b
Uint8Array(4) [ 4, 4, 4, 4 ]

const c = a.with(0, 99);

> a
Uint8Array(8) [
  10, 4, 4, 4,
   4, 4, 4, 4
]
> b
Uint8Array(4) [ 4, 4, 4, 4 ]
> c
Uint8Array(8) [
  99, 4, 4, 4,
   4, 4, 4, 4
]

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

create(o: object | null): any;

ורגע אם כבר הגדרנו את create אפשר להמשיך לרוץ עם אותו רעיון ולהגדיר גם את:

setPrototypeOf(o: any, proto: object | null): any;

ויש עוד כמה הגדרות שאפשר למצוא ב es5.d.ts שהמשותף לכולן הוא ה object | null. בעצם יש רק מקום אחד ש object מופיע בלי החיבור ל null וזה הטיפוס של הפונקציה Object.keys:

keys(o: object): string[];

אבל בניגוד למופעים האחרים פה אפשר לטעון שהטעות היא דווקא של טייפסקריפט, כי אין בעיה להפעיל keys גם על פרימיטיבים (לא שזה מועיל אבל זה כבר סיפור אחר). בחזרה לאתגר שלנו - למה null הוא לא חלק מ object? למה להגדיר טיפוס חדש כשכל פעם שמשתמשים בו זה כחלק מהחיבור object | null? התשובה ברורה כשנזכרים בגישה של JavaScript לסיפור. ב JavaScript הפקודה הזו מחזירה ערך אמת:

typeof null === 'object'

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

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

create(o: object | null): any;

ורגע אם כבר הגדרנו את create אפשר להמשיך לרוץ עם אותו רעיון ולהגדיר גם את:

setPrototypeOf(o: any, proto: object | null): any;

ויש עוד כמה הגדרות שאפשר למצוא ב es5.d.ts שהמשותף לכולן הוא ה object | null. בעצם יש רק מקום אחד ש object מופיע בלי החיבור ל null וזה הטיפוס של הפונקציה Object.keys:

keys(o: object): string[];

אבל בניגוד למופעים האחרים פה אפשר לטעון שהטעות היא דווקא של טייפסקריפט, כי אין בעיה להפעיל keys גם על פרימיטיבים (לא שזה מועיל אבל זה כבר סיפור אחר). בחזרה לאתגר שלנו - למה null הוא לא חלק מ object? למה להגדיר טיפוס חדש כשכל פעם שמשתמשים בו זה כחלק מהחיבור object | null? התשובה ברורה כשנזכרים בגישה של JavaScript לסיפור. ב JavaScript הפקודה הזו מחזירה ערך אמת:

typeof null === 'object'

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