ToCode

# הזמנה לוובינר: היכרות עם Solid.JS ריאן קרניאטו, היוצר של סוליד, העיד על עצמו שלקח לו הרבה זמן להבין מה אנשים מוצאים בריאקט ולהתאהב בפריימוורק בעצמו. עבורו הרגע המכריע היה החשיפה של React Hooks, שנתנו עדיפות לקומפוננטות פונקציונאליות ואיפשרו לארגן קוד לשימוש חוזר במקום אחד - בתוך Custom Hook - ואז להשתמש בו שוב ושוב במספר גדול של קומפוננטות. אבל בגלל איך שריאקט בנוי ל Hooks יש בעיה: כמעט כל Hook בריאקט חייב לקבל רשימת תלויות, בגלל שריאקט לא יודע "לראות" לבד את הקשר בין קוד לבין הדברים שהוא תלוי בהם. אותו חיבור שהוא הבסיס של מה שנקרא ריאקטיביות. במילים אחרות, כשקוד ריאקט רוצה ליצור אפקט על משתנה סטייט מסוים, למשל שכל פעם שמשתנה סטייט מסוים מתעדכן אז לעדכן אוטומטית את ה document.title, הוא יצטרך להיראות כך:

function useDocumentTitle(title) {
    useEffect(() => {
        document.title = title;
    }, [title]);
}

אבל הדיון על "רשימת התלויות" הולך הרבה יותר רחוק מאיך לבנות Custom Hooks בריאקט. אם נחשוב על זה, כל המהות של קומפוננטה זה להיות משהו שמתעדכן כש State או Props שלו מתעדכנים - ושוב יש לנו את משחק התלויות. מידע, ששמור בתור סטייט או פרופ, משפיע על הדבר שאנחנו רואים על המסך. הדרך שבה ריאקט מזהה ומעדכן את "התוצאות" כשהתלויות משתנות היא Virtual DOM. ריאקט שומר מבנה נתונים גדול של מה צריך להיות ומה קיים כרגע, ויודע לזהות הבדלים בין שני המצבים. כל פעם שתלות מסוימת משתנה ריאקט יחשב מחדש את ההבדלים ויכתוב את התוצאה המעודכנת למסך. סוליד, הפריימוורק שיצר ריאן קרניאטו, לוקח טייק אחר לגמרי. במקום לעקוב אחר תלויות במבני נתונים שנקראים Virtual DOM, הוא שומר על קשר ישיר בין משתנה לבין הדברים שתלויים בו. הריאקטיביות של סוליד היא ריאקטיביות ברזולוציה גבוהה - אף פעם לא מעדכנים מחדש קומפוננטה מלאה רק בגלל שמשהו בסטייט השתנה, אלא כל דבר שמשתנה גורם לעדכון מדויק של הדברים שמושפעים ממנו. התוצאה היא פריימוורק שנראה דומה לריאקט אבל עובד אחרת לגמרי: 1. הקומפוננטות הן פונקציות וקוד לשימוש חוזר הוא Custom Hook, אבל התלויות מזוהות בצורה אוטומטית ואין שום אילוץ להפעיל Hooks רק מתוך קוד של קומפוננטה. 2. פונקציית הקומפוננטה עצמה מורצת רק פעם אחת כדי "לחבר" בין משתני הסטייט לבין הדברים שרואים על המסך. משם, כל פעם שמשתנה סטייט מתעדכן הוא מייצר עדכון אוטומטי של ה DOM. 3. אין Virtual DOM ולכן יש הרבה פחות חשיבות (מבחינת ביצועים) לחלוקה נכונה לקומפוננטות. 4. בהרבה מאוד מצבים נקבל ביצועים טובים יותר עבור קוד כמעט זהה. ביום חמישי הקרוב אעביר בזום וובינר של שעה על סוליד בו אראה לכם איך לעבוד עם הפריימוורק וגם נראה את ההבדל מבחינת ביצועים בינה לבין ריאקט. בסיום הוובינר, בנוסף להיכרות עם פריימוורק די מדליק, גם תבינו מהי ריאקטיביות ואיך פריימוורק ריאקטיבי צריך להיראות. גם אם בסוף לא תעבדו עם סוליד, היכרות איתו ועם שיטת המחשבה שלו תעזור לכם להבין את ריאקט טוב יותר. אפשר להצטרף לוובינר בחינם בלחיצת כפתור בדף האירוע כאן: https://www.tocode.co.il/workshops/116 נתראה ינון

