{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiauu5zx2xdntnhg6dop5fdos5ncwv2talhvnohou76nomiezxyshq",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3momgalwz6662"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiduaeun7225vjtdptzqzhw762lp7jbppxbqe7z7tcgivqk3enyy3a"
    },
    "mimeType": "image/webp",
    "size": 66610
  },
  "path": "/ramesh_s_a8f0867d239e927c/structuring-typescript-interfaces-type-aliases-enums-and-object-types-1gmb",
  "publishedAt": "2026-06-19T03:27:06.000Z",
  "site": "https://dev.to",
  "tags": [
    "beginners",
    "tutorial",
    "typescript",
    "webdev",
    "here"
  ],
  "textContent": "#  Structuring TypeScript: Interfaces, Type Aliases, Enums, and Object Types\n\n_You've learned TypeScript's primitive types and the basics of type inference here. Now it's time to model real-world data — users, orders, API responses, configuration objects. That's where interfaces, type aliases, and enums come in._\n\nThese three features are what make TypeScript genuinely powerful for building applications. Let's dig in.\n\n##  Object Types: Describing the Shape of Data\n\nBefore we get to interfaces, let's understand object types. When you want to describe the structure of an object, you define what properties it has and what types those properties are:\n\n\n\n    // Inline object type annotation\n    function displayUser(user: { name: string; age: number; email: string }): void {\n      console.log(`${user.name} (${user.age}) — ${user.email}`);\n    }\n\n\nThis works, but it's messy to repeat everywhere. That's why we use **type aliases** and **interfaces** to name and reuse these shapes.\n\n##  Type Aliases: Naming a Type\n\nA type alias gives a name to any type — primitives, unions, objects, or combinations:\n\n\n\n    // Alias for a primitive union\n    type ID = string | number;\n\n    // Alias for an object shape\n    type User = {\n      id: ID;\n      name: string;\n      age: number;\n      email: string;\n    };\n\n    // Now use it anywhere\n    const user: User = {\n      id: 1,\n      name: \"Ramesh\",\n      age: 31,\n      email: \"ramesh@example.com\",\n    };\n\n    function getUser(id: ID): User {\n      // ... fetch user logic\n    }\n\n\nType aliases are flexible — they can represent almost anything.\n\n##  Interfaces: Defining Object Contracts\n\nAn `interface` is specifically designed to describe the shape of an object. Syntax is slightly different:\n\n\n\n    interface User {\n      id: number;\n      name: string;\n      age: number;\n      email: string;\n    }\n\n    const user: User = {\n      id: 1,\n      name: \"Ramesh\",\n      age: 31,\n      email: \"ramesh@example.com\",\n    };\n\n\n###  Optional and Readonly Properties\n\nProperties can be marked as optional (`?`) or read-only (`readonly`):\n\n\n\n    interface UserProfile {\n      readonly id: number;      // Can't be changed after creation\n      name: string;\n      age?: number;             // Optional — may or may not be present\n      bio?: string;             // Optional\n    }\n\n    const profile: UserProfile = { id: 101, name: \"Ramesh\" };\n    profile.id = 999;           // ❌ Error: Cannot assign to 'id' (readonly)\n    profile.age = 31;           // ✅ Fine, optional doesn't mean immutable\n\n\n###  Extending Interfaces\n\nInterfaces support inheritance — you can build on existing ones:\n\n\n\n    interface Animal {\n      name: string;\n      sound(): string;\n    }\n\n    interface Dog extends Animal {\n      breed: string;\n      fetch(): void;\n    }\n\n    const myDog: Dog = {\n      name: \"Bruno\",\n      breed: \"Labrador\",\n      sound: () => \"Woof!\",\n      fetch: () => console.log(\"Fetching...\"),\n    };\n\n\nThis is great for modelling hierarchical data (e.g. `AdminUser extends User`).\n\n##  `interface` vs `type`: When to Use Which\n\nThis is one of TypeScript's most debated questions. Here's a practical answer:\n\nFeature | `interface` | `type`\n---|---|---\nObject shapes | ✅ | ✅\nPrimitives/unions | ❌ | ✅\nExtending/inheriting |  `extends` keyword | Intersection (`&`)\nDeclaration merging | ✅ | ❌\nUse with classes | ✅ Preferred | Works\n\n\n    // Extending with interface\n    interface Animal { name: string; }\n    interface Dog extends Animal { breed: string; }\n\n    // Extending with type (using intersection)\n    type Animal = { name: string; };\n    type Dog = Animal & { breed: string; };\n\n\n**The honest answer:**\n\n  * Use `interface` for objects that represent real-world entities (users, products, components)\n  * Use `type` for unions, intersections, utility combinations, and when you need to alias primitive types\n\n\n\nIn most modern TypeScript codebases, both work. Just be consistent within a project.\n\n##  Enums: Named Constants That Make Sense\n\nAn **enum** is a set of named constant values. Instead of using magic strings or numbers scattered across your code, you define them once:\n\n###  Numeric Enums\n\n\n    enum Direction {\n      Up,    // 0\n      Down,  // 1\n      Left,  // 2\n      Right, // 3\n    }\n\n    function move(dir: Direction): void {\n      console.log(`Moving in direction: ${dir}`);\n    }\n\n    move(Direction.Up);    // ✅ Clean, readable\n    move(0);               // ✅ Also works (but less clear)\n    move(\"Up\");            // ❌ Error\n\n\nValues auto-increment from 0. You can override the starting number:\n\n\n\n    enum StatusCode {\n      OK = 200,\n      NotFound = 404,\n      ServerError = 500,\n    }\n\n    console.log(StatusCode.OK); // 200\n\n\n###  String Enums (More Common in Practice)\n\n\n    enum OrderStatus {\n      Pending = \"PENDING\",\n      Processing = \"PROCESSING\",\n      Shipped = \"SHIPPED\",\n      Delivered = \"DELIVERED\",\n      Cancelled = \"CANCELLED\",\n    }\n\n    function updateOrderStatus(orderId: number, status: OrderStatus): void {\n      console.log(`Order ${orderId} is now: ${status}`);\n    }\n\n    updateOrderStatus(1001, OrderStatus.Shipped);\n    // Output: Order 1001 is now: SHIPPED\n\n\nString enums are preferred because the values are human-readable in logs, APIs, and debugging.\n\n###  When to Use Enums vs Union Types\n\n\n    // Union type approach\n    type OrderStatus = \"PENDING\" | \"SHIPPED\" | \"DELIVERED\";\n\n    // Enum approach\n    enum OrderStatus {\n      Pending = \"PENDING\",\n      Shipped = \"SHIPPED\",\n      Delivered = \"DELIVERED\",\n    }\n\n\nUse **union types** when the values are simple and stable. Use **enums** when you need a named, reusable group of constants — especially when the values are used across many files.\n\n##  Putting It All Together: A Real Example\n\nHere's how interfaces, type aliases, and enums work together in a realistic scenario:\n\n\n\n    // Enum for user roles\n    enum UserRole {\n      Admin = \"ADMIN\",\n      Editor = \"EDITOR\",\n      Viewer = \"VIEWER\",\n    }\n\n    // Base interface for all users\n    interface BaseUser {\n      readonly id: number;\n      name: string;\n      email: string;\n      createdAt: Date;\n    }\n\n    // Extended interface with role\n    interface AppUser extends BaseUser {\n      role: UserRole;\n      lastLogin?: Date;\n    }\n\n    // Type alias for API response shape\n    type ApiResponse<T> = {\n      success: boolean;\n      data: T;\n      error?: string;\n    };\n\n    // Function using all of the above\n    function createUser(name: string, email: string, role: UserRole): ApiResponse<AppUser> {\n      const newUser: AppUser = {\n        id: Math.random(),\n        name,\n        email,\n        role,\n        createdAt: new Date(),\n      };\n\n      return {\n        success: true,\n        data: newUser,\n      };\n    }\n\n    const result = createUser(\"Ramesh\", \"ramesh@example.com\", UserRole.Admin);\n    console.log(result.data.role); // \"ADMIN\"\n\n\nNotice how the types tell a clear story. You don't need to read the function implementation to understand what it takes and what it returns.\n\n##  Common Mistakes to Avoid\n\n**Mistake 1: Over-nesting object types**\n\n\n\n    // ❌ Hard to read and reuse\n    interface Order {\n      user: {\n        id: number;\n        address: {\n          street: string;\n          city: string;\n        };\n      };\n    }\n\n    // ✅ Break it out into named types\n    interface Address {\n      street: string;\n      city: string;\n    }\n\n    interface OrderUser {\n      id: number;\n      address: Address;\n    }\n\n    interface Order {\n      user: OrderUser;\n    }\n\n\n**Mistake 2: Numeric enums in APIs**\n\n\n\n    // ❌ Numeric enum values in API responses are confusing\n    enum Status { Active, Inactive } // 0, 1 in JSON — meaningless without context\n\n    // ✅ String enums are self-documenting\n    enum Status { Active = \"ACTIVE\", Inactive = \"INACTIVE\" }\n\n\n##  Summary\n\nHere's what to remember from this post:\n\n  * **Object types** describe the shape of an object inline\n  * **Type aliases** (`type`) name any type — great for unions, intersections, and flexibility\n  * **Interfaces** (`interface`) define object contracts — great for classes, extension, and real-world entities\n  * Use `readonly` for immutable properties, `?` for optional ones\n  * **Enums** group related constants — prefer string enums for readability\n  * Combine all three to model complex, real-world data clearly\n\n\n\n**You've completed the TypeScript Beginners Series.** You now understand the full foundation: types, inference, arrays, tuples, unions, interfaces, aliases, and enums. That's everything you need to start writing real TypeScript confidently.\n\nFound this helpful? Follow for the rest of the series. Questions or corrections? Drop them in the comments.",
  "title": "Structuring TypeScript: Interfaces, Type Aliases, Enums, and Object Types"
}