רכיבי פונקציה מול `React.FC` ב-TypeScript: דיון אזרחי

React ו-TypeScript נכנסים לפרויקט יחד. TypeScript אומר, "אני אטפל בטיפוסים." React אומר, "אני אטפל ברינדור." ובדרך מישהו שואל:

האם להשתמש ב-React.FC, או פשוט להגדיר את הפונקציה ישירות?

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

בואו נבדוק מקרוב.

שני הסגנונות

רכיב פונקציה פשוט

type Props = { title: string };

function MyComponent({ title }: Props) {
  return <h1>{title}</h1>;
}

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

או, אם אתם מעדיפים פונקציות חיצים:

const MyComponent = ({ title }: Props) => {
  return <h1>{title}</h1>;
};

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

גרסת React.FC

import { FC } from 'react';

type Props = { title: string };

const MyComponent: FC<Props> = ({ title }) => {
  return <h1>{title}</h1>;
};

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

מה React.FC עושה בפועל

React.FC (קיצור של React.FunctionComponent) הוא טיפוס עזר שמתאר רכיב פונקציה. הוא מציע כמה התנהגויות ברירת מחדל:

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

אלה נוחות צנועות, ובימים הראשונים של React + TypeScript הן היו שימושיות יותר. אבל הזמנים השתנו, ו-"הפיצ'רים" האלה לעיתים מפריעים יותר ממה שהם עוזרים.

למה זה יוצא מהאופנה

אפשר לומר ש-React.FC הוא כמו מכנסיים עם כיסים רבים ב-TypeScript—הרבה כיסים, ורובם לא בשימוש.

children מלכתחילה

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

בעייתי עם גנריקים

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

רב פעמיות בלי בהירות

כתיבת const MyComponent: FC<Props> ארוכה ויכולה להיות יותר מעורפלת מאשר פשוט להגדיר את הפרופס ישירות.

כבר לא הכרחי

הסיבות המקוריות לשימוש ב-React.FC—תמיכה בעורך, ניבוי JSX—טופלו במרבית השיפורים ב-TypeScript. מה שהיה בעבר פתרון פרקטי הפך היום לסגנון מיושן.

השוואה צמודה

תכונה	function Component()	const Component: FC
כולל children?	רק אם מצהירים	תמיד כלול
תומך בגנריקים?	בחן ומתוחכם	לא בקלות
מידת הפורמליות?	מינימלית	ארוכה ושוררת יותר
תמיכה בעורך?	מספקת	מעט טובה יותר במקרים מסוימים
מומלץ?	כן	לא יותר

הגישה המומלצת

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

type Props = {
  title: string;
  children?: React.ReactNode;
};

const MyComponent = ({ title, children }: Props) => (
  <div>
    <h1>{title}</h1>
    {children}
  </div>
);

זה מפורש. זה ניתן לתחזוקה. וזה לא מתיימר שהרכיב שלך מטפל ב-children אם לא.

האם יש מצבים שבהם FC עדיין הגיוני?

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

אבל בדרך כלל, אלה החריגים שמאשרים את הכלל.

לסיכום

React.FC לא טועה. פשוט כבר לא הכרחי. TypeScript המודרני הפשט את הטיפוס של רכיבי React והפך אותו ליותר צפוי ופשוט בלעדיו.

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

בתכנות—כמו בחיים—בהירות גוברת על תחכום. ופחות הפתעות משמעותן בדרך כלל פחות חרטות.

רכיבי פונקציה מול React.FC ב-TypeScript: דיון אזרחי