# מהו useDeferredValue ולמה שיהיה לכם אכפת ריאקט 18 יצא לפני כמה ימים והפיצ'ר המרכזי שלו נקרא Concurrent Mode. פיצ'ר זה מאפשר לריאקט להתחיל לרנדר משהו, להבין שזה לוקח יותר מדי זמן או שיש משהו יותר חשוב לעשות ואז לעצור, לרנדר את הדבר היותר חשוב ולחזור לעבודה הארוכה יותר. אחד השימושים של הפיצ'ר הזה הוא הפונקציה useDeferredValue שמגדירה לריאקט שחישוב מסוים הוא פחות חשוב ואפשר לחכות קצת עם ה render-ים שתלויים בו כדי לא להאט את כל העמוד. הפונקציה יעילה במיוחד עבור רשימה עם תיבת סינון: כשמשתמש מקליד טקסט בתיבה אנחנו רוצים לראות תגובה מיידית, אבל סינון הפריטים עצמו יכול לקחת קצת יותר זמן ולעבוד ברקע. הקוד הבא ממחיש את ההתנהגות הרצויה תוך שימוש ב useDeferredValue:

export default function App() {
  const [search, setSearch] = useState("");
  const dsearch = useDeferredValue(search, { timeoutMs: 10000 });
  return (
    <div className="App">
      <input
        type="search"
        value={search}
        onChange={(e) => setSearch(e.target.value)}
      />
      <FilteredList search={dsearch} isPending={dsearch !== search} />
    </div>
  );
}

ואפשר לראות אותו בפעולה בקודסנדבוקס הבא: <iframe src="https://codesandbox.io/embed/condescending-andras-gtdmwt?fontsize=14&hidenavigation=1&theme=dark" style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;" title="condescending-andras-gtdmwt" allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking" sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts" ></iframe> קצת הסברים על הקוד: 1. הסטייט search מייצג את הטקסט בתיבה; המשתנה dsearch הוא עותק של search שהאלמנטים שתלויים בו פחות חשובים. 2. בפרק הזמן בין עדכון search לעדכון dsearch ריאקט מנסה ברקע לרנדר את הקומפוננטה FilteredList שמושפעת מ dsearch. בהתחלה הערכים של dsearch ו search יהיו שונים ואחרי שהרינדור האיטי יסתיים הערכים יהיו שווים. אני בודק את ההבדל בין שני המשתנים כדי לדעת אם ריאקט עכשיו עובד ברקע, ומשקף את זה למשתמשים באמצעות המשתנה isPending. 3. אם תכנסו לקודסנדבוקס ותשחקו שם עם המספרים תגלו שאומנם עבור 10,000 שורות הקוד עובד ממש בסדר, ככל שמעלים את מספר השורות אנחנו מצליחים לשבור את useDeferredValue ולמשל ב 90,000 שורות האיטיות כבר מורגשת בעדכון תיבת הטקסט. אולי זה ייפתר בגירסאות עתידיות של ריאקט ובכל מקרה זו תזכורת טובה לכך שתיקון גנרי בפריימוורק בדרך כלל לא יכול לפתור לכולם את הבעיות, וגם בריאקט 18 נצטרך לשים לב למה אנחנו מרנדרים כדי לשמור על ביצועים טובים.

