Format of the pattern library

[karmatosed]

We have an issue for what it will contain. This issue is to work out the format. Will it be based on Gutenberg? Will it use other methods such as:

• Storybook: https://storybook.js.org/ and Storybook
• CRA https://github.com/facebookincubator/create-react-...

Are there other ways to do this?

We want to have this is easy to do as possible, how can that happen? Should it be automated or will that come later?

[karmatosed]

My own feelings on this are:

• Start documenting even in simple install using sketch file as basis
• Bring in more complex methods as time develops

If a fully automated way can happen, that would be great, but until then I think taking an example from https://wpcalypso.wordpress.com/devdocs/design and doing similar. At least this gets the ball rolling. What do others think? I will let some discussion happen here but looking to begin next week.

[aduth]

Some similar efforts:

• DevDocs: Generate a table for displaying proptypes Automattic/wp-calypso#10342
• DevDocs: Auto Proptype Documentation for Components and Blocks Automattic/wp-calypso#9289
• DevDocs: Generate an index of proptypes for client consumption Automattic/wp-calypso#9919
• Devdocs: add isolate mode Automattic/wp-calypso#8482
• https://github.com/reactjs/react-docgen

(cc @withinboredom)

Some of the format depends on what we want to show: If it's simple pre-programmed demonstrations, we don't really need anything automatic, just a separate component that renders the example. See also: example.jsx pattern in Calypso. The only issue here is that any adjustable values need to be manually implemented, which is not too bad, but could benefit from automation. Similarly, Calypso's DevDocs lack any code snippets or prop documentation.

Storybook has some nice solutions here:

• https://github.com/storybooks/storybook/tree/master/addons/knobs (adjustable props)
• https://github.com/storybooks/storybook/tree/master/addons/info (prop types table)

The work in #1786 kept some of these requirements in mind, which influenced it being implemented as a React application, since this will simplify embedding components for a pattern library.

[withinboredom]

I've worked with StoryBook with knobs in the past, and it forces you to make your components as prop-driven as possible and ignore state. I really liked it, personally.

The nice thing about it, is that it allows you to demo a component for someone and test it out while developing it. IOW, you can focus a little more on ux from the beginning instead of worrying about integrating it into the application to get it to compile, run, etc. I felt like it lowered the barrier to entry tremendously, because a junior dev could build something awesome and show it to us, without having to have a depth of knowledge about the application framework and state management. After they were done with the feature, they could grab someone and get help actually integrating the component itself (or someone could even do it for them).

My 2¢ about it, anyway.

[karmatosed]

I really like idea we explore as much automation on this as possible. Which ever way that goes. Would it be worth spending some time in the weekly meeting talking through this?

[karmatosed]

Closing as moving to the project. We are moving things to projects that aren't core Gutenberg and need to be done apart.