ToCode

# קריאה מודרכת בפונקציה groupBy מ lodash לקרוא קוד של אחרים זו דרך טובה לקבל רעיונות, ללמוד Best Practices וגם לראות שטויות שאחרים עושים כדי להרגיש קצת פחות רע עם השטויות שלנו - והיום עם גיטהאב קל לקרוא אפילו מהטלפון. בואו ננסה יחד לקרוא את הקוד של groupBy מספריית ה JavaScript הפופולרית lodash ונראה מה נוכל ללמוד ממנו. ## נקודת ההתחלה - הקובץ groupBy בכניסה למאגר של lodash אנחנו שמים לב קודם כל שהספריה מחולקת לקבצים וכל פונקציה נמצאת בקובץ משלה. הקובץ package.json מספר לנו שהקובץ הראשי בספריה נקרא lodash.js:

{
  "name": "lodash",
  "version": "5.0.0",
  "license": "MIT",
  "private": true,
  "main": "lodash.js",
  "engines": {
    "node": ">=4.0.0"
  },
  "sideEffects": false,
  "scripts": {
    "style": "eslint *.js .internal/**/*.js",
    "test": "mocha -r esm test/*.test.js",
    "validate": "npm run style && npm run test"
  },
  "devDependencies": {
    "mocha": "^5.2.0",
    "eslint": "^7.16.0",
    "eslint-plugin-import": "^2.22.1",
    "lodash": "4.17.20",
    "esm": "^3.2.25"
  }
}

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

import baseAssignValue from './.internal/baseAssignValue.js'
import reduce from './reduce.js'

/** Used to check objects for own properties. */
const hasOwnProperty = Object.prototype.hasOwnProperty

/**
 * Creates an object composed of keys generated from the results of running
 * each element of `collection` thru `iteratee`. The order of grouped values
 * is determined by the order they occur in `collection`. The corresponding
 * value of each key is an array of elements responsible for generating the
 * key. The iteratee is invoked with one argument: (value).
 *
 * @since 0.1.0
 * @category Collection
 * @param {Array|Object} collection The collection to iterate over.
 * @param {Function} iteratee The iteratee to transform keys.
 * @returns {Object} Returns the composed aggregate object.
 * @example
 *
 * groupBy([6.1, 4.2, 6.3], Math.floor)
 * // => { '4': [4.2], '6': [6.1, 6.3] }
 */
function groupBy(collection, iteratee) {
  return reduce(collection, (result, value, key) => {
    key = iteratee(value)
    if (hasOwnProperty.call(result, key)) {
      result[key].push(value)
    } else {
      baseAssignValue(result, key, [value])
    }
    return result
  }, {})
}

export default groupBy

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

/** Used to check objects for own properties. */
const hasOwnProperty = Object.prototype.hasOwnProperty

לבד השורה הזאת נראית תמוהה- הרי אנחנו יודעים מה Object.prototype.hasOwnProperty עושה ב JavaScript. אבל אם נחפש בעוד קבצים בספריה נגלה שכל פעם שמוגדר const גלובאלי בקובץ יש מעליו הערה שמסבירה מה תפקידו. לדוגמה בקובץ clone.js אנחנו מוצאים את:

/** Used to compose bitmasks for cloning. */
const CLONE_SYMBOLS_FLAG = 4

וב conforms.js אני מוצא את:

/** Used to compose bitmasks for cloning. */
const CLONE_DEEP_FLAG = 1

וב isArrayBuffer.js יש לי את:

/* Node.js helper references. */
const nodeIsArrayBuffer = nodeTypes && nodeTypes.isArrayBuffer

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