# עוד שתי סיבות טובות לחוב טכני המונח "חוב טכני" (Technical Debt) מתאר מצב שבו אנחנו עושים פשרה במערכת כדי להתקדם מהר יותר. הבחירה במונח "חוב" באה להזכיר לנו שלפשרה הזאת יש מחיר, ושעוד מעט נצטרך "להחזיר" את החוב כלומר לארגן מחדש את הקוד בצורה נכונה. למי שצובר הרבה חובות טכניים יהיה קשה להתקדם ובסופו של דבר יצטרך להכריז על "פשיטת רגל", כלומר לזרוק את כל הקוד ולהתחיל מחדש. הסיבות הקלאסיות לחוב טכני כוללות- 1. בחירת פריימוורק שייתן פיתרון מהיר למרות שאנחנו יודעים שהוא לא מספיק גמיש או כולל בעיות ביצועים (היוש פונגאפ) 2. כתיבת קוד ללא בדיקות או ללא תיעוד 3. כתיבת קוד שלא מטפל במקרי שגיאה נפוצים 4. אי שידרוג תלויות כשגירסאות חדשות יוצאות בכל המקרים האלה אנחנו בוחרים "לוותר" על איכות של קוד כדי להגיע מהר יותר ללקוחות עם מוצר שעובד (גם אם לא עובד מושלם), כדי שנוכל לקבל פידבק על המוצר ואחרי זה להמשיך לסבב תיקונים. חוץ מהסיבות הקלאסיות לחוב טכני יש עוד שני מקרים שמצדיקים חזרה אחורה ותיקון, למרות שהם הרבה פחות מכוונים: ## כשאין לנו מספיק ידע כדי לפתור בעיה בפרויקט מסוים הייתי צריך לבנות ללקוח תשתית בדיקות אבל הפרויקט השתמש בכמה ספריות שלא עבדו טוב עם jest. באותו זמן, איך שלא סובבתי את הגדרות הבניה לא הצלחתי לגרום ל jest לבדוק את הפרויקט ובסופו של דבר כתבנו את הבדיקות עם mocha ו sinon. בפרויקט הזה לא היתה בחירה מודעת להשתמש בפיתרון מסוים שיהיה מהיר יותר מהאלטרנטיבות רק בשביל לפתור את הבעיה, אלא הפיתרון שנבחר היה היחיד שהיה נראה אפשרי באותו זמן. ## כשאנחנו לא מספיק מכירים את הדריכות בפרויקט אחר כתבתי ללקוח קומפוננטת ריאקט לטבלה שהיתה מאוד מושקעת מבחינת ביצועים - היא יכלה להכיל מאות אלפי שורות וכל פעם עשתה render רק לשורות שרואים על המסך, כדי שאפשר יהיה להפעיל סינונים ומיונים מהירים. הקוד עבד מצוין רק אחרי שהם הגיעו לפרודקשן שמתי לב שהם משתמשים בטבלה כדי להציג מספר מאוד קטן של נתונים, בדרך כלל פחות מעשר שורות. כששאלתי על זה הסתבר שבאמת בהתחלה היתה איזו אי הבנה והם רצו משהו בתור הכנה לעתיד אבל בסוף העתיד הזה לעולם לא יגיע. ## מה עושים בשתי הדוגמאות יש לנו פיתרון טוב שעובד. מוקה וסינון, למרות שהם ישנים, עדיין מתוחזקים ואין שום בעיה להמשיך להשתמש בהם גם היום וגם בעתיד הנראה לעין. טבלה שיודעת לטפל גם במאות אלפי שורות היא קומפוננטה טובה, גם אם בפועל היא מציגה הרבה הרבה פחות. ובכל זאת שתי הדוגמאות נכנסות אצלי לקטגוריה של חוב טכני ודורשות Refactoring. אלה פיתרונות יותר מורכבים ממה שהיה צריך וכל הרחבה שלהם תחייב השקעה גדולה יותר. בסופו של דבר אנחנו "משלמים שכירות" על כל שורת קוד במערכת, וגמישות יותר חשובה ממנגנונים מתוחכמים שלא משתמשים בהם.

