הפרדת חששות עם ווים של React

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

הפרדת ממשק המשתמש מההיגיון העסקי אינו ייחודי ל-React: הפרדת חששות היא עיקרון עיצובי שיש לו כבר קיים בשנות ה-70. לדוגמה, נהוג להפריד את הקוד הניגש למסד הנתונים מהלוגיקה העסקית ב-backend.

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

עם הצגת ה-React hooks, יש גישה חדשה לכך: שימוש ווים מותאמים אישית.

מדוע עלינו להפריד את ההיגיון מהרכיב?

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

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

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

ארגון הקוד שלך כך לא רק גורם לו להיראות טוב יותר וקל יותר לניווט, הוא גם מקל על השינוי מכיוון ששינוי ה-hook אינו משפיע על ממשק המשתמש ולהיפך.

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

כיצד לנתק את ההיגיון עם ווים של React

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

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

אתה יכול למצוא את קוד המקור המלא כאן.

הקוד נראה כך:

export const ExponentCalculator = () => {
  const [base, setBase] = useState(4);
  const [exponent, setExponent] = useState(4);
  const result = (base ** exponent).toFixed(2);

  const handleBaseChange = (e) => {
    e.preventDefault();
    setBase(e.target.value);
  };

  const handleExponentChange = (e) => {
    e.preventDefault();
    setExponent(e.target.value);
  };

  return (
    <div className="blue-wrapper">
      <input
        type="number"
        className="base"
        onChange={handleBaseChange}
        placeholder="Base"
        value={base}
      />
      <input
        type="number"
        className="exponent"
        onChange={handleExponentChange}
        placeholder="Exp."
        value={exponent}
      />
      <h1 className="result">{result}</h1>
    </div>
  );
};

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

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

const useExponentCalculator = () => {
  const [base, setBase] = useState(4);
  const [exponent, setExponent] = useState(4);
  const result = (base ** exponent).toFixed(2);

  const handleBaseChange = (e) => {
    e.preventDefault();
    setBase(e.target.value);
  };

  const handleExponentChange = (e) => {
    e.preventDefault();
    setExponent(e.target.value);
  };

  return {
    base,
    exponent,
    result,
    handleBaseChange,
    handleExponentChange,
  };
};

export const ExponentCalculator = () => {
  const {
    base,
    exponent,
    result,
    handleExponentChange,
    handleBaseChange,
  } = useExponentCalculator();

  // ...
};

נוכל להעביר את הקרס הזה ל-a קובץ נפרד להפרדה בולטת יותר של דאגות.

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

useExponentCalculator.js

const calculateExponent = (base, exponent) => base ** exponent;

const useExponentCalculator = () => {
  const [base, setBase] = useState(4);
  const [exponent, setExponent] = useState(4);
  const result = calculateExponent(base, exponent).toFixed(2);

  // ...
};

בדיקת הפונקציות הללו היא הרבה יותר קלה מאשר בדיקת כל הקוד של הרכיב מהדוגמה הראשונה. נוכל לבדוק אותם עם כל ספריית בדיקות של Node.js, שאפילו לא צריכה לתמוך ברכיבי React.

כעת יש לנו את הקוד הספציפי למסגרת (React) בקוד של הרכיב וה-hook, בעוד ההיגיון העסקי שלנו חי בפונקציות השונות שהגדרנו מאוחר יותר (שהן מסגרת-אגנוסטית).

שיטות עבודה מומלצות

שיום

אני אוהב לקרוא לווים המותאמים אישית שלי על שם הרכיב בתור שרשור של use ושם הרכיב (למשל useExponentCalculator). לאחר מכן אני מתקשר ל להגיש את אותו הדבר כמו הקרס.

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

אם אני יכול לעשות שימוש חוזר בחלקים של וו מותאם אישית, אני בדרך כלל מעביר אותו לקובץ אחר מתחת src/hooks.

אל תגזימו

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

CSS-in-JS

אם אתה משתמש בספריית CSS-in-JS (useStyles), ייתכן שתרצה להעביר את הקוד הזה גם לקובץ אחר.

אתה יכול להעביר אותו לאותו קובץ כמו הוו. עם זאת, אני מעדיף להשאיר אותו מעל הרכיב באותו קובץ או להעביר אותו לקובץ משלו אם הוא יגדל מדי.

סיכום

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

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

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