Discuss requirements for a pattern to be added to polaris/polaris-patterns

[sophschneider]

• What requirements need to be documented before a pattern component is added to the library? (e.g. owner, tags, pattern documentation, stories, tests)
• What kind of linters do we want to build to prevent builders from shipping the wrong thing?
• Is there any kind of components we want to prohibit from being added?

[sophschneider]

Here are my initial thoughts

Code requirements:

• JS Doc descriptions
  • Component description
  • Prop descriptions
• Purely presentational - No data/graphql requests
  • If the component is tied to data or Shopify context (i.e. useShop), it should be made presentational before being added
• Component can be public
  • Doesn't have any internal private dependencies (i.e. monorail) because it is a security issue
  • Doesn't have any proprietary info or PII
• Needs an up to date owner
  • Codeowner to review component changes and context questions, UX/Product owners for design questions, UX owner for Figma
• Linked to Figma kit or file
• Has Story for Storybook
  • Could use the Figma plugin to validate that each component has a figma link
  • This also makes the component part of the UI regression tests

Documentation requirements:

• Every component has to map to a patterns page on https://polaris.shopify.com/patterns (but a single patterns page can be linked from multiple components). For example, the Date Picking pattern documents three different date picking components
• Maybe we can have a component page for each component as a sub page under the pattern?
  • That means each component would have to have a README with best practices, content, install instructions, etc.

Requirements that I'm not sure about:

We may have to add these later as we see what kind of components are added in. I think we could leave these out of MVP but just noting them here for discussion

• Has to contain polaris-react components? (i.e. don't allow completely custom components)
• Has to have tests?
• Any dependencies? Other than internal private dependencies do we have any other restrictions?
• Usage: does it already have to be used a lot in the Admin to be added here or can new components be added?

[gwyneplaine]

I think has to have tests is worthwhile as a code requirement.
If there's a good reason for there not to be tests for a particular component, we can always make an exception.
One requirement not mentioned here (likely because its obvious) is that the component also has to meet Polaris architectural and API standards.

Other than that I think this is a really good set of initial requirements for a component candidate to make it into the package 🎉.

[sophschneider]

Maybe we could require that every component added has a certain Polaris coverage percentage? I think that would be pretty cool