# איך עובדת רשימת הקפיצות של vim אחד הפיצ'רים שאני הכי אוהב ב vim הוא רשימת הקפיצות. אם אתם לא מכירים (ואולי גם אם כן) הנה הסבר קצר מה זה ולמה זה טוב. ## קפיצה ב vim שתי הדרכים "הקלאסיות" לטייל בקוד בעורכי טקסט הן ללחוץ על שם קובץ עם סמן העכבר ולהזיז את הסמן עם החצים עד שמגיעים למקום שרוצים לערוך. ב vim אנחנו כמעט לא משתמשים בשני מנגנונים אלה ובמקומם יש לנו קפיצות: 1. קפיצה לקובץ חדש עם :e. 2. קפיצה לטקסט מסוים בקובץ עם /. 3. קפיצה לשורה מסוימת, או ל marker מסוים. 4. קפיצה למקום האחרון בו שיניתי טקסט עם '.. 5. קפיצה לקובץ ששמו נמצא מתחת לסמן עם gf. 6. קפיצה להגדרה של פונקציה עם gd. ועוד המון קפיצות בסגנון זה. הטריק הוא שכל פעם שאנחנו קופצים ממקום למקום ב vim, אז וים שומר את המקום הקודם שהיינו בו ברשימה שנקראת רשימת קפיצות. בכל רגע נתון אפשר לכתוב :jumps ולראות את הרשימה הזאת, או לכתוב :clearjumps כדי למחוק את ההיסטוריה. ## טיול ברשימת הקפיצות נניח ש jumps מראה לי את הפלט הבא:

:
 jump line  col file/text
   8     1    0 NERD_tree_1
   7    12    0 NERD_tree_1
   6     4    0 package.json
   5     1    0 src/App.vue
   4     3   24 src/main.js
   2     1    0 NERD_tree_2
   1     5    0 NERD_tree_2
>  0     1   61 import { createRouter, createWebHashHistory } from 'vue-router'
   1     1    0 ~/tmp/blog/vue/memory-game/node_modules/vue-router/dist/vue-router.d.ts

אז זה אומר שאני עכשיו מסתכל על השורה שמתחילה ב import ומסומנת בחץ. אני יכול ללחוץ על Ctrl+O כדי לזוז קפיצה אחת אחורה כדי להגיע לנווט הקבצים שנמצא בדיוק שורה אחת מעליי, או Ctrl+I כדי לקפוץ שורה אחת קדימה לקובץ vue-router.d.ts. אפשר גם לדלג לקפיצה מסוימת, למשל לחיצה על 6 ואז על Ctrl+O תשלח אותי לקפיצה מספר 6 כלומר לקובץ package.json. שימוש בקפיצות וצפיה ברשימת הקפיצות עוזר לנו לשמור על אוריינטציה במיוחד בניווט בפרויקט גדול ולהבין בדיוק מה שיניתי ואיפה.

# היום למדתי: הפונקציה rerender של react-testing-library הפונקציה rerender עושה בדיוק מה שהשם שלה רומז, ואני לא מאמין שהעברתי חיים שלמים בלעדיה. היא הכי שימושית כשיש לנו קומפוננה שה props שלה צריכים להשתנות במהלך הבדיקה. ככה זה עובד- ## הקומפוננטה שאני בודק בשביל המשחק ניקח קומפוננטה שמציגה מספר כלשהו של תיבות טקסט מסונכרנות, כשהמספר מתקבל דרך prop. אני רוצה לוודא שכשאני משנה את מספר התיבות, הטקסט בכל התיבות עדיין נשאר אותו דבר. זה קוד הקומפוננטה:

