addons.md

Storybook Addons long-term plan

Motivation:

• Consolidate addon API
• Ensure where possible addons are framework independent.
• Provide guidance around avoiding anti-patterns (addon-info, etc)

High level plan:

The key plan is to try and make addons run in the manager context rather than the preview context where possible.

This has some advantages:

1. Addons are framework independent by default
2. Users only have to load the addon in one context
3. It stops people messing with the preview, which is generally good.

Things that an addon may like to do:

(and how we'll make it possible in the manager)

1. Show an addon panel
2. Receive per-story information
   1. We will add the long-awaited options API: .add(name, story, options)
3. Modify inputs to stories
   1. Add an API to allow addons to provide (serializable) contextual props to stories (cf. knobs)
4. Read the list of stories
   1. We will improve the manager API
5. Change the currently displayed story
   1. (Use the manager API)
6. Modify the list of stories
   1. (With the manager API, only via serializable stories, or contextual modifications of existing stories)
7. Alter the display of the preview area
   1. We should have an API for this
8. Show more than one preview area
   1. We should have an API for this
9. Inspect runtime properties of a story [inspectors]
10. Wrap a story in extra components [decorators]

9+10 require running in the preview context, but we will limit them in the following ways:

Inspectors

Inspectors can work much like addons do now, but they will not have the ability to alter stories. Either use a pure decorator (if wrapping), or alter the story via manager-driven contextual changes.

Decorators

Are not seen as true addons. Do not have access to the addon channel etc. Can be communicated with via contextual props.