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

המודול csv של פייתון נותן לנו פיתרון ממש פשוט כשאנחנו רוצים לקרוא קובץ CSV ולגשת לשדות שלו מתוך תוכנית פייתון. שימו לב לתוכנית הדוגמא הבאה שקוראת קובץ בשם my.csv:

import csv
with open('my.csv', encoding='utf8', newline='') as csvfile:
    reader = csv.reader(csvfile)
    for row in reader:
        print(row[-1])

נקרא את התוכנית שורה אחר שורה:

1. הפקודה import מייבאת את המודול csv לתוכנית. מודול זה מגיע עם פייתון ולא דורש שום התקנה מיוחדת. המודול מספק לנו ממשק לעבודה עם מידע בפורמט CSV.

2. הפקודה השניה פותחת את הקובץ my.csv ושומרת את הקישור אליו במשתנה בשם csvfile. בגלל שהקובץ נפתח בתוך בלוק with, בסיום הבלוק באופן אוטומטי הקובץ ייסגר בסיום הבלוק. מילת המפתח encoding תעזור לפייתון להתמודד עם קובץ בכל שפה ומילת המפתח newline גורמת לקובץ לא לטפל בשורות חדשות (כי המודול CSV יהיה זה שיטפל בהן).

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

4. בפקודה הרביעית אנחנו רצים בלולאה על כל השורת ב Reader. כל שורה מתקבלת בתור רשימת ערכים למשתנה row.

5. בפקודה החמישית בשביל הדוגמא אני מדפיס את התא האחרון בשורה.

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

למידע נוסף על CSV Reader שווה להעיף מבט בתיעוד בקישור: https://docs.python.org/3.8/library/csv.html#id3

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

להרבה אנשים שמתחילים עם ריאקט יצא לעשות את הטעות הבאה ב Class Component:

class Counter {
  constructor() {
    this.state = { count: 0 };
  }

  inc = () => {
    this.setState({ count: this.state.count + 1 });
  }

  render() {
    return (
      <button onClick={this.inc}>{this.state.count}</button>
    );
  }
}

שזהה לטעות הבאה ב Functional Component:

function Counter() {
  const [count, setCount] = useState(0);

  function inc() {
    setCount(count + 1);
  }

  return (
    <button onClick={inc}>{count}</button>
  );
}

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

function Counter() {
  const [count, setCount] = useState(0);

  function inc() {
    const nextValue = count + 1;
    setCount(nextValue);
    setCount(nextValue);
  }

  return (
    <button onClick={inc}>{count}</button>
  );
}

או בגירסת הקלאסים:

class Counter {
  constructor() {
    this.state = { count: 0 };
  }

  inc = () => {
    const nextValue = this.state.count + 1;
    this.setState({ count: nextValue });
    this.setState({ count: nextValue });
  }

  render() {
    return (
      <button onClick={this.inc}>{this.state.count}</button>
    );
  }
}

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

  inc = () => {
    this.setState({ count: this.state.count + 1 });
    this.setState({ count: this.state.count + 1 });
  }

אני חושב שמה שהיה קצת מוזר ב Class Component והפך למאוד ברור במעבר ל Hooks הוא שהפונקציה setState לא משנה את הסטייט באופן מיידי אלא רק בפעם הבאה שיקרא render אז נקבל את הסטייט העדכני.

״זה מסובך מדי״

״כל האנשים שיודעים את זה התחילו בגיל הרבה יותר צעיר״

״זה ייקח יותר מדי זמן״

״זה בעצם לא שווה את ההשקעה״

״אולי בשנה הבאה אהיה יותר זמין לנסות ללמוד שוב״

״אני ממילא לא הולך להשתמש בזה״

״עד עכשיו הסתדרתי טוב בלי לדעת את זה״

״אני בחיים לא אבין את זה״

״גם אם אצליח להבין בחיים לא אהיה טוב בזה״

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

הפונקציה React.lazy משמשת לטעינה עצלה של פקדי ריאקט, כלומר היא תאפשר לנו בצורה מאוד קלה להגדיר שפקד ריאקט מסוים לא ייכלל בקובץ ה JS הגדול של העמוד וייטען רק אם מישהו ינסה לעשות לו render. דוגמא פשוטה לשימוש בה אפשר למצוא בתיעוד והיא נראית כך:

const OtherComponent = React.lazy(() => import('./OtherComponent'));

function MyComponent() {
  return (
    <div>
      <Suspense fallback={<div>Loading...</div>}>
        <OtherComponent />
      </Suspense>
    </div>
  );
}

כתיבת קוד React כזה בתוך פרויקט תגרום לוובפאק באופן אוטומטי לפצל את הקוד של הפרויקט ולשמור את הקוד של OtherComponent בקובץ js נפרד, שייטען בצורה אסינכרונית ב Ajax אחרי טעינת העמוד.

קסם? לא ממש. רוב מה ש React.lazy עושה אנחנו יכולים לעשות נפלא גם בלעדיו - בואו נראה איך.

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