export function ManyInputs(props) {
  const { n=5 } = props;
  const [ value, setValue ] = useState('');

  return (
    <div data-testid="many-inputs">
      {new Array(n).fill(0).map((_, index) => (
        <input
          key={index}
          type="text"
          value={value}
          onChange={(e) => setValue(e.target.value)}
        />
      ))}
    </div>
  );
}

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

test('change n', () => {
  const Helper = () => {
    const [n, setN] = useState(5);
    return (
      <div>
        <label>
          Number Of Boxes:
          <input type="text" value={n} onChange={(e) => setN(Number(e.target.value))} />
        </label>
        <ManyInputs n={n} />
      </div>
    );
  };

  render(<Helper />);

  let allInputs = within(screen.getByTestId('many-inputs')).getAllByRole('textbox');
  userEvent.type(allInputs[0], 'hello');
  for (const tb of allInputs) {
    expect(tb).toHaveDisplayValue('hello');
  }
  userEvent.type(screen.getByLabelText('Number Of Boxes:'), '8');

  allInputs = within(screen.getByTestId('many-inputs')).getAllByRole('textbox');
  for (const tb of allInputs) {
    expect(tb).toHaveDisplayValue('hello');
  }
});

## החיים היפים עם rerender במקום לבזבז מקום על כתיבת קומפוננטת עזר, הפונקציה rerender יכולה לעזור לנו לשנות prop על הקומפוננטה שאותה אנחנו בודקים. הפונקציה נשלחת אלינו כשדה באוביקט שחוזר מ render, ומספיק להפעיל אותה עם ה props החדשים. הנה קוד הבדיקה המעודכן:

test('change n', () => {
  const { rerender } = render(<ManyInputs n={5} />);

  let allInputs = within(screen.getByTestId('many-inputs')).getAllByRole('textbox');
  expect(allInputs).toHaveLength(5);
  userEvent.type(allInputs[0], 'hello');
  for (const tb of allInputs) {
    expect(tb).toHaveDisplayValue('hello');
  }
  rerender(<ManyInputs n={8} />);

  allInputs = within(screen.getByTestId('many-inputs')).getAllByRole('textbox');
  expect(allInputs).toHaveLength(8);
  for (const tb of allInputs) {
    expect(tb).toHaveDisplayValue('hello');
  }
});

יותר קצר, יותר מדויק והרבה יותר קל לתחזוקה.

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

# איך סוליד פתר את הבעיה הכי מעצבנת עם useEffect של ריאקט הפונקציה useEffect של ריאקט מגדירה קשר חד כיווני בין מידע מסוים שאנחנו עוקבים אחריו לבין "משהו" חיצוני שצריך לקרות. בין הדוגמאות הפופולריות לאפקטים נוכל למצוא: ## דוגמאות לאפקטים 1. קומפוננטה שומרת מזהה של משאב חיצוני, וכל פעם שהוא מתעדכן הקומפוננטה מושכת מידע חדש מהרשת שמתבסס על המזהה הזה. 2. קומפוננטה שומרת מחרוזת טקסט שמשמשת בתור title של הדף. כל פעם שהמחרוזת מתעדכנת גם משנים את ה document.title בהתאמה. 3. קומפוננטה מגדירה שעון שמתקתק כל X שניות, כאשר X הוא משתנה סטייט. כשהמשתנה מתעדכנן גם השעון משנה את התדירות. 4. קומפוננטה כוללת שדה קלט בטופס. כל פעם שמשתמש מעדכן את המידע מריצים וולידציה על המידע ואולי מגדירים הודעת שגיאה במשתנה סטייט אחר. 5. קומפוננטה מעדכנת משתנה State כל פעם ש prop מסוים שלה מתעדכן. הבעיה הכי מעצבנת עם useEffect היא שהפונקציה מטפלת בשני סוגים של מקרים, בלי לתת לנו דרך טובה להבדיל ביניהם: 1. יש אפקטים שצריכים לקרות גם אחרי ה render הראשון - לדוגמה להפעיל timer או למשוך מידע מ API מרוחק. 2. יש אפקטים שצריכים לקרות רק כשאחד הערכים שמשפיע על האפקט משתנה - לדוגמה עדכון ה document.title כשמשתנה state משנה את ערכו, או עדכון משתנה state אחרי שקיבלנו ערך חדש ל property מסוים. הקומפוננטה Ticker הבאה היא דוגמה למקרה הראשון. היא מציגה מספר שעולה ב-1 כל שניה:

