Storybook + Apostrophe 3.0

We’ve built out a lot of cool A3 stuff in isolation but we need to figure out how apostrophe-storybook and Apostrophe co exist before things diverge too far.

Where should Vue components be authored in Apostrophe?

Option 1: Components live in Storybook and are imported into Apostrophe 3.0

This is what we’re currently and it feels good. A blank canvas where you can just start writing an atomic piece of UI and know exactly where the files are going to go and how to write your story states.

Pros:

• Easy to get going
• Single, flat architecture where all components can be found
• Test driven approach ‘feels’ good

Cons:

• Writing new components happens in apostrophe-storybook instead of core. Friction!

Option 2: Components live in Apostrophe and are imported into Storybook

This makes more intuitive sense because when you’re updating or writing a new component, you’re writing it in the Apostrophe core module.

Pros:

• Easy to contribute
• Modules own their components. Apostrophe-UI contains all generic interface.
• A path forward for Storybook being a visual testbed where apostrophe and non-core modules could be installed can exist.

Cons

• Storybook becomes non-essential and prone to rot
• Harder to just ‘get started’ because you need to build your own context.

Where does Storybook live?

In either scenarios above we’re assuming Storybook is a separate repo, but it doesn’t have to be! In an effort to further reduce separation and ‘things to maintain’, Storybook could live alongside Apostrophe in core. This would make for a bit smoother development flow as you wouldn’t have to symlink the repos together in order to update both. Thoughts on that?

[stuartromanek]

A pattern where the story is bundled with the component would make it very clear for future component development, so I like that ✔️

Putting SB right into the core apostrophe module seems good from a maintenance perspective ✔️

So all we would need would be some loader so that SB could inhale all registered Apostrophe components and their stories and then you would never have to fiddle with Storybook’s config, just fire it up and run your tests. ✔️

Are we at ✔️✔️✔️ on Option 2 + Yes on the bonus question?

[boutell]

This direction looks great.

On Mon, Jun 24, 2019 at 10:43 AM Alex Bea [e-mail] wrote:

I think we’re at yes-yes-yes (mostly just wanted to say that). The caveat I’m seeing is that this bakes an arguably non-essential and substantial mechanism into the CMS. Theoretically it could be removed or replaced later… at the risk of devs depending on it in some way. I don’t know how that’d be, but not unimaginable.

So for the Road to Three Dot Ex™️ this seems totally fine. Two suggestions to pick one: 1) We document https://github.com/apostrophecms/apostrophe-documentation/tree/3.x that Storybook is purely for CMS development and not to be relied on, or 2) We create an issue to review this setup again before releasing v3.0 in case better ideas have come up. I’d vote 2️⃣ there.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/apostrophecms/apostrophe/issues/1954?email_source=notifications&email_token=AAAH27JK3M53AZGQ6BJUHADP4DMPRA5CNFSM4H2UQYPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYNFAKY#issuecomment-505040939, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAH27JIOMZCLIRYKJCA663P4DMPRANCNFSM4H2UQYPA .

–

Thomas Boutell, Chief Software Architect P’unk Avenue | [phone] | punkave.com