def v1(fin_name, fout_name):
    with open(fin_name, encoding='utf8') as fin:
        with open(fout_name, 'w') as fout:
            for line in fin:
                fout.write(line)

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

פיתרון קל למצב הזה אפשר למצוא במודול contextlib שמגיע כחלק מהספריה הסטנדרטית של פייתון. הפונקציה ExitStack מתוך אותו מודול היא Context Manager שמחבר יחד Context Managers אחרים, או בשפה פשוטה היא מאפשרת להשתמש בבלוק with אחד כדי לתפוס מספר דברים שיכולים להישבר.

הנה הקוד אחרי שהוספתי את ExitStack:

from contextlib import ExitStack
def v2(fin_name, fout_name):
    with ExitStack() as stack:
        fin  = stack.enter_context(open(fin_name, encoding='utf8'))
        fout = stack.enter_context(open(fout_name, 'w'))
        for line in fin:
            fout.write(line)

הפונקציה ExitStack מחזירה אוביקט שיש לו פונקציות __enter__ ו __exit__, וגם פונקציה בשם enter_context. הפונקציה enter_context מצפה בתורה לקבל משהו שיש לו __enter__ ו __exit__, מפעילה מיד את ה __enter__ של מה שקיבלה, וכשמגיע ה __exit__ של ה ExitStack הוא קורא באופן אוטומטי ל __exit__ של כל האוביקטים שעברו אליו דרך enter_context.

ל ExitStack יש עוד כמה טריקים עליהם לא סיפרתי ואם אתם סקרנים תוכלו למצוא את כל הפרטים בדף התיעוד. קריאה מהנה.

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

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

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

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

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

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

יש רק שלוש שאלות ששווה להתלבט לגביהן לפני שמחליטים אם לקחת או לא לקחת מסלול לימוד מסוים (קורס, ספר, השתתפות במיטאפ, פיתוח פרויקט לבד וכו'):

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

הי חברים,

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

אני יכול לראות את השיעור כמה פעמים שאני צריך עד שאני מבין.

אני יכול לדלג על קטעים שלא מעניינים אותי.

אני יכול להתאמן בלי שאף אחד מסתכל.

ואני יכול לשאול שאלות בלי להרגיש שרק אני לא הבנתי.

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

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

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

הקורס הראשון יהיה React ומיועד למתכנתים שכבר יודעים לכתוב קוד Front End, מכירים JavaScript ברמה סבירה אבל מכל מיני סיבות לא הצליחו עדיין להיכנס לשוק העבודה למשרות ה Front End הטובות באמת. הקורס ייפתח באמצע מרץ ויימשך חודשיים.

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

לכל הפרטים על קורס ריאקט הקרוב מוזמנים לקפוץ לדף הנחיתה החדש שבניתי בקישור https://www.tocode.co.il/bundles/react

נתראה בקורס ינון

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

כך קרה לי עם אלמנטים שניתנים לעריכה - למרות שחיפשתי ומצאתי מספר ספריות ב npm עבור Editable React Components, בסוף לכל אחת היו את הבעיות שלה ומימוש לבד של הקוד נתן לי את השליטה הכי מדויקת. וזה אפילו לא היה כזה מסובך.

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

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

function EditableLabel_View(props) {
  const { text, startEdit } = props;
  return (<p onClick={startEdit}>{text}</p>);
}

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

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

function EditableLabel_Edit(props) {
  const { text, setText, done } = props;

  function doneIfEnter(e) {
    if (e.keyCode === 13) {
      done();
    }
  }

  return (
    <input
      type="text"
      value={text}
      onChange={(e) => setText(e.target.value)}
      onBlur={done}
      onKeyDown={doneIfEnter}
      />
  );
}

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

function EditableLabel(props) {
  const [text, setText] = useState(props.text);
  const [edit, setEdit] = useState(false);

  if (edit) {
    return <EditableLabel_Edit text={text} setText={setText} done={() => setEdit(false)} />
  } else {
    return <EditableLabel_View text={text} startEdit={() => setEdit(true)} />
  }
}

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

class App extends React.Component {
  render() {
    return (
      <div>
        <EditableLabel text="Hello world" />
      </div>
    );
  }
}

ואפשר לראות את הקסם כולו בפעולה בקודפן הבא:

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

function makeEditableComponent(View, Edit) {
  return function EditableLabel(props) {
    const [data, setData] = useState(props.defaultValue);
    const [edit, setEdit] = useState(false);

    if (edit) {
      return <Edit data={data} setData={setData} done={() => setEdit(false)} />
    } else {
      return <View data={data} startEdit={() => setEdit(true)} />
    }
  }
}

היתרון הוא שעכשיו קל מאוד לייצר את EditableLabel או כל קומפוננטה דומה פשוט באמצעות הפעלת הפונקציה:

const EditableLabel = makeEditableComponent(EditableLabel_View, EditableLabel_Edit);

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