function Ticker() {
  const [value, setValue] = useState(0);
  useEffect(() => {
    setInterval(() => {
      setValue(v => v + 1);
    }, 1000);
  }, []);

  return (
    <p>{value}</p>
  )
}

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

export default function TitleEditor() {  
  const [value, setValue] = useState(document.title);
  useEffect(() => {
    console.count(`writing ${value} to document.title`);
    document.title = value;
  }, [value]);

  return (
    <input type="text" value={value} onChange={(e) => setValue(e.target.value)} />
  )
}

בעוד ש useEffect מציע פיתרון ממש טוב לסוג הראשון של אפקטים, קומפוננטה כמו TileEditor עושה עבודה מיותרת - היא מעדכנת את document.title גם בפעם הראשונה כשהערך זהה. עכשיו תגידו ובצדק שבדוגמה הפשוטה של TitleEditor מאוד קל לפתור את זה - פשוט בודקים אם document.title זהה ל value שיש לי, ואם כן לא מעדכנים אותו. אבל במקרים יותר מורכבים ייתכן ואנחנו רוצים לסנכרן את המשתנה עם מידע בשרת וגם הקריאה עצמה לוקחת זמן. הדרך המקובלת בריאקט לדלג על האפקט אחרי render ראשוני היא לייצר ref כדי לזכור האם האפקט רץ פעם אחת. אפשר לקרוא על הטכניקה כאן: https://medium.com/swlh/prevent-useeffects-callback-firing-during-initial-render-the-armchair-critic-f71bc0e03536 ## טריק קטן של סוליד שעושה את ההבדל אז מה הטריק של סוליד שהופך את כל הסיפור הזה להרבה יותר קל? פשוט - הפונקציה useEffect שלהם, שנקראת createEffect יכולה לקבל פרמטר שני מיוחד שיעבור לפונקציית ה Callback רק בהפעלה הראשונה של האפקט (ובהפעלות הבאות בפרמטר הזה יישלח הערך "הקודם" של האפקט). הקומפוננטה הבאה בסוליד משיגה את אותו אפקט, תוך דילוג על הכתיבה הראשונה (המיותרת) ל document.title:

function App() {
  const [value, setValue] = createSignal(document.title);
  createEffect((prev) => {
    if (prev) {
      document.title = value();
    }

    return value();
  }, null);

  return (
    <input
      type="text"
      value={value()}
      onInput={(e) => setValue(e.currentTarget.value)}
    />
  );
}

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

# אפילו שזה רק שורה משמעות הקיצור DRY היא Don't Repeat Yourself, ובהקשר של קוד אנחנו מתכוונים לא לחזור על אותו קטע קוד שוב ושוב. אבל מה אם קטע הקוד הזה הוא שורה אחת? ## איך בודקים קומפוננטה בריאקט ספריית הבדיקות הפופולרית לריאקט היום נקראת react-testing-library ויש בה מודול שנקרא userEvent, שמדמה פעולות של משתמש. הקוד הזה לדוגמה לוקח קומפוננטה בשם MyComponent ולוחץ על הכפתור שבתוכה עם הטקסט click me:

test('trigger some awesome feature when clicking the button', () => {
    render(<MyComponent/>)
    userEvent.click(screen.getByRole('button', name: /click me!/))
})

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