function groupBy(collection, iteratee) {
  return reduce(collection, (result, value, key) => {
    key = iteratee(value)

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

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

# משחקים עם Deta לא, זו לא שגיאת כתיב בכותרת - אכן יש מערכת ענן חינמית לגמרי בשם deta שכוללת גם בסיס נתונים וגם אפשרות לכתוב קוד ווב ב Python או Node.JS. הלכתי לשחק עם ה API שלהם כדי לראות מה אפשר לקבל בלי לשלם. ## מה בקופסה הסלוגן אומר: > Deta is a free cloud crafted with the developer and user experience at heart. וזה סוג-של נכון. לקח לי שתי דקות להקים חשבון ועוד 5 דקות לקבל אתר ווב באוויר. בשביל להתחיל לעבוד אנחנו מתקינים את ה CLI Client שלהם (הוראות באתר), מפעילים משורת הפקודה deta login ואז ממלאים טופס ולוחצים על קישור במייל שנשלח אליכם. חוץ מלהקים מערכת ווב בפייתון (עם פלאסק) הם גם תומכים ב: 1. חיבור דומיין שלכם למערכת. 2. הפעלת משימות מתוזמנות עם cron. 3. אחסון קבצים עם מערכת שנקראת Data Drive (עד 10 ג'יגה). 4. אחסון נתונים עם מערכת שנקראת Deta Base. החיסרון היחיד שמצאתי הוא שאי אפשר למחוק פרויקט. לא הצלחתי להבין למה. וגם לא מצאתי התיחסות ל Rate Limits או דברים כאלה. ## התוכנית הראשונה שכתבתי בשביל המשחק כתבתי שם תוכנית פייתון שסופרת כמה בקשות POST שלחתם אליה ושומרת את התוצאה בבסיס נתונים. זה הקוד:

from flask import Flask
from deta import Deta

deta = Deta()
counters = deta.Base('counters')

app = Flask(__name__)

@app.route('/', methods=["GET"])
def get_root():
    record = counters.get('posts') or { "count": 0 }
    return f"{record['count']} POST requests were sent so far"

@app.route('/', methods=["POST"])
def post_root():
    try:
        updates = {
                "count": counters.util.increment(1)
                }
        counters.update(updates, "posts")
        record = counters.get('posts')
        return f"{record['count']} POST requests were sent so far"
    except Exception as err:
        # can only update existing records
        try:
            counters.put({ "key": "posts", "count": 1 })
            record = counters.get('posts')
            return f"{record['count']} POST requests were sent so far (including yours)"
        except Exception as err:
            return f"Error - {err}"

החלקים המעניינים ממנו לדעתי: 1. תמיכה מלאה ב flask, וכנראה בספריות פייתון באופן כללי (אפשר לכתוב קובץ requirements.txt והם מתקינים כל מה שנמצא בו) 2. בסיס הנתונים Deta Base מבוסס רשומות ומזכיר בסיסי נתונים NoSQL, אבל בגירסה מאוד מאוד פשוטה שלהם ועם API מסורבל. הפונקציה update לדוגמה לא מחזירה את הערך המעודכן אז בשביל לקבל אותו הייתי צריך להפעיל עוד בקשת get, מה שלא בטוח יחזיר תוצאה נכונה (ויש עוד כמה באגים מהסוג הזה בתוכנית). 3. אפשר להשתמש רק בבסיס הנתונים, או רק ב Web Framework, או רק באחסון הקבצים, או בכולם יחד. סך הכל מקום איחסון בחינם לפרויקטי ווב זה תמיד רעיון טוב. הייתי שמח יותר אם הם היו נותנים לי מכונה או קלאסטר קוברנטיס, אבל כשלא משלמים אי אפשר להתלונן. האתר מאוד מתאים לפרויקטי צד שלכם כשמחפשים פשוט לעלות לאוויר איזה API בפייתון או Node.JS בלי להתעסק עם שרתים.

# איך לשנות כללי ESLint ב create-react-app בכתיבת קוד בדיקה תקופה ארוכה שאני מעדיף להשתמש בערך ההחזר של render במקום ב screen הגלובאלי בעת כתיבת הבדיקות, כלומר אני מעדיף את הגירסה הזאת:

import { render } from '@testing-library/react';
import App from './App';

test('renders learn react link', () => {
  const screen = render(<App />);
  const linkElement = screen.getByText(/learn react/i);
  expect(linkElement).not.toBeInTheDocument();
});

על פני:

import { screen, render } from '@testing-library/react';
import App from './App';

test('renders learn react link', () => {
  render(<App />);
  const linkElement = screen.getByText(/learn react/i);
  expect(linkElement).not.toBeInTheDocument();
});

הסיבה היא ההבדל הפונקציונאלי בין שתי הגישות. בגישה הראשונה כל השאילתות יתפסו רק אלמנטים מהקומפוננטה ש render עכשיו הציג, ובגישה השניה השאילתות מתחילות מ body ולכן יכולות לתפוס גם אלמנטים שהיו שם קודם. בתקופה האחרונה העדפה זו נהייתה קשה יותר לביצוע בגלל ש create-react-app כולל הגדרות eslint שממליצות בדיוק על ההיפך, כלומר על הגישה השניה. ההסבר שלהם כאן: https://github.com/testing-library/eslint-plugin-testing-library/blob/main/docs/rules/prefer-screen-queries.md מה עושים? מתקנים את ה eslint כמובן. בתוך הקובץ package.json של פרויקט create-react-app חדש נוכל למצוא את הבלוק הבא:

  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },

כל מה שצריך לעשות זה לזהות את שם הכלל מתוך הודעת השגיאה או דף ההסבר על הכלל, במקרה שלנו הכללים הבעייתיים הם testing-library/prefer-screen-queries ו testing-library/render-result-naming-convention ואז מוסיפים בלוק rules ל package.json שמנטרל את שניהם:

  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ],
    "rules": {
      "testing-library/prefer-screen-queries": "off",
      "testing-library/render-result-naming-convention": "off"
    }
  },

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

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

