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

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

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

<input type='text' required="required" />

וזה היה עובד ברוב הדפדפנים אבל טקסט הודעת השגיאה היה אחיד.

בשנים שעברו מאז נכנס API חדש בשם Constraint Validation API שכולל מנגנון מתוך JavaScript לקבוע את טקסט הודעת השגיאה עבור שגיאות וולידציה. זו טבלת התמיכה במנגנון בדפדפנים השונים:

https://caniuse.com/#feat=constraint-validation

התמיכה קיימת בכל הדפדפנים המובילים כולל IE10. מתכנתי ווב שעדיין זוכרים איך לכתוב Client Side Validation לפני HTML5 מפסידים פיצ'ר שחוסך המון עבודה ועובד הרבה יותר טוב מכל מנגנון אחר שתנסו לבנות לבד.

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

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

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

בואו נראה מתי זה טוב ואיך בונים את זה בפייתון.

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

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

לא. שתי הגישות שגויות

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

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

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

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

בן אדם קם בבוקר פותח את הפייסבוק לבדוק- מה חדש?

ממשיך לטוויטר, לעיתון, לאינסטוש, ללינקדאין- ותמיד אותה שאלה: מה חדש? מה קרה עכשיו?

וזה כמובן בזבוז זמן טוטאלי.

בגלל זה אני מעדיף ספר ליד המיטה. וכמה שיותר ישן יותר טוב. בספר אין לך פייסבוק, וטוויטר ואינסטוש. הספר לא יספר לך מה קרה אתמול (או אפילו לפני שנה).

במקום לשאול מה חדש בואו ננסה לשאול "מה חשוב?", מה ישן ועדיין כאן. מה שווה שאקרא אותו שוב ושוב.

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

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

ספריית jQuery נוצרה כדי לתת לנו ממשק עבודה טוב יותר עם ה DOM. בתקופה ש jQuery התחילה כל דפדפן סיפק פונקציות שונות כדי לחבר בין קוד JavaScript לבין התוכן שאתם רואים על הדף. ג'ון רסיג כתב את jQuery ב 2005 בזמן שלמד בקולג' במטרה לתת למתכנתים (ולעצמו) כלים טובים יותר לגשת ל DOM ולחבר קוד טיפול באירועים בצורה שעובדת טוב בכל הדפדפנים.

בשנה הראשונה של jQuery היא היתה הספריה היחידה שהגיעה עם תיעוד מלא. כל שאר הספריות שלחו אתכם להסתכל בקוד המקור שלהן או להבין דברים לבד. מאפיין זה יחד עם ארכיטקטורת פלאגינים שבנויה לתוך הספריה הפכו אותה מ"עוד ספריה לגישה ל DOM" לספריה המרכזית שאנשים בוחרים בה ב 2006, ב-2012 וכן גם ב 2018.

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

שתי יכולות של תקשורת Ajax ב jQuery מחזירות את הסיפריה הוותיקה לחיים והופכות את השימוש בה להרבה יותר מהנה מכל API מקביל שיש בדפדפן. הראשונה היא השימוש ב Promises והשניה היכולת לקבוע Headers בצורה גלובאלית לכל בקשות התקשורת בעמוד.

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

אפשר לחשוב על פלאגין בתור פונקציה שמקבלת כפרמטר איזשהו DOM Element. וזה כנראה יהיה די קרוב למציאות. אנחנו מצרפים פלאגין ליישום באמצעות הדבקת פונקציה כזו על שדה מסוים ב jQuery Object ומשם אפשר להפעיל את הפלאגין על כל אלמנט בעמוד.

ספריית jQuery התחילה עם רעיון פשוט וגאוני: לבנות API טוב יותר ואמין יותר עבור ה DOM. בימים שהם התחילו המצב היה הרבה יותר גרוע ממה שהוא היום והצורך ב API אמין לחיבור בין JavaScript לאלמנטים על המסך היה מאוד בולט.

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