test('memory game red-blue-blue-red', () => {
    render(<MemoryGame colors=['red', 'blue', 'blue', 'red'] />);
    userEvent.click(screen.getByRole('button', name: /red/));
    userEvent.click(screen.getByRole('button', name: /blue/));
    userEvent.click(screen.getByRole('button', name: /blue/));
    userEvent.click(screen.getByRole('button', name: /red/));
    expect(screen.getByText('Bravo!')).toBeInTheDocument();
});

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

userEvent.click(screen.getByRole('button', name: /red/));

בשורה מקבילה עבור ה div. במקרים פשוטים אפשר להשתמש בפונקציית Replace All של עורך הטקסט שלכם, במקרים יותר מורכבים יכול להיות שמצפה לכם קצת עבודה ידנית. ## מה עושים במקום? הלקח כאן הוא ש DRY לא קשור בכלל למספר השורות שחוזרות על עצמן אלא למשמעות של הפעולה - קוד הבדיקה הראשון שכתבתי חיבר בין "לחץ על הכפתור האדום" ל"לחץ על הכפתור האדום בדרך של userEvent ועם מבנה ה DOM של הקומפוננטה MemoryGame". החלק שחזר על עצמו שוב ושוב בקוד היה "כדי ללחוץ על הכפתור האדום צריך למצוא אלמנט כפתור עם הטקסט red". המשפט הזה הופיע בצורה מובלעת כל פעם שכתבתי את שורת הלחיצה. גישה טובה יותר שהיתה מונעת את הבעיה מראש היתה להגדיר איזה פעולות אנחנו צריכים לעשות עם הקומפוננטה וליצור פונקציה קטנה עבור כל פעולה, נניח פונקציה שלוחצת על הכפתור האדום:

function clickOnRed(screen) {
    userEvent.click(screen.getByRole('button', name: /red/));
}

את קוד הבדיקה אני אחליף עכשיו ל:

test('memory game red-blue-blue-red', () => {
    render(<MemoryGame colors=['red', 'blue', 'blue', 'red'] />);
    clickOnRed();
    clickOnBlue();
    clickOnBlue();
    clickOnRed();
    
    expect(successTextElement()).toBeInTheDocument();
});

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

ומה לגבי המפתחות? באופן אוטומטי לולאות בסוליד מקבלות בתור מפתח את ה Reference של האוביקט עצמו, ולכן אוביקט שרק משנה מקום במערך מצליח לשמור על ה DOM Node שלו. ## עכשיו אתם בגלל שה Playground הוא אינטרקטיבי אתם יכולים לקחת את הקוד ולשחק איתו. נסו לעדכן את הקוד כך ש: 1. הוסיפו כפתור מחיקה שימחק את כל הימים המסומנים. 2. הוסיפו כפתור "ערבוב" שיערבב מחדש את הימים. 3. במקום להציג רק את הימים שמתאימים לחיפוש, צבעו את האותיות שמתאימות לחיפוש בכל אחד מהימים ברשימה שמכיל אותן.

# פיתוח רשימה עם סינון ב Solid JS סוליד היא פריימוורק ריאקטיבית לפיתוח יישומי צד לקוח. היא דומה לריאקט בגלל השימוש ב JSX אבל יש לה מספר היבטים משמעותיים שונים, חלקם לטובה וחלקם פחות לטובה. בואו נראה חלק מהם באמצעות פיתוח קומפוננטה לרשימת פריטים עם סינון ב Solid JS. ## מה אנחנו בונים אפשר להיכנס לקוד הקומפוננטה המלא ולשחק איתו אונליין בקישור: https://bit.ly/3IIWUKe אחרי שתיכנסו תמצאו שם רשימה של ימי השבוע ותיבת סינון. כתיבת טקסט בתיבה תסנן את הרשימה ותציג רק את הימים שמתאימים לטקסט. שחקו עם זה קצת, ובואו נמשיך לדבר על הקוד. ## סיגנלים במקום סטייט רעיון מהפכני ראשון של סוליד הוא זיהוי התלויות האוטומטי - שזה בעצם הריאקטיביות. הרעיון הוא שמידע מסוים (שבריאקט היינו קוראים לו סטייט) יכול להשתנות, ומידע במקום אחר יכול להיות מושפע מהשינוי הזה. בריאקט כל ה Hooks API בנוי על העברת רשימות של תלויות כדי שריאקט יוכל לדעת מה משפיע על מה. בסוליד קריאה של ערך אוטומטית מוסיפה את ה"דבר" הזה לרשימת התלויות, ולכן חישוב הרשימה הוא אוטומטי. בדוגמה שלנו יש לנו תיבת חיפוש והערך בתיבה משפיע על רשימת הימים שצריך להציג. הנה שתי השורות שגורמות לקסם הזה לקרות:

