רינדור ב-React: מה גורם לרינדור מחדש ולמה

קומפוננטת React מתרנדרת מחדש כשה-state שלה משתנה, כשההורה שלה מתרנדר מחדש, או כשקונטקסט שהיא קוראת משתנה. רינדור פירושו ש-React קוראת שוב לפונקציית הקומפוננטה כדי לקבל JSX חדש; אחר כך היא מעדכנת רק את החלקים בדף שבאמת השתנו.

import { useState } from 'react';

function Title() {
    console.log('render Title');
    return <h3>Cart</h3>;
}

function Counter({ count }) {
    console.log('render Counter, count =', count);
    return <p>Items: {count}</p>;
}

export default function App() {
    const [count, setCount] = useState(0);
    console.log('render App');

    return (
        <div>
            <Title />
            <Counter count={count} />
            <button onClick={() => setCount(count + 1)}>Add item</button>
        </div>
    );
}

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

מה מפעיל רינדור

React מרנדרת קומפוננטה בדיוק מהסיבות האלה:

1. הרינדור הראשון. האפליקציה מתחילה, או שהקומפוננטה מופיעה בעץ בפעם הראשונה.
2. ה-state שלה השתנה. קראתם ל-setter מ-useState או ל-dispatch מ-useReducer עם ערך חדש.
3. ההורה שלה התרנדר. כברירת מחדל, כשקומפוננטה מתרנדרת, כל קומפוננטה שהיא מחזירה מתרנדרת גם היא, עד הסוף למטה.
4. קונטקסט שהיא קוראת השתנה. קומפוננטה שקוראת ל-useContext(SomeContext) מתרנדרת כשה-provider הקרוב מעביר value חדש (ראו useContext).

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

קביעת state לערך שכבר יש לו (בהשוואה עם Object.is) לא מתחילה רינדור של הילדים. React עשויה עדיין לקרוא לאותה קומפוננטה אחת פעם אחת לפני שהיא שמה לב ששום דבר לא השתנה, אבל היא זורקת את התוצאה.

render ו-commit

כל עדכון עובר שני שלבים:

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

הדוגמה שמתחת מתרנדרת בכל לחיצה, אבל React שומרת את אותו אלמנט <input>. אפקט רץ אחרי כל commit ובודק את זה.

import { useEffect, useRef, useState } from 'react';

export default function App() {
    const [ticks, setTicks] = useState(0);
    const inputRef = useRef(null);
    const firstInput = useRef(null);

    console.log('render', ticks);

    useEffect(() => {
        if (!firstInput.current) firstInput.current = inputRef.current;
        const same = inputRef.current === firstInput.current;
        console.log('after commit', ticks, 'same <input> node:', same);
    });

    return (
        <div>
            <input ref={inputRef} placeholder="Type here, then click" />
            <p>Rendered {ticks} extra times</p>
            <button onClick={() => setTicks(ticks + 1)}>Render again</button>
        </div>
    );
}

הקלידו משהו בשדה ולחצו כמה פעמים. הטקסט שהקלדתם נשאר, כי React אף פעם לא החליפה את השדה: השינוי היחיד ב-DOM בכל לחיצה הוא המספר בתוך ה-<p>. הלוג גם מראה את הסדר, קודם render ואחרי ה-commit האפקט.

ה-virtual DOM, בפשטות

"Virtual DOM" הוא השם הפופולרי לאובייקטים שהקומפוננטות שלכם מחזירות. <p>Items: {count}</p> מתקמפל לקריאה שיוצרת אובייקט כמו { type: 'p', props: { children: ['Items: ', 1] } }. אחרי רינדור, React עוברת על העץ החדש של האובייקטים האלה לצד הקודם, ובמקום שבו הטיפוס והמיקום תואמים היא שומרת את צומת ה-DOM הקיים ומעדכנת רק מאפיינים וטקסט שהשתנו. ההשוואה הזו נקראת reconciliation.

