TypeScript Interface vs Type: ההבדלים ומתי להשתמש בכל אחד

לתיאור מבנה של אובייקט, interface ו-type עושים את אותה עבודה, וערכים של אחד ניתנים להשמה לשני כשהמבנים מתאימים. ההבדלים נמצאים בשוליים: type יכול לתת שם לדברים ש-interface לא יכול (unions, tuples, טיפוסים מחושבים), ו-interface יכול לעשות כמה דברים ש-type alias לא יכול (מיזוג, extends שנבדק).

interface PointI {
  x: number;
  y: number;
}

type PointT = {
  x: number;
  y: number;
};

const a: PointI = { x: 1, y: 2 };
const b: PointT = a; // same shape, so they are interchangeable
const c: PointI = b;

function show(p: PointI): string {
  return `(${p.x}, ${p.y})`;
}

console.log(show(b), show(c)); // (1, 2) (1, 2)

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

טבלת השוואה

מה רק type יכול לעשות

כל דבר שאינו מבנה אובייקט יחיד צריך type alias:

type Status = "idle" | "loading" | "done";                   // union of literals
type Coordinates = [lat: number, lng: number];               // tuple
type Handler = (event: string) => void;                      // function type
type ID = string | number;                                   // union of primitives
type Flags<T> = { [K in keyof T]: boolean };                 // mapped type
type ElementOf<T> = T extends readonly (infer U)[] ? U : T;  // conditional type

const current: Status = "loading";
const here: Coordinates = [51.5, -0.12];
const onSave: Handler = (e) => console.log("saved:", e);
const flags: Flags<{ dark: string; beta: number }> = { dark: true, beta: false };
const first: ElementOf<string[]> = "a";

onSave(current);
console.log(here, flags, first);
// saved: loading
// [ 51.5, -0.12 ] { dark: true, beta: false } a

אף אחד מאלה לא ניתן לכתיבה עם interface (שני האחרונים מוסברים בעמודים על mapped types ועל conditional types). זו הסיבה המעשית שכל בסיס קוד משתמש בסוף ב-type איפשהו, לא משנה במה הוא משתמש למבנים של אובייקטים.

מה רק interface יכול לעשות: declaration merging

שתי הצהרות interface עם אותו שם באותו scope מתאחדות לאחת. שתי הצהרות type עם אותו שם הן השגיאה TS2300, Duplicate identifier.

interface Settings {
  theme: string;
}
interface Settings {
  fontSize: number;
}
const s: Settings = { theme: "dark", fontSize: 14 }; // needs both

type Options = { a: number };
type Options = { b: number }; // error TS2300: Duplicate identifier 'Options'.

מיזוג הוא הדרך שבה מרחיבים טיפוסים של ספריות מבחוץ: הוספת מאפיין ל-Window הגלובלי, ל-Request של Express, או לטיפוס ה-theme של ספרייה. אם אתם מפרסמים טיפוסים שמשתמשים עשויים להצטרך להרחיב, השתמשו ב-interfaces. בקוד של האפליקציה שלכם, מיזוג בטעות (שני קובצי script שמצהירים על אותו שם של interface גלובלי) קורה בשקט, אלא אם שניהם מצהירים על אותו מאפיין עם טיפוסים שונים, וזה אחד הנימוקים שחלק מהצוותים נותנים להעדפת type.

extends מול intersection

interface מתרחב עם extends, ו-type alias עם &. ברוב המקרים הם מייצרים את אותה תוצאה, אבל הם מטפלים אחרת במאפיין מתנגש. extends מדווח על ההתנגשות כבר בהצהרה:

// This does not compile: id cannot change from string to number
interface Base {
  id: string;
  name: string;
}

interface Broken extends Base {
  id: number;
}

const x: Broken = { id: 1, name: "a" };
console.log(x);

index.ts(7,11): error TS2430: Interface 'Broken' incorrectly extends interface 'Base'.
  Types of property 'id' are incompatible.
    Type 'number' is not assignable to type 'string'.

intersection מקבל את אותה התנגשות בשקט והופך את המאפיין ל-never (string שהוא גם number). השגיאה מופיעה רק מאוחר יותר, כשמנסים ליצור ערך:

type Base = { id: string; name: string };
type Broken = Base & { id: number }; // no error here

// id is string & number, which is never: no object can satisfy Broken
// @ts-expect-error: Type 'number' is not assignable to type 'never'.
const x: Broken = { id: 1, name: "a" };

console.log("the alias compiled; only using it failed");

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

Index signatures: הבדל שקל לפספס

type alias של טיפוס אובייקט מקבל index signature מרומזת, ולכן אפשר להעביר אותו במקום שבו מצופה Record<string, unknown>. interface לא מקבל. זה בכוונה: ההסבר של צוות TypeScript (issue #15300 במאגר של TypeScript) הוא שאפשר להרחיב interface בהצהרות מאוחרות יותר, ולכן הסקה של index signature עבורו פחות בטוחה, ושינוי הכלל עכשיו היה שובר יותר מדי קוד.

interface UserI { name: string; age: number }
type UserT = { name: string; age: number };

function logFields(fields: Record<string, unknown>) {
  for (const [key, value] of Object.entries(fields)) {
    console.log(`${key}=${String(value)}`);
  }
}

const t: UserT = { name: "Ada", age: 36 };
const i: UserI = { name: "Alan", age: 41 };

logFields(t); // fine

// @ts-expect-error: Index signature for type 'string' is missing in type 'UserI'.
logFields(i);

logFields({ ...i }); // a spread copy is a fresh object type, so it is accepted

הקריאה שמסומנת ב-@ts-expect-error עדיין רצה ומדפיסה את השדות של Alan: הכלל הוא כלל של זמן קומפילציה. זו הסיבה הרגילה לשגיאה מבלבלת כשמעבירים ערך של interface לפונקציית עזר ללוגים, לסריאליזציה או לשאילתות שהטיפוס שלה הוא Record<string, ...>. החליפו את ההצהרה הזו ל-type, עשו spread לערך, או תנו לפרמטר של פונקציית העזר טיפוס של interface או גנרי.

ביצועים והודעות שגיאה

עמוד הביצועים בוויקי של TypeScript (הסעיף "Preferring Interfaces Over Intersections") ממליץ על interface Foo extends Bar, Baz { ... } במקום type Foo = Bar & Baz & { ... } בהרכבה של טיפוסי אובייקט. הנימוקים שלו: interface הוא טיפוס אובייקט שטוח יחיד שמזהה התנגשויות בין מאפיינים, יחסי טיפוסים בין interfaces נשמרים במטמון (intersections בשלמותם לא), ובדיקה של ערך מול intersection בודקת כל רכיב לפני הטיפוס המשוטח. ההבדל חשוב בבסיסי קוד גדולים עם הרבה טיפוסים מורכבים; בכמה מבנים רגילים של אובייקטים לא תוכלו למדוד אותו.

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

במה להשתמש

כלל שעובד:

1. מבנים של אובייקטים: interface. הוא נותן extends שנבדק, שגיאות ברורות יותר בהרכבות גדולות, ומאפשר למשתמשי ספריות להרחיב אותו. זה תואם לכלל האצבע של ה-handbook של TypeScript: "השתמשו ב-interface עד שתצטרכו תכונות של type".
2. כל השאר: type. Unions, tuples, טיפוסי פונקציות, טיפוסי ליטרל, וכל מה שנבנה עם mapped types, conditional types או template literal types.
3. חריג: השתמשו ב-type למבנה אובייקט שצריך להתאים לפרמטרים של Record<string, ...>, או כשאתם רוצים בכוונה למנוע מיזוג.

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