ToCode

promise.status = 'rejected';
        promise.reason = reason;
      },
    );
    throw promise;
  }
}

הפונקציה מקבלת Promise ומשתמשת ב throw כדי לברוח מהפונקציה שקראה לה אם ה Promise עדיין לא מוכנה. קומפוננטת Suspense תתפוס את ה Promise ותציג את ה Fallback Content, ואוטומטית כשה Promise יסתיים תרנדר מחדש את הקומפוננטה הפנימית. החלק האחרון בדוגמה הוא הפונקציה fetchData. אחסוך לכם את המימוש כי הוא לא חשוב, זאת פשוט פונקציה אסינכרונית שמקבלת מידע מהשרת. ## מפל בקשות אספקט נוסף של Suspense שקצת עובר מתחת לרדאר הוא היחס לבעיה שנקראת מפל בקשות. הבעיה בגדול עשויה להיגרם כשיש לנו קומפוננטות מקוננות שכל אחת מהן צריכה לקבל מידע אחר מהשרת. נדמיין משהו בסגנון: 1. קומפוננטה של טופס החלפת סיסמה במסך "החשבון שלי", שבשביל להיטען צריכה לקבל מהשרת את פרטי המשתמש הנוכחי. 2. בתוכה קומפוננטה של Captcha שצריכה לקבל משרת אחר את הציור של האותיות המוזרות כדי לוודא שהמשתמש אכן בן אדם. במצב רגיל של קומפוננטה בתוך קומפוננטה, רק אחרי שקונפוננטת הטופס תסיים לטעון ולהתרנדר על המסך אפשר יהיה להמשיך למשוך את המידע מקומפוננטת ה Captcha. בחלק מדפי התיעוד על Suspense הם מדברים על הבעיה הזו, באחרים לא. נשים לב ששימוש נאיבי ב Suspense לא יפתור את בעיית המפל כי ה throw שיעצור את הרינדור של קומפוננטת הטופס ימנע רינדור של קומפוננטת ה Captcha הפנימית יותר. כן אפשר לארגן אחרת את עץ הקומפוננטות ולמשוך את המידע בקומפוננטה ברמה גבוהה יותר או מתוך ספריית ניהול הסטייט כדי לצאת מזה, אבל בכל מקרה Suspense יהיה רק חלק קטן מהפיתרון כאן. ## מה אפשר לעשות במקום Suspense? אם נסכם היתרון הגדול של Suspense הוא ביכולת לטפל במספר קומפוננטות שטוענות מידע ולהציג קומפוננטת Loading מסודרת אחת שמרכזת את כל הטעינות. לפני Suspense הפיתרון הטוב ביותר למצב הזה הוא לבצע את כל הטעינות מהקומפוננטה הראשית ולהעביר את המידע שנטען לילדים כשהוא מוכן, משהו בסגנון הזה:

export default function ArtistPage({ artist }) {
  const { data, isLoading } = useSWR(`/${artist.id}/albums`);
  return (
    <>
      <h1>{artist.name}</h1>
      {isLoading ? <Loading /> : <Albums data={albums} />}
    </>
  );
}

היתרון בגישה כזאת הוא שאנחנו מקבלים אוטומטית הפרדה בין הקומפוננטות של הלוגיקה (אלה ששולחות בקשות רשת) לקומפוננטות פשוטות יותר של תצוגה שנמצאות בתוכן. החיסרון הוא שהכתיבה מאוד ריכוזית וזה יכול להיות מבלבל כשצריך לשנות נתיבים או כשיש לוגיקה יותר משמעותית סביב הבקשה, לדוגמה אם Albums צריך לקחת את המידע שמגיע מהשרת ולעשות עליו איזושהי מניפולציה לפני שיכול להציג אותו. ## אז לשכתב? מצד אחד ל Suspense יש קלף מנצח בשרוול - הוא באמת מאפשר הרבה יותר בקלות לבנות דף שמורכב מהרבה קומפוננטות, שכל אחת מהן מושכת מידע מהשרת וכולן יחד מציגות מסך טעינה אחד. מצד שני ה Use Case הזה הרבה פחות נפוץ ממה שמדמיינים. בהרבה מערכות יש לי נתיב אחד בשרת שמחזיר את כל המידע של "דף" מסוים, ואז אני משתמש ב useSWR (או מקבילות שלו) רק בקומפוננטה הראשית של הדף ומפזר את המידע שקיבלתי בין הקומפוננטות. בעוד הרבה מערכות כן יהיו לי קומפוננטות קטנות שטוענות את עצמן, אבל כשכל קומפוננטה יודעת להציג את עצמה גם במצב "טעינה", למשל במערכת שמציגה על המסך כמה גרפים, אז הגיוני לראות את הגרפים נטענים בצורה עצמאית אחד אחרי השני. אז כן כדאי להכיר את Suspense, כדאי להשתמש בו כשצריך, אבל אל תעצרו עכשיו הכל בשביל לשכתב את כל קוד התקשורת שלכם עם Suspense. ברוב המערכות אפשר להסתדר טוב מאוד גם בלעדיו.

