Component driven development VS colocation

[Fawwaz-2009]

Summary

Hey all 👋 I'm trying to find experts in components driven development and pick their brain on some doubts I'm having.

A big trend in the industry that I'm very thankful for is co-location, including co-location of APIs for both query and actions. This is great because it creates self-isolated components that compose Incredibly well.

However, from my research about component driven development, it seems to handle external dependency or frameworks dependencies, you end up with two options.

Option one, make all storybook components basically presentational and their contract specified in their in their props. However, this breaks the idea of co-location APIs and actions. You can see the below example of a storybook component I created during my exploration and honestly feels wrong and I feel I'm going back in time to a period I didin't like

<AddExpenseUI ollamaHealth={{ isLoading: ollamaHealth.isLoading, data: ollamaHealth.data }} users={usersQuery.data ?? []} selectedUserId={selectedUserId} stage={stage} previewUrl={previewUrl} extractedData={extractedData} timing={timing} error={error} savedData={savedData} onUserChange={setSelectedUserId} onFileSelect={handleFileSelect} onReset={handleReset} onSave={handleSave} onGoHome={handleGoHome} onAddAnother={handleAddAnother} isSaving={completeExpense.isPending} />

The second option is around mocking APIs. But I'm not sure how painful would that option be because it's not clear to me if this is going to be an initial setup cost and afterwards the cost will be low or if this is going to be an ongoing large cost to sync the mocked APIs with the actual APIs that they're using and TRPC quirks, etcetera.

What do you all think and would be grateful for any insight that you can add?

Additional information

No response

Create a reproduction

No response

[dosubot[bot]]

Hi @Fawwaz-2009! I'm Dosu and I’m helping the storybook team.

Great question—this is a common tension in modern frontend architecture. Here’s what’s working well for teams using Storybook with component-driven development and colocation:

• You don’t have to make all components purely presentational. Storybook supports colocating API logic and UI by mocking APIs/services at the component or page level. This keeps components self-contained and composable, while still testable in isolation. Storybook recommends mocking services in stories or using higher-level connected components to compose data from child stories’ args (example).

• For API mocking, Storybook now offers a global mocking API (sb.mock in .storybook/preview.ts) that lets you mock modules or services globally. These mocks are automatically reset before each story, so you don’t have to manually sync or reset them between stories. This reduces ongoing maintenance and helps keep mocks in sync with real APIs (discussion).

• For more advanced or per-story mocking, you can use a __mocks__ directory or subpath imports. Webpack aliasing is another pattern: swap real API modules for mocked versions in your Storybook config. The initial setup can be tricky, especially with builder aliases, but once configured, it’s manageable (discussion).

• If your components depend on network APIs, Mock Service Worker (MSW) is a popular way to simulate backend responses in Storybook. This lets you colocate API logic and test realistic flows, including user interactions, without needing to lift all state to props (discussion).

• You can keep internal state in components and still test them effectively in Storybook. Play functions let you simulate user flows and verify component behavior, integrating well with automated visual testing.

• If you’re using frameworks with quirks (like tRPC), centralizing mocks and using Storybook’s reset/restore features helps minimize drift and maintenance. For more details and examples, check the official docs on mocking modules.

You can try these patterns to balance colocation and testability. If you run into specific issues with tRPC or syncing mocks, sharing a minimal reproduction or more details will help with targeted advice.

To reply, just mention @dosu.

---

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