Pattern for reuse/sharing of decorators common to a group of packages?

[SpanishPear]

Summary

Hi!

I help maintain a rather large monorepo, and a common question we get is how to best structure decorator reuse between a collection of story files. This is a common question as often the decorator list can be quite long for our more complex components, and developers want to avoid the re-use where possible.

For example, consider the following:

my-repo/
├─ src/
│  ├─ app1/
│  │  ├─ pkg-a/
│  │  │   ├─ baz.stories.tsx
│  │  ├─ pkg-b/
│  │  │   ├─ bar.stories.tsx
│  │  ├─ pkg-c/
│  │  │   ├─ foo.stories.tsx
│  │  ├─ utils/
│  │  │   ├─ decorators.tsx
│  ├─ pkg-d/

pkg-a, pkg-b, pkg-c all want to share a list of 5 decorators - is there a great way to do this? Currently, there are two main solutions in use.

Solution 1 - utility file that exports a list of decorators

This is mostly common for the larger lists of decorators, a file (usually something like app-1/utils/decorators.tsx and then that is

export const commonApp1Decorators = [list, of, my decorators]

// pkg-a/foo.stories.tsx
import { commonApp1Decorators } from '@app1-utils/decorators.tsx';

export default { 
   decorators: commonApp1Decorators,
   component: foo,
}

Which is then used in every story file's default meta export.

Solution 2 - Duplication

This is mostly preferred by teams who want increase greppability/static analysis - they'll just copy and paste the decorators.

Question

Is there a preferred or conventional way to re-use decorators amongst multiple but not all (i.e. not global) packages?

Additional information

No response

Create a reproduction

No response

[Marklb]

I don't know if there is a recommended pattern for that, but I tend to look for patterns used for test/spec files, when I can't decide. Storybook has become the main tool I use for testing components, but even before that I thought about it this way. Most things I share are based around providing mock data or implementations, which would also be done for tests, even if I am not adding tests to the stories. So, I often group them with my shared test exports. If I had more Storybook specific shared things then maybe I wouldn't mix them with the test utilities, but I am normally sharing a mock or wrapper of something.

The way I do it normally ends up being something similar to your Solution 1, but I do tend to duplicate more than I should. Solution 2 typically becomes Solution 1 after I notice that I keep duplicating something.

[SpanishPear]

That's a good way to think about it, thanks! Sounds like we are using the right framework then, as it's very similar to this:

Solution 2 typically becomes Solution 1 after I notice that I keep duplicating something.