# למה למידה היברידית לא עובדת ומה אפשר לעשות במקום השבוע הודיעו גם רן ארז וגם יפה בן דויד על התנגדות למודל "הלמידה ההיברידית" הנוכחי. אני כותב למידה היברידית במרכאות כי למידה היברידית אמיתית היא בהחלט חיובית, והיא לא מה שקורה עכשיו בבתי הספר. בואו נפתח את זה כדי להבין מה קורה עכשיו בבתי הספר, למה זה לא עובד ומה אפשר לעשות במקום. ## מה זה למידה היברידית למידה היברידית, או בשמה המקובל יותר למידה מעורבת (Blended Learning) מוגדרת בויקיפדיה בתור "שיטת לימוד המשלבת הוראה מסורתית, כלומר למידה "פנים-מול-פנים", עם למידה מקוונת ו-E-learning, בגישה זו יש אלמנטים בהם התלמיד שולט על זמן, קצב, מקום ונתיב הלימוד, בשילוב לימוד פרונטלי בכיתה". מניסיון בהדרכת לא מעט קורסים בשיטה זו, למידה היברידית דורשת אחריות גדולה מצד התלמידים אבל אלה שמצליחים להתמיד מגיעים להישגים טובים בהרבה מכל שיטת לימוד אחרת שניסיתי. היכולת של תלמידים לקבוע את הקצב, היכולת להתייעץ במורה כל הזמן, בשילוב עם המסגרת החברתית של למידה בכיתה מאפשרת לכל תלמיד לקבל את המקסימום שנכון עבורו מהקורס. בלמידה מעורבת כל התלמידים עוברים את אותו מסלול מבחינת "שיטת הלימוד", אבל הסילבוס שכל אחד יגיע ללמוד יהיה שונה ויתאים לו אישית. זה אינו המתווה שמתרחש היום בכיתות רבות בארץ. בכיתות בהן יש מאומתים לקורונה, תלמידים בעלי תו ירוק ממשיכים להגיע לכיתה ובמקביל התלמידים האחרים צופים בשיעור דרך הזום בבית. המורה צריך ללמד את שתי קבוצות התלמידים במקביל, למרות שלכל קבוצה דרך תקשורת שונה וצרכים שונים. ## למה זה לא עובד הדרכה פרונטלית, שאנחנו מדברים עליה כאילו היא דבר טבעי, לא באה בקלות לרוב המורים. זה משהו שאנחנו צריכים להתאמן עליו והיינו צריכים ללמוד איך לעשות אותו טוב. הדרכה פרונטלית מורכבת משליחת מסרים רלוונטים לקבוצה של אנשים שיושבים מולך, סינכרון מתמיד והתאמת הקצב או משיכת תלמידים חזרה לקצב כשהם הולכים לאיבוד. בשיעור טוב הכל מתוכנן ובאותו זמן כלום לא ידוע מראש. אני יכול להגיע ללמד את אותו נושא לקבוצות שונות, ובכל קבוצה זה יראה אחרת. הדרכה פרונטלית היא כולה התאמה של הנושא לקבוצה איתה אתה מדבר. בהדרכה בזום הקשר הוא משמעותית פחות חזק. רוב המשתתפים יעשו עוד פעולות תוך כדי הצפיה בזום ויתקשו לשמור על ריכוז לאורך כל ההרצאה. אין שום דרך להסתכל על הקבוצה כולה ולזהות מי אתך ומי לא. מורים מתמודדים עם זה באחת משתי דרכים: או על ידי העברת הרצאה בסגנון סרט, שכמעט הכל מוקלט ומתוכנן מראש (אני עושה את זה בוובינרים כאן באתר); או על ידי יצירת חוויה סופר אינטרקטיבית עם סקרים, משחקי קבוצה ועוד פעילויות חברתיות. הניסיון לשלב בין שתי שיטות ההדרכה באותו שיעור אומר שחייבים לבחור: או שאנחנו מעבירים שיעור בזום ומשתפים את מי שנמצא בכיתה, או שאנחנו מעבירים שיעור פרונטלי ומשדרים אותו לזום. שתי השיטות ייכשלו. אם אני בוחר להעביר שיעור בזום ומנסה להסתנכרן עם הקהל שלי שנמצא בזום אז אני צריך לזכור שהם עושים עוד דברים באותו זמן, ולכן אין לי באמת קצב שיחה אחיד לכולם. האנשים בכיתה ישתעממו כי הם היחידים שרק מקשיבים להרצאה (כל האחרים גם מקשקשים בטלפון באותו זמן). אם אני בוחר שיעור לכיתה ופשוט משדר אותו לזום, אז אותם אנשים שמסתכלים מרחוק מהר מאוד ילכו לאיבוד, כי אני לא מחכה להם, והם לא מצליחים לשמור על אותה רמת ריכוז כמו המשתתפים שנמצאים בכיתה. הם יוכלו לראות את השיעור כמו שרואים סרט, אבל הרצאות פרונטליות בדרך כלל לא מספיק מדויקות וחסרה להן העריכה שיש בסרטים מוקלטים, כך שהן גם לא כל כך מהנות לצפיה אם אתה לא שם. וכל זה לפני שדיברנו על תקלות טכניות, מישהו שחוזר לזום אחרי שהתנתק לו המחשב, lag-ים למיניהם וכל הצרות שמוציאות אותנו מריכוז, ואיך זה משפיע על המשתתפים שנמצאים בכיתה. ## מה אפשר לעשות במקום הפיתרון לבעיית הלימודים בקוביד הוא פשוט כמו שהוא קשה ליישום. המפתח הוא ההבנה של התפקיד הכפול של בתי הספר היום: גם בתור מקום שמקנה ידע, וגם בתור מקום מפגש ומרכז החיים החברתיים של התלמידים שלומדים בהם. עלינו להפריד בין שני התפקידים ולייצר פיתרון שונה לכל אחד. בצד הלימודי אין שום הגיון בלימוד פרונטלי מעורב בזום. בהנחה שתלמידים מסוימים יצטרכו ללמוד מרחוק, עדיף לייצר קיטים ללימוד עצמי של הנושאים השונים ולפתוח לתלמידים חדר זום שיפעל כל היום ברצף אליו יוכלו להיכנס עם שאלות על נושאי הלימוד. בכל חדר יהיה מתרגל מומחה במקצוע שיוכל לענות תשובות מקצועיות לתלמידים.