המונח רופף משתי סיבות. React לא מחזיקה עותק שני של ה-DOM ולא משווה שני DOMs: היא משווה אובייקטי אלמנטים מול העץ הפנימי שלה של קומפוננטות (עץ ה-fiber). ואותו תהליך מניע יעדים שאין להם DOM בכלל, כמו React Native. התיעוד של React ברובו נמנע מהביטוי ומדבר על render ו-commit במקום. מה שחשוב בפועל הוא התוצאה: רינדור זול לעומת עבודה עם ה-DOM, כי רוב הרינדורים מסתיימים בעדכון DOM קטן או בכלום.

שני כללים נובעים מהאופן שבו ההשוואה עובדת. טיפוס אלמנט אחר באותו מקום (<div> שמוחלף ב-<section>, או ComponentA ב-ComponentB) הורס את תת העץ הישן ואת ה-state שלו. וברשימות, key אומר ל-React איזה פריט הוא איזה, כדי שתוכל להזיז צמתים במקום לבנות אותם מחדש.

לעצור רינדורים שלא צריך

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

הורידו את ה-state למטה

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

export default function App() {
    const [text, setText] = useState('');
    return (
        <>
            <input value={text} onChange={(e) => setText(e.target.value)} />
            <ProductList />
        </>
    );
}

העבירו את השדה ואת ה-state שלו לקומפוננטה משלהם, והרשימה כבר לא נמצאת בתוך הקומפוננטה שמתרנדרת:

import { useState } from 'react';

function SearchBox() {
    const [text, setText] = useState('');
    console.log('render SearchBox', JSON.stringify(text));
    return (
        <input
            value={text}
            onChange={(e) => setText(e.target.value)}
            placeholder="Type something"
        />
    );
}

function ProductList() {
    console.log('render ProductList');
    return (
        <ul>
            <li>Keyboard</li>
            <li>Mouse</li>
            <li>Monitor</li>
        </ul>
    );
}

export default function App() {
    return (
        <div>
            <SearchBox />
            <ProductList />
        </div>
    );
}

הקלידו כמה אותיות: רק SearchBox רושמת.

העבירו children במקום

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

import { useState } from 'react';

function Highlighter({ children }) {
    const [on, setOn] = useState(false);
    console.log('render Highlighter');
    return (
        <div style={{ background: on ? '#fff3b0' : 'transparent', padding: 8 }}>
            <button onClick={() => setOn(!on)}>Toggle highlight</button>
            {children}
        </div>
    );
}

function Article() {
    console.log('render Article');
    return <p>A long article that is costly to render.</p>;
}

export default function App() {
    console.log('render App');
    return (
        <Highlighter>
            <Article />
        </Highlighter>
    );
}

לחצו על ההחלפה ורק Highlighter רושמת. עכשיו העבירו את <Article /> לתוך ה-JSX של Highlighter במקום {children}, וכל לחיצה רושמת גם render Article.

memoization

כששום ארגון מחדש לא מתאים, עטפו את הילד ב-memo. React משווה אז את ה-props שלו לקודמים ומדלגת על הרינדור כשכולם זהים. אובייקטים ופונקציות שנוצרים בזמן הרינדור הם חדשים בכל פעם, ולכן memo מגיע בדרך כלל עם useMemo או useCallback בשביל ה-props האלה. הדף על React.memo מראה את זה עם דוגמאות שרצות.

import { memo } from 'react';

const ProductList = memo(function ProductList({ category }) {
    // skipped while category stays the same
});

React Compiler יכול להוסיף memoization כזה בשבילכם בזמן ה-build, אבל ארגון מחדש של ה-state הוא עדיין הדבר הראשון לנסות: הוא מבטל את העבודה במקום לשמור אותה ב-cache.

רינדורים הם בדרך כלל בסדר

רינדור הוא קריאה לפונקציה שמחזירה אובייקטים. React מריצה אלפים מהם מהר, ורינדור שמייצר את אותו פלט לא משנה שום DOM. אל תוסיפו memo בכל מקום "ליתר ביטחון": לכל השוואה יש עלות משלה והיא הופכת את הקוד לקשה יותר לקריאה. מדדו קודם. ה-Profiler של React DevTools מראה אילו קומפוננטות התרנדרו, למה, וכמה זמן לקח כל אחת.