ToCode

# קבוצות אטומיות בביטויים רגולאריים אחד השינויים המעניינים שתמצאו ברשימת החידושים של פייתון 11 נקרא Regular Expressions Atomic Grouping. מסתבר שמאחורי השם המפוצץ מסתתר תחביר פשוט וחמוד, שאפילו יכול להציל את המערכת שלכם מהתרסקות אטומית. אחת הבעיות עם ביטויים רגולאריים נקראת Catastrophic Backtracking. קחו לדוגמה את הביטוי הרגולארי:

re = /W(X|Y+)+Z/

ואת הטקסט:

text = "WYYYYYYYYYYYYYYYYYYYYYYYYYYYYA"

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

re = /W(?>X|Y+)+Z/

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

re = /a(bc|b)c/

יתאים לטקסטים abc ו abcc, אבל אם אני הופך את הקבוצה לאטומית והאופציה של bc תיכשל, המנוע לא יחזור לנסות את b ולכן הטקסט abc לא יתאים לביטוי a(?>bc|b)c. בסך הכל קבוצות אטומיות הן כלי מתקדם שחשוב להכיר אם אתם משתמשים בביטויים רגולאריים על קלט לא מפולטר ורוצים לוודא שקלט זדוני לא שובר לכם את השרת. והחל מפייתון 3.11 תוכלו להשתמש בהן גם בפייתון.

# טיפ טייפסקריפט: ההבדל בין let ו const מבחינת Type Inference לקח לי קצת זמן לשים לב לזה אז משתף כדי שאתם לא תתבלבלו. מנגנון ה Type Inference של טייפסקריפט, זה שאחראי על בחירת הטיפוסים בצורה אוטומטית בקוד שלכם, משתמש בתחילית let או const כדי להחליט אם "להרחיב" את הטיפוס או להשתמש בטיפוס ליטרלי. במילים אחרות ויותר ספציפי, הקוד הזה מגדיר את x להיות מהטיפוס הליטרלי 10:

const x = 10;

אבל הקוד הזה מגדיר את x להיות number:

let x = 10;

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

const movie = { name: 'Return Of The Jedi', rating: 5 };
let key = Math.random() > 0.5 ? "name" : "rating";
console.log(movie[key]);

ולא בגלל שטייפסקריפט כועס על הדירוג הגבוה של "שובו של הג'דיי". הוא פשוט רואה את ה let לפני ה key, מחליט ש key הוא string ולא מבין איך אפשר להשתמש ב string כללי בתור מפתח בגישה לאוביקט movie. התיקון הכי קל הוא להפוך את הגדרת המשתנה ל const:

const movie = { name: 'Return Of The Jedi', rating: 5 };
const key = Math.random() > 0.5 ? "name" : "rating";
console.log(movie[key]);

וככה טייפסקריפט מבין שהטיפוס של key הוא האיחוד בין שני הטיפוסים הליטרליים name ו rating, ובגלל ששניהם מפתחות ב movie הוא מרשה לי להשתמש ב key בתור מפתח באוביקט. נ.ב. לאלה מכן שפחות אוהבים להתחכם, אפשר לכתוב את אותה הדוגמה בלי ה random בכלל:

const movie = { name: 'Return Of The Jedi', rating: 5 };
let key = "name";
console.log(movie[key]);

אבל זה עלול להרוס את הכיף.

