Better understanding component driven development

[brendan-morin]

Summary

Hi! I'm coming from data background where I've traditionally focused on TDD in languages such as python. I'm now building a frontend with sveltekit and trying to understand how to leverage storybook for CDD effectively. At a high level it makes sense to me, but I think there are a lot of micro-decisions I'm unsure about the implications of, in particular to general design patterns and interfaces. This may not be an entirely storybook focused discussion, but I'd appreciate any advice.

I'm going to borrow some code from shadcn-svelte for this example. Let's say I have a component like this:

<script lang="ts">
	import * as Avatar from '$lib/components/ui/avatar/index.js';
	import type { User } from '$lib/types/api';

	let {
    user }: { user: User } = $props();
</script>

<Avatar.Root class="size-8 rounded-lg">
  <Avatar.Image src={user.profile_photo} alt={user.name} />
  <Avatar.Fallback class="rounded-lg">{user.name[0]}</Avatar.Fallback>
</Avatar.Root>
<div class="grid flex-1 text-left text-sm leading-tight">
  <span class="truncate font-semibold">{user.name}</span>
  <span class="truncate text-xs">{user.email}</span>
</div>

In this example, I am recycling my user type User from my OpenAPI schema generated by my backend. On some level that feels nice because I don't have to define a second type. However, this type contains a lot of items that are not relevant to this component, when it comes to loading this into storybook, I see a lot of noise. Let's assume this type:

type User = {
    profile_photo: string | null | undefined;
    is_active: boolean | undefined;
    is_staff: boolean | undefined;
    is_superuser: boolean | undefined;
    last_login: string | null | undefined;
    name: string;
    id: number;
    created: string;
    modified: string;
    email: string;
    profile_photo_url: string;
}

We can see we have a lot of info that's just not used. And when viewing this in storybook with this setup:

<script context="module" lang="ts">
	import { defineMeta } from '@storybook/addon-svelte-csf';

	import UserInfo from '$lib/components/sidebar/user-info.svelte';

	/**
	 * Display user avatar and information.
	 */
	const { Story } = defineMeta({
		component: UserInfo,
		tags: ['autodocs'],
		parameters: {
			layout: 'centered'
		},
		args: {

		}
	});
</script>

<!--
 Default user info.
 -->
 <Story name="Default" />

I see my user type looks quite noisy, and suddenly this component feels more complex and opaque than it really is.

So then I'm left with the question: is this the right approach here? It seems my choices would either be:

1. Leave user type as it is, handle constructing a User argument via hardcoding or maybe custom controls.
2. Use a simpler interface that omits these unnecessary fields (not sure how to reconcile this with the original User, ideally they are in sync).
3. Don't use the User interface at all, just expose the required fields as top level props (e.g. name, email, profile_photo). Maybe do something higher up to destructure the User object at the time this component is created. This feels verbose but also is the most explicit interface. This approach is also probably what I would do in e.g. TDD/Python because it's easier to dependency inject primitive values as needed than create potentially complex mock objects.
4. Something else? Perhaps there is a storybook configuration option to help with making this more clear.

It's possible the answer here for experienced frontend devs is pretty clear, so if so I'd be interested in hearing it. Ultimately I'm interested in the driven aspect of component driven development. I don't just want to use storybook as a tool, I want to better understand the paradigm behind this approach that helps guide these sort of decisions.

Additional information

No response

Create a reproduction

No response

[dosubot[bot]]

Component-driven development (CDD) is about building UIs from small, focused components upward, developing and testing each in isolation. Storybook is designed for this: it lets you work on components in specific states without spinning up your whole app, and encourages a bottom-up workflow where you start with basic components and compose them into more complex ones "Storybook is an interactive directory of your UI components and their stories".

For your specific dilemma—whether to use a full backend-derived User type, a simplified interface, or destructured props—here’s how experienced frontend devs typically approach it:

• Explicit, minimal interfaces are preferred for leaf components. If your component only needs name, email, and profile_photo, define its props as just those fields. This keeps the component API clear, easy to test, and avoids leaking backend concerns into your UI layer. It also makes Storybook controls and docs much less noisy.
• If you want to keep things DRY and in sync with backend types, you can use TypeScript’s utility types: Pick<User, "name" | "email" | "profile_photo"> defines a minimal interface based on your backend type, so you don’t duplicate field definitions.
• Passing the whole User object is sometimes fine for higher-level components or containers, but for reusable UI components, it’s best to keep the interface as small as possible.

Storybook controls: By default, Storybook will try to generate controls for every field in your prop types, which can get noisy with complex objects. You can customize this using the parameters.docs.controls.exclude option to hide irrelevant fields from the controls panel. For example, in your Storybook config or at the story/meta level:

export default {
  component: UserInfo,
  parameters: {
    docs: {
      controls: { exclude: ['is_active', 'is_staff', 'is_superuser', 'last_login', 'id', 'created', 'modified', 'profile_photo_url'] }
    }
  }
};

This will hide those fields from the controls UI, making your stories much clearer "Storybook allows customization of the Controls panel by using parameters to exclude specific props".

Summary:

• Prefer explicit, minimal props for leaf components.
• Use TypeScript’s Pick to stay in sync with backend types without exposing unnecessary fields.
• Use Storybook’s controls.exclude to reduce noise in the docs/controls panel.
• Reserve passing full backend types for higher-level components or data containers.

This approach keeps your components focused, your stories readable, and your codebase maintainable as your app grows.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}