# ריאקט מתי Suspense שווה את המאמץ אחד הפיצ'רים שעוררו התלהבות בריאקט 18 נקרא Suspense For Data Fetching. בפוסט זה נראה מהו Suspense For Data Fetching ומתי כדאי או לא כדאי להשתמש בו. ## הצורך ב Suspense לפני Suspense, כשרצינו (או עדיין רוצים) להציג קומפוננטה שתלויה במידע שמגיע מהשרת היו לנו שתי אפשרויות: 1. היינו יכולים בקומפוננטה שמעליה למשוך את המידע, ולהציג את הקומפוננטה רק אחרי שהמידע מוכן. 2. היינו יכולים בתוך הקומפוננטה לכתוב קוד שימשוך את המידע, ולשים לב לטפל תמיד גם במצב לפני שהמידע מוכן. בדוגמה פשוטה מ swr, הקומפוננטה הבאה מושכת מידע על משתמש:

import useSWR from 'swr'

function Profile() {
  const { data, error, isLoading } = useSWR('/api/user', fetcher)

  if (error) return <div>failed to load</div>
  if (isLoading) return <div>loading...</div>
  return <div>hello {data.name}!</div>
}

הקומפוננטה אחראית לייצר 3 ייצוגים - אם הבקשה נכשלה היא מחזירה את הטקסט failed to load, אם הבקשה הצליחה היא מחזירה את שם המשתמש ואם הבקשה בטעינה היא מחזירה את הטקסט loading. יש קומפוננטות שמאוד הגיוני לבנות עבורן "מצב טעינה". חישבו על קומפוננטה של תיבת בחירה שבה האפשרויות השונות לבחירה נטענות ממידע שמגיע מהשרת. במצב כזה אין בעיה לצייר Spinner קטן בתוך התיבה כשהאפשרויות נטענות כדי לשקף למשתמש שתכף אפשר יהיה לבחור אפשרות. אבל יש מצבים יותר מסובכים, למשל נחשוב על קומפוננטה של "דף חשבון" שכוללת מידע על החשבון שמגיע מכמה נקודות קצה ובכמה קומפוננטות. לדוגמה אפשר לדמיין דף באתר קורסים שיהיה מורכב מכמה קומפוננטות: 1. קומפוננטה של תעודות שמציגה רשימה של כל הקורסים שסיימתם . 2. קומפוננטה של פרטי כניסה שמציגה את האימייל של המשתמש עם אפשרות להחליף מייל או סיסמה. 3. קומפוננטה של פרטי תשלום שמציגה את פרטי התשלומים שבוצעו עם אפשרות להוריד חשבוניות ישנות או לשנות פרטי אשראי. במצב כזה כל קומפוננטה תצטרך למשוך את המידע שרלוונטי עבורה. אם כל קומפוננטה תציג הודעת "המידע בטעינה" יהיה לנו דף שמורכב מכמה Spinner-ים שאולי לא מתואמים ביניהם. ## איך Suspense עובד אני מתבסס על הדוגמה מהתיעוד שזמינה בקודסנדבוקס הזה: https://codesandbox.io/s/s9zlw3 בשביל להשתמש ב Suspense אנחנו צריכים לכתוב הרבה קוד הגיוני וקצת קוד מוזר. נתחיל מהקוד ההגיוני. אם יש לי קומפוננטה שאני יודע שהילדים שלה יצטרכו לקבל מידע מהרשת, ואני רוצה לייצר מסך "מצב טעינה" אחד שיופיע עד שכל הילדים יהיו מוכנים, אני עוטף את הילדים בקומפוננטת Suspense:

