Generics are an incredibly useful feature in TypeScript that let you build components with APIs that are both reusable and safe. Think of them as a way to create functions, classes, or Svelte components that work with various types instead of being locked into one. This means your components can adapt to different types without losing their type-checking powers—pretty handy when you're dealing with collections of data or custom callbacks.

In this article, we'll dive into how you can use generics in Svelte 5 to create reusable components that feel like a dream to use. We’ll also sprinkle in snippets—a feature that complements generics by giving you more control over how things are displayed. By the end, you’ll have a better idea of how these tools make your code cleaner, easier to maintain, and a joy to work with.

Generics and snippets are perfect for developers who want to make their components more versatile without sacrificing readability or safety. As your projects grow, these tools can help you avoid duplicating code while maintaining a clear structure in your codebase. Let’s start by understanding the basics of generics and how they fit into Svelte development.

Getting Started with Generics

Generics are like placeholders for types that get replaced when the function or component is used. Here’s a quick example to get the idea across:

function getFirst<T>(arr: T[]): T {
  return arr[0];
}

const firstNumber = getFirst([1, 2, 3]); // TypeScript figures out T is a number
const firstString = getFirst(['Alice', 'Bob']); // Here, T becomes a string

Notice how the type of T is inferred based on the array you pass in? This keeps things both flexible and safe. You can apply the same concept to Svelte components to make them adaptable to whatever data they need to handle.

Generics are especially handy for scenarios where you’re building utility functions or components that work with multiple data types. They allow you to avoid repetitive code while maintaining strong type guarantees. Let’s see how this concept applies to Svelte components, where generics can bring additional flexibility to UI development.

Generics in Svelte Components

In Svelte 5, generics are easy to use with the generics attribute in your <script> tag. Let’s take a look at a simple List component that can display any type of item:

<script lang="ts" generics="T">
  let { items }: { items: T[] } = $props();
</script>

