Move addon-info into addons panel

[shilman]

Why

Currently addon-info shows component info in the preview pane alongside each story. This behavior differs from typical addons, that display their info in the addons panel.

Modifying the behavior to use the addons panel would make the addon available for react-native. It also means that addon-info can benefit from addon panel UI improvements in future versions of storybook-ui.

EDIT: It would also make the addon compatible with storyshots

What

• modify the info addon to use the addons panel
• update docs

[mthuret]

Maybe it would be better to split the addon-info features to be displayed in different panel? One for the description, one for the source, one for the propTypes? What do you think?

[Gongreg]

If you are thinking about splitting it into separate panels it starts to sound like separate addons which already exist.
There are propTypes addon, description addon, source addon.

[bigassdragon]

@shilman is this a new addon?

[shilman]

@bigassdragon i'm proposing modifying the existing addon, but it could also be a separate addon. it seems like there are a bunch of addons that do similar things in this space, so it would be nice (i think!?) to consolidate and remove duplication of work...

[bigassdragon]

@shilman is there a link to the existing addon we are talking about?

I tried looking for it but I have never seen or heard of addon-panel, I would not mind having any kind of merge just need to know what it would look like and if we can make and even more awesome addon that could incorporate a lot of slick things to make documentation better.

[shilman]

@bigassdragon sorry for the confusion. hopefully this clarifies?

[bigassdragon]

@shilman OOOOHHHHHHH. I definitely get it now. yeah I use those.

However I thought there was an addon that already does a panel view of the documentation.

I think you might be trying to do something like this: https://github.com/mihalik/storybook-addon-markdown

However the difference is it would use the addon-info plugin so you do not need to create a bunch of markdown files.

Is that correct?

[shilman]

@bigassdragon AFAIK:

• addon-info looks at proptypes etc. to create an API description semi-automatically
• addon-markdown accepts generalized markdown?

I think this should all be simpler, cleaner, and compatible with the rest of the plugins.

[bigassdragon]

@shilman correct, I was just making the comparison that you want the docs to show up in one of the panels in your picture above.

[bigassdragon]

@shilman I think this idea would be awesome. I kind of thought it would be cool to have the option to have it in the panel and if we put it in the panel let's provide the user the chance to remove the blue button that shows up where you switch between documentation and example.

I think it would be really slick if we can have the ability to show the docs in a panel and also the configuration to hide the blue button because that could be redundant to show.

[Gongreg]

@shilman:

Right now there are:

Plugin for documentation: https://github.com/Gongreg/react-storybook-addon-docgen
Plugin for usage: https://github.com/Kilix/storybook-addon-jsx , https://github.com/Gongreg/storybook-usage

As far as I understand the info addon is kinda like a wrapper for these two.

I think it would be good to have simply two separate addons inside monorepo, so users could choose to op out from using one of the addons if they want to.

And then the info addon wouldn't be necessary at all.

[shilman]

Thanks @Gongreg that makes a lot of sense. I think part of the problem is that addon-info came first and is mentioned all over the place in the docs, so lots of people use it and don't necessarily even know about the replacements. It's a little messy/confusing right now, but I'm sure we can come up with a clean solution here.

[shilman]

Here's another reason this should happen:

storybook-eol/storybook-addon-a11y#11

[ranneyd]

+1 really wish it worked this way

[shilman]

Furthermore, we should get rid of the addWithInfo(title, description, story) API because it makes it impossible for addons to interoperate. Instead, we can use the pattern used in other addons (e.g. notes).

Either:

storiesOf('MyComponent', module)
  .addDecorator(withInfo(title, description))
  .add('foo', () => <MyComponent />)
  ...

Or something like:

storiesOf('MyComponent', module)
  .add('foo', () => <WithInfo title='my title' description='my desc'><MyComponent /></WithInfo>)

[robinglen]

+1 for the first option

[tmeasday]

@shilman yes this seems like a very easy thing to change and a good practice to establish. A lot of addons out there follow the addWithX approach probably because they are just imitating the canonical info addon.

[tmeasday]

I looked briefly into replacing addon-info with the docgen and jsx addons that @Gongreg mentioned above. The issues I ran into (which are probably why he forked them) are:

1. The docgen plugin doesn't seem to have been updated for 3.0 yet, and doesn't quite work.
2. The JSX plugin requires the use of .addWithJSX() (strictly speaking this isn't a step backwards). Still it would be good to allow the decorator pattern @shilman mentioned above.

However these issues are probably easily solved. I am happy to help with updating these packages and bringing them into core alongside deprecating the info addon if the respective authors would like that to happen (@wcastand, @mihalik?)

[wcastand]

Hi, I wouldn't mind putting jsx into the monorepo but i'm not okay with the WithNotes pattern.
Addon for panels shouldn't be in my stories.
We know this is a issue right now and we discussing on how to change the addon API to allow this kind of patterns and avoid the overwrite of .add()

i use the addWithJSX because i need access to the storyFn() to create the JSX and i'm not okay with the WithNotes pattern :)

[tmeasday]

@wcastand -- do you mean you don't like the fact that the story gets "polluted" with the decorator?

Is there a specific reason you don't like it (i.e. does it stop you doing something?), or is it more a matter of style? (I don't really like it either)

I am looking at this from a short-term perspective. The issue with .addWithX() is you can only use one addon that uses it! This is a problem for adoption of addons.

Also the nice thing about the decorator pattern is you can apply it to a whole chapter or even all stories in a natural way using an API that users are familiar with.

My slightly longer term suggestion is to solve #993 and pass options in the .add() call. This avoids the decorator problem.

A new addons API would be good! But it seems a bit further off.

[hipstersmoothie]

I've published storybook-addon-react-docgen. It uses the docgen information just like the info addon but places the information in a Props tab in the the addons panel. It works quite well with the notes notes-addon

https://www.npmjs.com/package/storybook-addon-react-docgen

[JamesIves]

@shilman I know this is an old issue, but is there plans to implement this? I'm running into this problem where the addon info button is blocking parts of my component preview and would love for this data to appear in the addons panel.

[shilman]

@JamesIves Yeah it's been on the back burner for a long time but I have a prototype running and plan to release it in 5.1. we're putting a focus on component documentation now that 5.0 has been successfully released.

Note: it may be a new add-on that supercedes addon-info

[JamesIves]

Excellent! Is there an ETA for that release?

[shilman]

Hopefully we can get that feature available in prerelease by mid-April and a solid first cut by May

[avrilpearl]

@JamesIves --> you can define this in the configuration of the info addon as well: e.g:

addDecorator(
    withInfo({
      styles: {
        button: {
          base: {
            fontFamily: 'sans-serif',
            fontSize: '14px',
            fontWeight: '500',
            display: 'block',
            position: 'fixed',
            border: 'none',
            background: '#14558f',
            color: '#fff',
            padding: '5px 15px',
            cursor: 'pointer',
          },
          topRight: {
            bottom: 0,
            right: 0,
            top: 'unset',
            borderRadius: '5px 0 0 0',
          }
        }
      }
    })
  );

[JamesIves]

Thanks @avrilpearl ! This is a great workaround.

[inspiratweb]

Do we have any news about this @shilman?

[shilman]

@inspiratweb Addon-docs has been in alpha for over a month and is nearing beta. It solves a ton of problems with addon-info and adds a bunch of new features as well.

Read about it here: https://medium.com/storybookjs/storybook-docs-sneak-peak-5be78445094a

And get started here: https://docs.google.com/document/d/1un6YX7xDKEKl5-MVb-egnOYN8dynb5Hf7mq0hipk8JE/edit?usp=sharing

[shilman]

FYI addon-info is being superceded by addon-docs, which fixes a bunch of bugs and is easier to maintain. It’s reached release candidate (RC) status and will be properly released soon. Please give it a try! https://medium.com/storybookjs/storybook-docspage-e185bc3622bf

[shilman]

This is the most up-voted issue in the Storybook repo and I'm closing it. If anybody wants to pick this up, feel free to create a PR.

For those who care, here's the full explanation:

• addon-docs is the successor to addon-info. For the past few months, I've been redirecting all addon-info-related issues to addon-docs.
• addon-docs contains a superset of addon-info's features, and also contains many bugfixes.
• addon-docs should be better than addon-info in every way. If you disagree, please feel to file an issue, and we'll do our best to fix it. It should be an attractive, painless upgrade, and if it's not it means that we're doing something wrong.

Thanks for using addon-info; please upgrade to addon-docs today!

[DiegoBM]

It would be wise to redirect from the Info addon to the Docs addon in the Info page on Github, or warn about the deprecation in some sort of way there, just so that people know that the Info addon is not being supported anymore and that they should use Docs instead, and avoid wasting time trying to make it work.

[shilman]

@DiegoBM done. thanks!