export default function ArtistPage({ artist }) {
  return (
    <>
      <h1>{artist.name}</h1>
      <Suspense fallback={<Loading />}>
        <Albums artistId={artist.id} />
      </Suspense>
    </>
  );
}

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

export default function Albums({ artistId }) {
  const albums = use(fetchData(`/${artistId}/albums`));
  return (
    <ul>
      {albums.map(album => (
        <li key={album.id}>
          {album.title} ({album.year})
        </li>
      ))}
    </ul>
  );
}

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

function use(promise) {
  if (promise.status === 'fulfilled') {
    return promise.value;
  } else if (promise.status === 'rejected') {
    throw promise.reason;
  } else if (promise.status === 'pending') {
    throw promise;
  } else {
    promise.status = 'pending';
    promise.then(
      result => {
        promise.status = 'fulfilled';
        promise.value = result;
      },
      reason => {

# הצילו! ספריית הקוד הפתוח שאני צריך כבר לא מתוחזקת בעולם של היום הדבר הכי קל בפרויקט זה להוסיף תלות בעוד ספריית קוד פתוח. צריכה הצפנה? יש מודול ב pip שעושה את זה. צריך לפתוח קובץ זיפ? פשוט תריץ npm install. לפעמים נדמה לי שחצי מהעבודה שלנו היא למצוא את המודול המתאים בשביל לפתור את הבעיה. הבעיה שכשהפרויקט מתבגר כך גם ספריית הקוד הפתוח ששילבתם, ולא בטוח שאהבת הנעורים מלפני שנתיים היא השותפה המושלמת גם לפרויקט של היום. הרבה (מאוד) ספריות קוד פתוח התחילו בתור רעיון או צורך של מתכנת פרטי, לא זכו למימון וננטשו אחרי שהפסיקו להיות "כיף" לאותם מתכנת או מתכנתת שכתבו אותם במקור. אפילו פרויקטי קוד פתוח מסחריים רבים ננטשים, כשהחברה שבנתה אותם רואה שזה לא מביא להם את יחסי הציבור הטובים אליהם הם קיוו, או כשהסטארט אפ שבנה אותם נסגר כי נגמר המימון. בקיצור זה לא מוזר בכלל לעבוד על פרויקט שחצי מהתלויות שלו כבר לא נתמכות. ואם זה גם המקרה שלכם הנה כמה רעיונות פרקטיים שאפשר לנסות: 1. להתעלם - זוכרים את "אם זה עובד לא נוגעים"? אז הרבה פעמים אנחנו רואים פרויקטים שתלויים בספריות קוד פתוח שכבר שנים לא מתוחזקות, ולאף אחד לא אכפת. בדרך כלל בפרויקטים כאלה יהיו כל מיני כללים מוזרים כמו "אסור לשדרג את node כי אז כלום לא יעבוד", וכולם מתכננים יום אחד לשדרג את התלות הלא מתוחזקת אבל לא מגיעים לזה. 2. ליצור fork מתוחזק - כש kreeti שמו לב שספריית הריילס האהובה עליהם ננטשה, הם יצרו פורט מתוחזק. וכן יש אפילו כלי שעוזר למצוא פורקים קיימים לספריות שננטשו. 3. להיפרד מהתלות ולהמשיך הלאה - רוב הסיכויים שאם הבעיה שלכם מעניינת יש גם אנשים אחרים שנתקלו בה ויש לה פיתרונות אחרים, טובים יותר מהפיתרון הישן ההוא שכבר לא מתוחזק. בדוגמה שקישרתי אליה קודם של פייפרקליפ, יש כבר פיתרון מובנה בריילס שפותר בדיוק את אותה בעיה (זאת הסיבה שהספריה המקורית ננטשה). אם הפרויקט שלכם מספיק חשוב, שווה להשקיע את הזמן ולעבור לפיתרון החדש יותר. האפשרות השלישית היא המועדפת עליי. למרות שאפשר להישאר עם פיתרונות ישנים ולגרום לכל דבר לעבוד, אין כמו הכיף בלעבוד על פרויקט שהכל בו חדש, ושאפשר בקלות למצוא תיעוד רלוונטי ולשלב יכולות חדשות או כלים חדשים בלי התנגשויות מוזרות.

# למה למחוק קוד? אודי הרשקוביץ כתב בסיפור על הבראנץ הנדיב- > ומנהל הפיתוח גייס עוד טאלנטים והוסיף המון באזז-וורדס ל Branch, והקוד הלך והסתבך ונהיה כבד ומסורבל, ואף אחד כבר לא ידע בדיוק מה עושים ולמה, אבל הדברים איכשהו עבדו. והמשקיעים ראו רק את הצמיחה האדירה של ה Branch, והמשיכו להזרים כסף. ולמרות הבלאגן והספגטי התוכנה המשיכה לעבוד איכשהו, וה Branch היה מקומפל. קוד עובד הוא משקולת. הוא יוצר אילוצים, הוא יוצר בעיות קומפילציה כשמנסים להזיז דברים ממקום למקום, הוא מונע Refactoring כי אי אפשר לדעת איך זה ישפיע על הדברים הקיימים. זה לא סתם שמתכנתים הכי אוהבים פרויקטי Green Fields. כשאין קוד אין מה שיישבר. ולמחוק קוד? למחוק קוד זאת הדרך הכי קלה להאיץ את הפיתוח. זה להקטין את כדור הבוץ הענק שאנחנו קוראים לו מערכת. כדי שהבראנץ שלנו לא יגמור כמו הבראנץ הנדיב.

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

function update() {
  var i;
  for (i = 3; i <= 10; i++) {
    labelID = "line_R" + i;
    if (document.getElementById("num").value >= i) {
      document.getElementById(labelID).style.display = "list-item";
    } else {
      document.getElementById(labelID).style.display = "none";
    }
  }
}

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

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

function update() {
  var i;
  for (i = 3; i <= 10; i++) {
    labelID = "line_R" + i;
    if (document.getElementById("num").value >= i) {
      document.getElementById(labelID).style.display = "list-item";
    } else {
      document.getElementById(labelID).style.display = "none";
    }
  }
}

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

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

# העלות של קיצורי דרך (ולמה כל כך מסובך לכתוב gitignore) ניסיתי לבקש השבוע מ gitignored ליצור לי קובץ gitignore לפרויקט פייתון. זאת היתה ההצעה שלו:

# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class

# C extensions
*.so

# Distribution / packaging
.Python
build/
develop-eggs/
dist/
downloads/
eggs/
.eggs/
lib/
lib64/
parts/
sdist/
var/
wheels/
share/python-wheels/
*.egg-info/
.installed.cfg
*.egg
MANIFEST

# PyInstaller
#  Usually these files are written by a python script from a template
#  before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec

# Installer logs
pip-log.txt
pip-delete-this-directory.txt

# Unit test / coverage reports
htmlcov/
.tox/
.nox/
.coverage
.coverage.*
.cache
nosetests.xml
coverage.xml
*.cover
*.py,cover
.hypothesis/
.pytest_cache/
cover/

# Translations
*.mo
*.pot

# Django stuff:
*.log
local_settings.py
db.sqlite3
db.sqlite3-journal

# Flask stuff:
instance/
.webassets-cache

# Scrapy stuff:
.scrapy

# Sphinx documentation
docs/_build/

# PyBuilder
.pybuilder/
target/

# Jupyter Notebook
.ipynb_checkpoints

# IPython
profile_default/
ipython_config.py

# pyenv
#   For a library or package, you might want to ignore these files since the code is
#   intended to run in multiple environments; otherwise, check them in:
# .python-version

# pipenv
#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
#   However, in case of collaboration, if having platform-specific dependencies or dependencies
#   having no cross-platform support, pipenv may install dependencies that don't work, or not
#   install all needed dependencies.
#Pipfile.lock

# poetry
#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
#   This is especially recommended for binary packages to ensure reproducibility, and is more
#   commonly ignored for libraries.
#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
#poetry.lock

# pdm
#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
#pdm.lock
#   pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
#   in version control.
#   https://pdm.fming.dev/#use-with-ide
.pdm.toml

# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
__pypackages__/

# Celery stuff
celerybeat-schedule
celerybeat.pid

# SageMath parsed files
*.sage.py

# Environments
.env
.venv
env/
venv/
ENV/
env.bak/
venv.bak/

# Spyder project settings
.spyderproject
.spyproject

# Rope project settings
.ropeproject

# mkdocs documentation
/site

# mypy
.mypy_cache/
.dmypy.json
dmypy.json

# Pyre type checker
.pyre/

# pytype static type analyzer
.pytype/

# Cython debug symbols
cython_debug/

# PyCharm
#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
#  and can be added to the global gitignore or merged into this file.  For a more nuclear
#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
#.idea/

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

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

def paint_circle(*, x: int, y: int):
    print(f"Circle: x={x}, y={y}")


def paint_triangle(*, x: int, y: int):
    print(f"Triangle: x={x}, y={y}")


def bad_painter(x, y, z):
    print("Bad painter: x={x}, y={y}, z={z}")


def paint(shapes: List[Callable]):
    for shape in shapes:
        shape(x=10, y=20)


paint([
    paint_circle,
    paint_circle,
    bad_painter,
    paint_triangle,
])

התוכנית מגדירה פונקציה בשם paint שמקבלת רשימה של פונקציות ציור, ומפעילה כל פונקציית ציור עם keyword arguments בשמות x ו y. בעזרת Callable הצלחתי להגדיר בקלות שאני מחפש רשימה של פונקציות, אבל Callable לא נותן לי דרך להגיד שהפונקציות צריכות לקבל פרמטרים בשמות מסוימים (כן אפשר להוסיף סוגריים מרובעים אחרי Callable כדי לקבוע את הטיפוסים הרגילים שפונקציה מקבלת, אבל לא את ה Keyword Arguments). לכן כשמפעילים mypy על הקוד שלמעלה מקבלים:

Success: no issues found in 1 source file

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

from typing import Optional, Iterable
from typing_extensions import Protocol

class Combiner(Protocol):
    def __call__(self, *vals: bytes, maxlen: Optional[int] = None) -> list[bytes]: ...

וכך יכולים לקבוע מה יהיו הפרמטרים של הפונקציה כשקוראים לה כולל מה יהיו השמות של ה Keyword Arguments. בתוכנית שלנו פרוטוקול מציל את המצב בקלות:

from typing import Callable, TypeVar, List
from typing_extensions import Protocol


class Painter(Protocol):
    def __call__(self, *, x: int, y: int) -> None: ...


def paint_circle(*, x: int, y: int):
    print(f"Circle: x={x}, y={y}")


def paint_triangle(*, x: int, y: int):
    print(f"Triangle: x={x}, y={y}")


def bad_painter(*, x, y, z):
    print("Bad painter: x={x}, y={y}, z={z}")


def paint(shapes: List[Painter]):
    for shape in shapes:
        shape(x=10, y=20)


paint([
    paint_circle,
    paint_circle,
    bad_painter,
    paint_triangle,
])

ועכשיו כשמפעילים mypy מקבלים את השגיאה:

named_arguments.py:29: error: List item 2 has incompatible type "Callable[[NamedArg(Any, 'x'), NamedArg(Any, 'y'), NamedArg(Any, 'z')], Any]"; expected "Painter"
Found 1 error in 1 file (checked 1 source file)

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

# מתי עוצרים? בתיעוד של Redux מוצגת הדוגמה הבאה ל Reducer:

function counterReducer(state = { value: 0 }, action) {
  switch (action.type) {
    case 'counter/incremented':
      return { value: state.value + action.payload }
    case 'counter/decremented':
      return { value: state.value - action.payload }
    default:
      return state
  }
}

היא עובדת, אבל לא הולכת להזדקן יפה. על כל פעולה חדשה ביישום נצטרך עוד בלוק ב switch/case הזה, ולאורך זמן הבלוק יגדל למימדים מפלצתיים, יהפך לקשה לתחזוקה וכמעט בלתי אפשרי לשינוי. האתגרים המרכזיים של מבנה ה switch/case הקלאסי של רידאקס הם: 1. אין Context - מי שיסתכל על הקוד הזה בעוד שבועיים לא ידע מתי פעולה מסוימת נקראת, מה החשיבות שלה ביישום באופן כללי. 2. אין טיפוסים - לא ברור מה צריך להיות הערך של action.payload ואיך הוא מחובר ל action.type בלי לקרוא ולהבין את הקוד עצמו. 3. שימוש במחרוזות בתור טיפוסים של actions-ים אומר שאם מישהו ירצה לשנות שם של פעולות הוא יצטרך לעבור על כל הקבצים ביישום כדי לחפש את כל המקומות בהם המחרוזת מופיעה. אז אין ספק שעם 10 שורות הכל עובד מעולה אבל ב 500 שורות כבר אי אפשר לתחזק את הקוד. ועכשיו השאלה מתי עוצרים? מתי משכתבים את היסודות כי הלוגיקה של המערכת שלנו נהייתה מסובכת מדי? אני יכול לחשוב על 3 אפשרויות: 1. אפשר לחפש מהתחלה בסיס שיגדל טוב - לדוגמה אפשר להתחיל את הפרויקט עם Redux Toolkit ו TypeScript ולקבל יסודות טובים יותר מהשניה הראשונה. 2. אפשר לזהות שקטעי קוד מסוימים "מתחילים" להיות מכוערים או קשים לתחזוקה ולשכתב את היסודות איפשהו סביב הנקודה הזאת. 3. אפשר לחכות עד שהקוד יהיה לגמרי כדור ענק של בוץ ואז לבנות אותו מחדש עם יסודות טובים יותר. לכל גישה יש את היתרונות והחסרונות שלה, הדבר החשוב הוא לבחור את הגישה בצורה מפורשת בתחילת הפיתוח כדי שנדע מה מצפה לנו.

# לתפוס את הרגע יושב מתכנת בחברת תוכנה כלשהי ומקבל דיווח על באג - הבילדים נשברים. אחרי קצת מחקר מתגלית הבעיה: סקריפט הבניה של התוכנה שלהם מוריד קוד מגיטהאב בתור קובץ tar.gz ובודק Checksum על הקובץ שירד כדי לראות שקיבל את הקובץ הנכון. רק אם ה Checksum מתאים הוא מריץ את הבניה. ומסתבר שלאחרונה ה Checksum-ים על קבצי ה tag.gz התחילו להשתנות. פרטים בקישור: https://github.com/orgs/community/discussions/45830 מה שקרה זה שגיטהאב שינו את שיטת הכיווץ שלהם, ולכן למרות שהקוד עצמו זהה, הקובץ המכווץ שסקריפט הבניה מקבל שונה מאיך שהוא היה בעבר. וכן תקלות מסוג זה קרו גם לי אינספור פעמים בעבר. וזה רגע שצריך לתפוס. כי ברגע שאתה מתחיל לבדוק מסביב אתה מגלה שיש הרבה מאוד אנשים שלא חושבים שלגיטהאב יש איזושהי מחויבות לגבי האופן בו הם מכווצים את הקוד בריפו, ואף פעם לא היו חולמים לחשב Checksum על קובץ כזה או להתבסס עליו בשום סקריפט בניה. הנה כמה מהתגובות ברדיט: > It's been known for forever that these files aren't stable > GitHub doesn't guarantee the stability of checksums for automatically generated archives. annndd its gonee > This is why I generally upload tarballs to my releases. Artifacts attached to a release won't change. הסיבה שאני אוהב באגים כאלה היא שהם חושפים בעיה באינטואיציה שלי, וכך הם נותנים לי הזדמנות להבין משהו לגבי מגבלות ודברים שאפשר או אי אפשר להסתמך עליהם, וגם לגבי התיעוד ואיך לקרוא ולהבין אותו. כשאנחנו נתקלים בכזה באג, הדבר החכם לעשות הוא לחזור לתיעוד ולחפש כמה שיותר רמזים שאפשר היה להבין מהם מה החוזה האמיתי של ה API ועל מה מותר ואסור להסתמך. אינטואיציה טובה יותר היא אחת הדרכים להפוך למפתחים טובים יותר.