<ul>
  {#each items as item}
    <li>{item}</li>
  {/each}
</ul>

Here, the items prop is flexible and adapts to whatever type the parent component specifies. This makes the List component incredibly reusable. You don’t need to write separate components for numbers, strings, or objects—just let the parent decide.

The real beauty of this approach is that it scales effortlessly. Whether you’re displaying a list of strings, numbers, or complex objects, the component remains the same. Plus, you get the added bonus of TypeScript’s type-checking to catch potential bugs during development.

Example 1: Displaying Strings

<script lang="ts">
  import List from './List.svelte';

  let names = ['Alice', 'Bob', 'Charlie'];
</script>

<List items={names} />

Example 2: Displaying Numbers

<script lang="ts">
  import List from './List.svelte';

  let numbers = [1, 2, 3, 4];
</script>

<List items={numbers} />

Generics make this process seamless. You get type safety and flexibility without writing repetitive code. Plus, TypeScript gives you immediate feedback if something doesn’t line up, which means fewer bugs and more confidence in your code.

Another advantage of using generics is that they make your components future-proof. As your application evolves, you can easily adapt these components to handle new data types without rewriting them. This saves time and ensures consistency across your project.

Making Components Interactive with Callbacks

Generics show their true power when paired with callbacks. Using them alone provides type safety, but the real value comes when your components start interacting with data. Here’s an example of a List component that lets you handle item clicks:

<script lang="ts" generics="T">
  let { items, onSelect }: { items: T[]; onSelect: (item: T) => void } = $props();
</script>

<ul>
  {#each items as item}
    <li onclick={() => onSelect(item)}>{item}</li>
  {/each}
</ul>

With this setup, the parent component controls what happens when an item is clicked, and TypeScript ensures that the onSelect function gets the right type of item.

Example 3: Handling User Objects

<script lang="ts">
  import List from './List.svelte';

  type User = { id: number; name: string };
  let users: User[] = [
    { id: 1, name: 'Alice' },
    { id: 2, name: 'Bob' }
  ];

  function handleSelect(user: User) {
    console.log('Selected user:', user.name);
  }
</script>

<List items={users} onSelect={handleSelect} />

This approach keeps things clean and ensures that your interactions are consistent with the data type you’re working with. Whether it’s a User object or something else entirely, TypeScript has your back.

Interactive components like this are invaluable for building dynamic interfaces. You can use the same pattern for forms, dashboards, or e-commerce applications where user interaction is key.

Adding Flexibility with Snippets

Generics are great for handling data, but what if you want to customize how each item looks? That’s where snippets come in. They let you define how items should be rendered, giving the parent component full control over presentation.

Snippets are like templates that you can pass to a child component. They make it easy to tailor the appearance of your data without modifying the component itself. This is especially useful when working with complex UIs that need to display the same data in different ways.

Updating the List Component

<script lang="ts" generics="T">
  import { Snippet } from 'svelte';

  type ListProps<T> = {
    items: T[];
    itemTemplate?: Snippet<[T]>;
  };

  let { items, itemTemplate }: ListProps<T> = $props();
</script>

<ul>
  {#each items as item}
    <li>
      {#if itemTemplate}
        {@render itemTemplate(item)}
      {:else}
        {item}
      {/if}
    </li>
  {/each}
</ul>

Example 4: Customizing the Display

<script lang="ts">
  import List from './List.svelte';

  type User = { id: number; name: string };
  let users: User[] = [
    { id: 1, name: 'Alice' },
    { id: 2, name: 'Bob' }
  ];
</script>

<List items={users}>
  {#snippet itemTemplate(user: User)}
    <strong>{user.name}</strong> (ID: {user.id})
  {/snippet}
</List>

This gives you the best of both worlds: reusable components and fully customizable rendering. It’s especially useful when you’re working on complex applications where different contexts might need different visual treatments.

Wrapping It Up

Generics and snippets in Svelte 5 are a game-changer for building flexible, type-safe components. Generics let your components adapt to different types of data while maintaining strict type checking. Snippets, on the other hand, let you customize how your components look without sacrificing reusability.

Whether you’re building a simple list or a complex UI, these tools make your job easier and your code cleaner. Start using generics and snippets today, and see how they can transform your workflow!

These techniques aren’t just for advanced users. Even if you’re new to Svelte or TypeScript, mastering generics and snippets can greatly enhance your productivity. So why wait? Dive in and make your components smarter, more adaptable, and more fun to work with!

Cover photo by: Online illustrations by Storyset

In this article, I’ll walk you through my approach to structuring components by prioritizing ontological meaning—what a component represents in your application—its purpose or role—rather than how it looks, and how this can help avoid common pitfalls when building complex UIs.

Ontological meaning refers to the purpose or concept a component represents within your application. While components may look similar, their meaning—or ontology—can be different. For example, a TaskCard and ProjectCard might both display a title and a progress bar, but they represent two very different concepts.

The Naive Approach: One Generic Component for Everything

When you're building a front-end application, you’ll often come across components that look similar at first glance. Imagine a Project Card and a Task Card. Both cards might show a title, a description, and a progress bar, but they represent fundamentally different concepts: a project and a task.

A naive approach might suggest: “These two cards look the same, so let’s just create one generic component that can handle both!”

You could end up with something like this:

// Generic InfoCard component
const InfoCard = ({ title, description, progress }) => (
  <div className="info-card">
    <h2>{title}</h2>
    <p>{description}</p>
    <div className="progress-bar" style={{ width: `${progress}%` }} />
  </div>
);

Instead of creating separate components for ProjectCard and TaskCard, you would simply pass different data into this single generic InfoCard component:

// Using InfoCard for a Project
<InfoCard title="Website Redesign" description="Redesigning the homepage with a new layout" progress={40} />

// Using InfoCard for a Task
<InfoCard title="Create Wireframe" description="Design the initial wireframe for the homepage layout" progress={60} />

At first glance, this might seem like a time-saving strategy. After all, both components share the same structure, so why not create a single generic component? However, this desire for efficiency can introduce long-term challenges.

The Problems with a Single Generic Component

1. Loss of Semantic Meaning: By using the same InfoCard for both projects and tasks, you start to lose the ontological meaning of these components. Is this component about a project or a task? Over time, it’s easy to forget the distinction. While the InfoCard looks the same, it represents two different things.

2. Lack of Flexibility: What happens when one of these cards needs to change? Let’s say you need to add task assignees or due dates to the TaskCard. Now, you have to modify the InfoCard to accommodate these new features. The problem is, this generic component might also be used for projects, which don’t need the same updates. You end up adding conditional logic and props to handle edge cases, cluttering your shared component with unnecessary complexity.

3. Harder to Maintain: As the generic InfoCard becomes more complex, it becomes harder to maintain. You might start introducing props like isProject or isTask, which increase the mental load for anyone maintaining the component making it harder to understand and debug. Over time, this kind of complexity leads to "prop bloat," where the component accepts more and more parameters to handle different scenarios.

A Better Approach: Semantic Components with Shared Structure

Instead of trying to force unrelated concepts into a single generic component, it's better to think of components as semantically different but structurally similar. This means you should create separate components for ProjectCard and TaskCard even if they share the same layout at the start. You can still share the structure (like the card layout) between them, but by keeping their identity distinct, you give yourself much more flexibility for the future.

Here’s how it could look:

const InfoCard = ({ title, description, progress }) => (
  <div className="info-card">
    <h2>{title}</h2>
    <p>{description}</p>
    <div className="progress-bar" style={{ width: `${progress}%` }} />
  </div>
);

// ProjectCard.js - Semantically distinct component
const ProjectCard = ({ projectName, projectDescription, projectProgress }) => (
  <InfoCard title={projectName} description={projectDescription} progress={projectProgress} />
);

// TaskCard.js - Semantically distinct component
const TaskCard = ({ taskName, taskDescription, taskProgress }) => (
  <InfoCard title={taskName} description={taskDescription} progress={taskProgress} />
);

At first glance, this might look like unnecessary boilerplate since both ProjectCard and TaskCard are essentially just wrapping the same InfoCard. But this boilerplate is intentional and provides several key benefits.

Why Boilerplate Isn’t Always Bad

1. Clarity: By having distinct ProjectCard and TaskCard components, you maintain a clear separation of meaning. If someone new joins your team, they will immediately understand that ProjectCard deals with a project and TaskCard deals with a task, even if they share the same structure. This makes your code easier to understand and maintain over time.

2. Flexibility: As your application evolves, ProjectCard and TaskCard can evolve independently to meet new requirements. For example, let's say you want to add additional information to the ProjectCard, such as project deadlines or milestones. Instead of modifying a shared component like InfoCard, you can extend or replace the entire structure of the ProjectCard while keeping the TaskCard untouched.

For instance, if you want to add more detailed project information to the ProjectCard, you can simply replace InfoCard with a more complex component:

const ProjectCard = ({ projectName, projectDescription, projectProgress, projectDeadline }) => (
  <div>
    <ExtendedProjectInfoCard 
      title={projectName} 
      description={projectDescription} 
      progress={projectProgress} 
      deadline={projectDeadline} 
    />
  </div>
);

3. Maintainability: It makes your code easier to maintain in the long run by keeping components focused and modular. When you need to make changes, you know exactly where to look, and you can be confident that updates to one component won’t inadvertently affect another. You avoid unecessary conditional logic and props that clutter your shared components.

Balancing Reusability and Flexibility

The key here is to reuse what makes sense but not force reuse at the expense of clarity or flexibility. Reusing the shared structure (like InfoCard) helps maintain consistency and reduces duplication, but by keeping ProjectCard and TaskCard semantically distinct, you allow each component to evolve independently. This leads to a cleaner codebase, more scalable components, and less brittle logic.

Conclusion: Prioritize Semantic Meaning

When designing components, focusing on semantic differences while reusing common structure is an excellent strategy to strike the right balance between reusability and flexibility. While it might seem like extra work upfront to create separate components like ProjectCard and TaskCard, this approach pays off in the long term by making your codebase easier to maintain, more understandable, and more adaptable as the application grows.

Next time you’re tempted to create a single generic component for similar-looking elements, remember: a little intentional boilerplate can save you from a lot of complexity and headaches down the road.

Key Takeaways:

• Reuse Structure, Not Meaning: While components may share a layout, wrap them in distinct components (ProjectCard, TaskCard) to preserve their unique semantic purpose.

• Leverage Generic Components Thoughtfully: It’s fine to use generic components like InfoCard, but ensure they’re wrapped in more meaningful components that reflect the domain concepts.

• Maintain Clarity with Wrappers: Adding wrappers around shared components keeps your codebase clearer and more flexible. A ProjectCard can evolve independently from a TaskCard, even if they share structure initially.

• Boilerplate for Semantic Clarity: Writing a little extra wrapper code up front might seem redundant, but it ensures your components remain clear and adaptable as the application scales.

• Avoid Overcomplicating Generic Components: Instead of adding complex props to handle different scenarios within a generic component, wrap the generic structure in components that handle those differences separately.