const [search, setSearch] = createSignal('');
const visibleItems = createMemo(
  () => items().
  map((i: string) => i.toLowerCase()).
  filter((i: string) => i.includes(search()))
);

המשתנה search הוא סיגנל - כלומר הוא מחזיק מידע שכשמידע זה משתנה צריך להודיע לכל מי שתלוי במידע על השינוי. בשורה הבאה אני מפעיל את הפונקציה createMemo שיוצרת משתנה שתלוי במידע. אני לא אומר לה באיזה מידע הוא תלוי, ובאופן אוטומטי סוליד מזהה מתי הפעלתי את הפונקציה search() שמחזירה את המידע בסיגנל, ויוצר את הקשר. הפעלת הפונקציה setSearch תשלח את הסיגנל ותודיע ל visibleItems שעליו להתעדכן. מסיבה זו כל משתני הסטייט בסוליד הם בעצם פונקציות, והם יכולים להיווצר בכל מקום בתוכנית ולא רק בתוך קומפוננטות. כך הגדרתי את items בקוד הראשי של התוכנית:

const [items, _] = createSignal(['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday']);

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

interface IFilteredListProps {
  items: Accessor<Array<string>>;
  renderItem?: (item: string) => Node
}

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

<input type="text" value={search()} onInput={e  => setSearch(e.currentTarget.value)} />

שווה לשים לב שבניגוד לריאקט, כאן האירוע נקרא input ולא change, כדי להתאים לטרמינולוגיה של ה DOM. ## לולאות טריק שני של סוליד שעובד אחרת מריאקט הוא הלולאות. שימו לב לקוד-

<ul>
  <For each={visibleItems()}>
    {(item, _index) => (
      renderItem(item)
    )}
  </For>
</ul>

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

function defaultRenderItem(item: string) {
  return (
    <li>
        <input type="checkbox" />
        {item}
    </li>
  )
}

אז מה הסיפור עם הקומפוננטה, ולאן נעלם המאפיין key? נתחיל בקומפוננטה - לסוליד יש קטע שרק קוד שכתוב בתוך קומפוננטות מושפע משינויים ריאקטיביים בסיגנלים. אצלנו יש שני סיגנלים items ו search, מהם מושפע סיגנל שלישי בשם visibleItems וממנו מושפע הקטע שבתוך קומפוננטת ה For. כש search או items יתעדכן, אז visibleItems יחושב מחדש ובתגובה קומפוננטת ה For שמושפעת ממנו תחושב מחדש. זה ריאקטיביות כל הדרך. הסיפור כאן מאוד שונה מריאקט, שם כל שינוי במשתנה state או prop כלשהו יגרום להרצה מחדש של כל פונקציית הקומפוננטה, ולא רק של החלק שמושפע מאותו השינוי. ברמת הביצועים בהנחה שהחיבורים בין הסיגנלים לדברים שמושפעים מהם לא גוזלים יותר מדי זיכרון, אז פעולת ה render של סוליד יותר מדויקת מזו של ריאקט ולכן יש פחות עבודה מיותרת של השוואות בין Virtual DOMs. למעשה בגישה הריאקטיבית של סוליד לא צריך Virtual DOM בכלל.