# זה לא חשוב אם את רוצה לפתוח בלוג, זה לא חשוב באיזו פלטפורמה תבחרי או אם תכתבי לעצמך. מה שחשוב זה לכתוב פוסטים. אם את רוצה לבנות מערכת, לעצב את הדפים ולכתוב את כל ה CSS בשבילם זה לא חשוב. מספיק שהאיפיון יהיה טוב והפונקציונאליות תהיה במקום. ואותו דבר לגבי הבחירה בין Redux ל MobX, בין ריאקט ל Vue, בין GraphQL ל REST. ובכל זאת נדמה שהאושר הכי גדול שלנו הוא להיתקע על אותן פינות לא חשובות הרבה יותר מדי זמן בתור צורה של הסחת דעת. כאילו הלב רוצה לעשות הכל חוץ מלהתקדם. טריק שעובד לי במקרים כאלה הוא "להשאיר לאחר כך" את ההתלבטות. את ה CSS אפשר להשאיר ריק, במקום רידאקס או מובאקס פשוט לכתוב את כל הסטייט בקומפוננטה או מקסימום בקונטקסט. במקרים שחייבים לבחור כמו בצד השרת אני בוחר במה שאני כבר מכיר יותר טוב. ואת הבלוג הראשון שלי פתחתי בפלטפורמה מנוהלת שנקראת blogger. המטרה היחידה היא להגיע למשהו באוויר. אחרי זה משפרים.

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

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

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

import { useRef } from "react";

export default function App() {
  const inputRef = useRef(null);
  const hasText = inputRef?.current?.value !== "";

  return (
    <div className="App">
      <h1>Write some text to enable the button</h1>
      <input type="text" ref={inputRef} />
      <button 
          disabled={!hasText}
      >Go</button>
      <p>hasText = {hasText}</p>
    </div>
  );
}

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