[dmitriid]

So, so many people in the comments saying "good to design components in isolation".

Why would design your components in isolation? Do they never interact with each other? Appear next to each other on a page? Participate in a layout?

This is my main gripe with Storybook in particular and any design system and design system tool in general: they never consider how components work together and force into a mindset of just documenting separate components complete isolation.

[ojkelly]

Build* in isolation the same way we chunk up server side code and test that in isolation. These are unit tests for UI.

Storybook gives you the framework to run them. Add something like cypress on top and you have the whole testing loop.

Making and updating the components in isolation reduces how much you need to reason about when building highly composable components.

The higher up you go (ie more composition) the less you can do in isolation.

But this is only building, you should design with as full an understanding of the rest of your components. Behaviours need to match, style needs to be consistent.

You don’t build a whole program at once, in the same way you can’t build a whole UI at once. At some point, you focus in on one area.

This because exponentially helpful when you team grows to a size larger than one.

[dmitriid]

> Making and updating the components in isolation reduces how much you need to reason about when building highly composable components.

How do you know they are composable if you make and update them in isolation?

[crubier]

Do you never use unit tests or integretion tests ?

When you are building an app bottom up, you will be working on components “in isolation” 100% of the time all the way up. Integration between components is just part of the behavior of a component higher in the hierarchy.

You can make stories of larger components assembling smaller components, entire pages, and even your entire app!

It’s been very valuable for my teams, especially coupled with Chromatic.

[dmitriid]

> When you are building an app bottom up, you will be working on components “in isolation” 100% of the time all the way up.

What? When you're building an app, you will always have components interacting with each other and being used with each other.

[crubier]

Yes but my point is that “components interacting with each others” is really just the implementation of another component higher up in the hierarchy.

E.g, the interaction between the submit button and the email input box is just the behavior of the whole form component. In react at least, your app is a component, so literally all the logic of your app is in a component in the end. And you can rest this component in storybook. So really there is no limit to what you can test in storybook in that sense.

[dmitriid]

> Yes but my point is that “components interacting with each others” is really just the implementation of another component higher up in the hierarchy.

It's not "just another component up in the hierarchy". If your components are truly composable, you don't need to create another "component" to be able to use them. But you do need to show how they can be used together.

> And you can rest this component in storybook. So really there is no limit to what you can test in storybook in that sense.

And yet, I keep seeing "components in isolation" and all examples (and all storybooks I've seen) have little to no examples of how these isolated components are used together.

[crubier]

I don’t know what you mean. I have dozens of stories showing components of all layers in the hierarchy. I have single button stories, stories for entire views, stories of entire apps.

And storybook allows to show the code of stories, which is equivalent to a « getting started » or usage example for each of these components in docs. Except that it is guaranteed to be evergreen, since if these examples break, my CI wouldn’t pass.

Labelflow is a public repo I manage with storybooks like that. We use Chromatic with storybook in there. Search for folders named « __stories__ » for stories at all level of the hierarchy. https://github.com/labelflow/labelflow

[dmitriid]

You're one of the few people who does things right then :)

[presentation]

Layouts are the parents concern, not the child. You test the parent for that.

[dmitriid]

I have no idea what you mean. Even Storybook's front page shows a video of completely isolated components. And every single example reinforces the idea of isolated components.

As if components existed in a void.

[presentation]

What I mean is, if a component is supposed to have two children side by side with even spacing, make a test _for that parent component_ such that with arbitrary children, they end up side by side with even spacing. If your children have that logic encoded in them, then you have brittle components (the moment you move that component elsewhere, it will be applying styles for a different layout)