# האתר החדש באוויר אתר טוקוד החדש עלה לאוויר אתמול ואם אתם קוראים את זה מהאתר אתם כבר יכולים לראות את השינוי (אם אתם במייל או בטלגרם - תקפצו לבקר דרך הלינק). חוץ משינוי העיצוב יש גם כמה פיצ'רים חדשים: 1. נוספה אפשרות למנוי שנתי, בו אתם משלמים על 10 חודשים מראש ומקבלים את החודשיים האחרונים מתנה. 2. נוספה אפשרות למנוי בתשלום מראש שאינו מתחדש לתקופה לבחירתכם. אתם פשוט מסמנים כמה חודשים אתם רוצים, משלמים ושוכחים מזה. 3. נוספה אפשרות לצפיה בטקסט ובוידאו באותו זמן: בתוך נגן הוידאו אתם לוחצים על האייקון שמראה חץ קטן לתוך ריבוע בצד (זה בתוך הוידאו אני לא בטוח שתיארתי אותו נכון, פשוט תנסו את זה), ואז הסרט "יוצא" מהנגן ומתחיל לרחף באתר. כשזה קורה אתם עוברים לטאב "טקסט" ותוכלו לראות שהוידאו ממשיך להתנגן. בעתיד אולי אמצא דרך להשאיר את הוידאו מנגן גם בניווט לדפים אחרים. 4. נוסף "מצב חשוך" למי שאוהבים לקרוא מהטלפון בלילה. מאחורי הקלעים השינוי הכי גדול זה המעבר החוצה מריאקט לכלי ה JavaScript של ריילס שזה טורבו וסטימולוס. המטרה שלי כאן היתה להוריד עלויות ולאפשר שינויי עיצוב מהירים רק דרך שינוי HTML בלי לחשוב על המערכת בתור "אפליקציה", ובעצם להפוך את הקוד להרבה יותר פשוט. אם אתם מנויים של האתר ורוצים לעבור לאחד המסלולים של "מנוי שנתי" או "מנוי בתשלום מראש" כרגע תצטרכו לבצע "ביטול מנוי" וכשתקופת המנוי תסתיים תוכלו להירשם מחדש לאחד המסלולים. בקרוב אוסיף אפשרות של מעבר בין מסלולים למסך "החשבון שלי" וכשזה יקרה גם אעדכן פה בבלוג. למרות הרבה בדיקות שלי על הגירסה החדשה אני בטוח שיש לא מעט דברים שעדיין שבורים. אם אתם נתקלים בבעיות בבקשה אל תהססו להשאיר הודעה או לשלוח לי מייל. מקווה שתהנו מהאתר החדש ותמשיכו להצליח בקורסים. ינון.

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

https://youtu.be/jxi0ETwDvws Lol

# היום למדתי: פיירפוקס ומאפיין auto complete אחד המאפיינים שהכי פחות השתמשתי בהם בפיתוח הוא autocomplete של טפסים ותיבות טקסט. הנה הפיסקה מהתיעוד שמסבירה על הפיצ'ר: > The HTML autocomplete attribute lets web developers specify what if any permission the user agent has to provide automated assistance in filling out form field values, as well as guidance to the browser as to the type of information expected in the field. זה לא נשמע מלהיב כי רוב הזמן כשלא מציינים את המאפיין הזה דפדפנים מתנהגים כמו דפדפנים ועושים את הדבר הנכון. לפחות עד פיירפוקס. פיירפוקס רוצה לעזור למשתמשים ולכן כשהעמוד שלכם כולל טופס, ומשתמש התחיל להקליד טקסט בתוך התיבות ואז מרענן את העמוד, באופן אוטומטי פיירפוקס ימלא את הטקסט שקודם היה בתיבות גם בעמוד שנטען מחדש, כאילו שהמשתמש הקליד את הטקסט שוב (אבל בלי אירועי ה JavaScript שהיו מלווים לאותה הקלדה). התוצאה היא שאנחנו מאבדים וולידציות, השלמה אוטומטית או חיפושים שאולי מימשנו כשדף נטען מחדש אפילו אם זה היה בטעות, וזה גורם לטופס להיראות רע. וזה מחזיר אותנו למאפיין autocomplete. אם הטופס שלכם לא ערוך למילוי אוטומטי על ידי דפדפן, מומלץ להגיד לדפדפן לא למלא את השדות לבד. אפשר לבטל את automcomplete על הטופס כולו:

<form method="post" action="/form" autocomplete="off">
  …
</form>

או ברמת ה input:

<input type="text" id="cc" name="cc" autocomplete="off" />

אז כן כמובן שהכי טוב שהאתר שלכם מותאם לכל המצבים בעולם ויודע להתמודד עם טקסט שממולא אוטומטית בטופס על ידי הדפדפן, אבל אם זה לא המצב שווה לספר לדפדפן ולחסוך מבוכה מול המשתמשים. נ.ב. דוגמה? יאללה דוגמה. הנה קודפן: https://codepen.io/ynonp/pen/RwJPYYX. בקישור הזה אפשר לראות אותו על מסך מלא: https://cdpn.io/pen/debug/RwJPYYX הטופס כולל קוד טיפול באירוע שכותב את מספר התווים שבתיבת החיפוש מתחת לתיבה. אתם נכנסים עם פיירפוקס, מקלידים טקסט בתיבה ורואים את המספר גדל. אחרי זה לוחצים F5 כדי לרענן את העמוד ותוכלו לראות שהמספר התאפס אבל הטקסט עדיין כתוב בתיבה. בסוף תוכלו למזלג את הקודפן, להוסיף autocomplete=off ולראות איך הכל מסתדר.

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

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

ועם כל הכיף ביצירת פונקציות בקלות, כפתור אחד שאני אפילו יותר אוהב הוא Show Call Hierarchy. נוסיף קריאה ל twice לתוך אחת הפונקציות:

function clearHeadersText(headers: NodeListOf<Element>) {
  headers.forEach(header => {
    console.log(header.textContent);
  });
  alert(twice(5));
}

ועכשיו נכנס לקובץ utils.ts, כפתור ימני על הפונקציה twice ולחיצה על Show Call Hierarchy. בתגובה תקבלו את רשימת המקומות שהפונקציה הזאת נקראת בהם, וככה קל לזהות מי משתמש בפונקציה או להוסיף או להוריד פרמטר. ## עזרה בכתיבת הקוד גם בכתיבת קוד טייפסקריפט יודע לעזור לנו בעזרת מערכת השלמה אוטומטית המודעת לקונטקסט ומזהה מה אני רוצה לעשות. נעדכן את הפונקציה clearHeadersText לקוד הבא:

function clearHeadersText(headers: NodeListOf<HTMLHeadElement>) {
  headers.forEach(header => {
    console.log(header.textContent);
  });
  alert(twice(5));
}

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

header.addEventListener('

פה טייפסקריפט כבר יודע הרבה על מה שקורה מסביב: הוא יודע שיש לי ביד אלמנט מסוג HTMLHeadElement, והוא יודע איזה אירועים מותר לכתוב על אלמנט כזה. בידע הזה VS Code יכול להשתמש ובאמת רשימת ההשלמות שאני מקבל כוללת את כל האירועים האפשריים על אלמנטי head. בשביל המשחק נחזיר את סוג המשתנה להיות NodeListOf<Element> ונוכל לראות שרשימת האירועים הרבה יותר קטנה. לסיום נתקין ספריה חיצונית ונראה את ההשלמות שאנחנו מקבלים בשבילה. אני חוזר לשורת הפקודה ומפעיל:

npm install --save axios

בחזרה לקוד ונכתוב פשוט axios ו Enter ואוטומטית VS Code מוסיף את ה import המתאים. אחרי המילה axios כותבים נקודה ואוטומטית אנחנו רואים רשימה של כל השדות שיש על אוביקט axios. אני משלים ל get ושוב מקבל את רשימת הפרמטרים, כולל רשימת המפתחות באוביקט הקונפיגורציה ש get מצפה לקבל. ## סיכום העבודה עם טייפסקריפט עוזרת לנו לכתוב JavaScript ב-3 אופנים: 1. כלי הפיתוח יכולים לזהות טעויות של טיפוסים לא נכונים ולהתריע עליהן. 2. כלי הפיתוח יכולים לעזור להזיז קוד ממקום למקום, ולתקן את כל הקוד שמושפע מאותה הזזה. 3. כלי הפיתוח יכולים לעזור לנו בכתיבת הקוד ולחסוך הליכה לתיעוד, כדי לקבל השלמות רלוונטיות. כל פעם כשאני חוזר לפרויקט JavaScript אחרי כמה ימים או שבועות של עבודת טייפסקריפט נדרשת תקופת הסתגלות, כמו שפתאום נכנסים לחדר קצת יותר חשוך. בזמן העבודה עם JavaScript קשה לראות שמשהו היה חסר, אבל אחרי תקופה עם טייפסקריפט אתם תראו שקשה לחזור אחורה.

נמחק את ה import ונלך לבעוט בו עוד קצת, הפעם בפונקציות של השפה. ל TypeScript יש עוד שתי בדיקות שחשוב להכיר: קודם כל הוא מכיר את כל הפונקציות של ה DOM ושל JavaScript רגיל, ויגיד לנו כשאנחנו מעבירים פרמטרים לא נכונים. דבר שני הוא בעבודה עם ספריות חיצוניות, שם טייפסקריפט יכול להשלים לפי הגדרות טיפוסים שיש בהרבה ספריות. נתחיל עם הספריות המובנות ונוסיף את הבלוק הבא בתחילת הקובץ main.ts:

const headers = document.querySelector('h1,h2,h3,h4,h5,h6');
headers.forEach(h => {
  console.log(h.textContent);
});

רציתי לקחת את כל הכותרות, אבל השתמשתי בפונקציה הלא נכונה - במקום להשתמש ב querySelectorAll קראתי ל querySelector. טייפסקריפט מזהה ש querySelector מחזירה אלמנט DOM יחיד שלא כולל את הפונקציה forEach ולכן מסמן לי שלושה קווים אדומים: מתחת למילה headers, מתחת למילה forEach ומתחת למשתנה h. לפני שנצלול לקווים האדומים בואו נתקן את השגיאה ונחליף את הקריאה ל querySelectorAll. תוכלו לראות שכל הקווים האדומים נעלמו. עכשיו על מה טייפסקריפט התלונן? 1. הקו האדום הראשון מתחת ל headers צויר שם בגלל ש querySelector עלולה להחזיר null. אם היא החזירה null (למשל כי האלמנט לא קיים בדף) אז הפקודה שכתבתי תזרוק Exception ותרסק את התוכנית. 2. הקו האדום השני מתחת למילה forEach נמצא שם בגלל שגם אם querySelector היתה מחזירה את מה שרציתי, עדיין זה היה אלמנט בודד ולאלמנט אין פונקציית forEach. 3. הקו האדום השלישי הוא על ה h והוא הכי עדין כאן. טייפסקריפט רוצה להגיד שאפילו אם הוא טעה עד עכשיו, ואפילו אם באמת יש forEach על משהו שחוזר מ querySelectorAll, עכשיו הוא תקוע כי הוא לא יודע מה הטיפוס של כל אחד מהאלמנטים שצריכים לעבור ל Callback Function. אם זה היה querySelectorAll שהוא מכיר הוא היה יודע מה צריך לעבור שם, אבל בגלל שזו פונקציה אחרת שאתם טוענים שמחזירה מערך, אתם תצטרכו לתת לטייפסקריפט יותר מידע כדי לבדוק את המשך הקוד. ## עזרה בשינוי הקוד טייפסקריפט יכול לעזור לנו להזיז קוד ממקום למקום בעזרת כמה פונקציות נחמדות של VS Code: 1. כפתור Extract To Function יודע לקחת כמה שורות קוד ולהוציא אותן לפונקציה נפרדת, כאשר כל המשתנים הפנימיים הופכים להיות פרמטרים של הפונקציה. 2. כפתור Rename Symbol יודע לשנות שם של משתנה או פונקציה בכל המקומות בהם שם זה מופיע. 3. כפתור Show Call Hierarchy מראה את כל המקומות שקוראים לפונקציה מסוימת, כדי שיהיה לכם קל לשנות את כולם (למשל כדי להוסיף פרמטר לפונקציה). נראה את שלושת הדוגמאות. תחילה סמנו בקוד את השורות:

const headers = document.querySelectorAll('h1,h2,h3,h4,h5,h6');
headers.forEach(h => {
  console.log(h.textContent);
});

ולחצו כפתור ימני. בחרו Extract To Function In Module Scope ואז הקלידו שם עבור הפונקציה. אני אבחר בשם main. התוצאה היא פונקציה חדשה בשם main שנוצרה בסוף הקובץ:

function main() {
  const headers = document.querySelectorAll('h1,h2,h3,h4,h5,h6');
  headers.forEach(h => {
    console.log(h.textContent);
  });
}

שלב שני - נסמן את שלושת השורות התחתונות של הפונקציה (כלומר בלי השורה שמגדירה את המשתנה headers) ונלחץ שוב על הכפתור הימני ושוב נבחר Extract To Function In Module Scope. הפעם אני בוחר בשם clearHeadersText ואני יכול לראות שהפונקציה מקבלת כקלט משתנה headers שאמור להיות מסוג NodeListOf<Element>. ככה היא נראית:

function clearHeadersText(headers: NodeListOf<Element>) {
  headers.forEach(h => {
    console.log(h.textContent);
  });
}

מבחינת VS Code ההבדל בין שני ה Refactorings היה שבפעם הראשונה הקוד התיחס למשתנה גלובאלי, ולכן אם הייתי מוציא רק את שלושת השורות האחרונות לפונקציה היא היתה ממשיכה להתיחס לאותו משתנה גלובאלי headers. בפעם השניה המשתנה headers היה משתנה פנימי של פונקציה main, ולכן בשביל להוציא החוצה את שלושת השורות לפונקציה חדשה אותה פונקציה חדשה חייבת לקבל את הערך של headers. נמשיך ל h בתוך הלולאה:

  headers.forEach(h => {
    console.log(h.textContent);
  });

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

# יתרונות של TypeScript למתכנתי JavaScript טייפסקריפט נכתבה ב 2010 כשהעולם של JavaScript היה שונה מאוד והרבה יותר מבולגן ממה שהוא היום. היא הגיעה עם שתי בשורות: היא הוסיפה מערכת טיפוסים לשפה כדי שיהיה יותר קל לכתוב פרויקטים גדולים, והיא הוסיפה תמיכה ביכולות "חדשות" של השפה שהתקרבו לתקן אבל עדיין לא היו בתוכו או בדפדפנים. אני מזכיר שב 2010 שוק הדפדפנים וועדות התקינה היו בקיפאון, גירסת JavaScript שעבדה ברוב הדפדפנים היא ES3 והיא כבר לא התאימה לפרויקטים מודרניים. לימים JavaScript יצאה מהקיפאון והיום התקן מתעדכן וגם הדפדפנים מוסיפים יכולות חדשות בצורה עקבית, כך שאין כבר טעם להשתמש ב TS כדי לקבל יכולות אלה. החדשנות של TS אם כן עברה למערכת הטיפוסים שלה, ולכלי פיתוח מעולים שאפשר לבנות בזכות אותה מערכת טיפוסים. ## מה TypeScript נותן לנו כמפתחי JavaScript טייפסקריפט היא Superset של JavaScript. זה אומר שכל קובץ JavaScript שתיקחו הוא גם קובץ טייפסקריפט תקני. בנוסף VS Code משתמש בכל הכלים של טייפסקריפט אוטומטית גם בעבודה על קבצי js וגם בעבודה על קבצי ts. לכן ובמיוחד אם אתם עובדים ב VS Code, השאלה היא לא אם להשתמש ב TypeScript, אלא באיזו מידה. האם אתם מוכנים להסתפק בבדיקות ובהשלמות ברירת המחדל של VS Code ולהישאר עם קבצי ה js שלכם? האם אתם רוצים "לעזור" קצת ל VS Code ולהוסיף מידע על הטיפוסים תוך כדי כתיבת הקוד? האם אתם רוצים להיעזר ב VS Code ולהוסיף וולידציות על הקוד, כך שתוכלו להשתמש רק בקוד "בטוח" בפרויקט שלכם? הדברים המרכזיים שנקבל מ TypeScript בתור מפתחי ווב הם: 1. עזרה בבדיקת הקוד - כדי לוודא שאנחנו משתמשים בפונקציות שלנו ובפונקציות של אחרים כמו שהתכוונו. 2. עזרה בשינוי הקוד - כדי לוודא ש Refactor מסוים לא שובר קוד במקומות שלא חשבנו עליהם, וכדי לתקן אוטומטית את מה שאפשר. 3. עזרה בכתיבת הקוד - כדי להציע לנו השלמות רלוונטיות במהלך הכתיבה. בואו נראה דוגמאות לשלושת הסעיפים. ## עזרה בבדיקת הקוד אני מתחיל עם פרויקט TypeScript חדש שיצרתי באמצעות vite עם הפקודה:

$ npm create vite@latest

ובחרתי בתפריטים Vanilla TypeScript. אני יוצר קובץ חדש בתיקיית src בשם utils.ts עם התוכן הבא:

export function twice(x: number) {
  return x * 2;
}

אנחנו רואים שאנחנו עובדים על קובץ TypeScript לפי הסיומת, ואנחנו רואים שהוספתי אחרי שם המשתנה בכניסה לפונקציה סימן נקודותיים ואחריו את המילה number. זה אומר שאני מתכוון שהמשתנה x תמיד יקבל ערך מספרי. שומר את הקובץ וממשיך ל main.ts שכבר קיים בפרויקט. שם בשורה 4 אני כותב:

alert(twice(10));

אני רואה שמתחת למילה twice מופיע לי קו אדום שאומר ש VS Code לא מזהה את המילה. כשאני משתהה עם הסמן מעל המילה twice אני מקבל את ההודעה:

Cannot find name 'twice'.ts(2304)

קוד השגיאה 2304 יכול לעזור לי אם אצטרך לחפש בגוגל קצת יותר מידע על מה בדיוק קרה שם, אבל הפעם השגיאה די מסבירה את עצמה - טייפסקריפט לא מצליח למצוא את השם twice. עכשיו שימו את הסמן על המילה האדומה ותוכלו לראות מנורה קטנה מופיעה בתחילת השורה קצת מעל המילה alert. זאת מנורת התיקון האוטומטי. נלחץ עליה וייפתח תפריט עם האפשרויות: 1. Add import from utils 2. Add missing function declaration 'twice' אפשרות שניה לטייל בין השגיאות היא עם כפתור F8. לחצו עליו והסמן מיד יקפוץ למילה twice עם הודעת השגיאה מתחת למילה. נבחר באפשרות Add import from utils, והקו האדום נעלם. אבל עכשיו בואו ניקח את זה עוד צעד קדימה - אני יודע שהפונקציה מצפה לקבל מספר, וגם typescript יודע את זה. נשנה את הקריאה ל:

alert(twice("yay"));

ושוב קו אדום, הפעם מתחת למילה yay. ההודעה הפעם:

Argument of type 'string' is not assignable to parameter of type 'number'.ts(2345)

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

'twice' is declared but its value is never read.ts(6133)

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