Components and Patterns in polaris-react

[yurm04]

At a high level, polaris-react today is a combination of two kinds of components:

• small, primitive components (ex. Button, Radio Button, Link, etc.) to be used as "building blocks" AND
• large, monolithic components (ex. Autocomplete, IndexTable, ResourceList, etc.) that are (only sometimes) composed from the smaller building blocks

More often than not, these large monolithic components are actually UI patterns in disguise that are conveniently packaged up into reusable and customizable components that can be easily dropped into any codebase.

Issues
These large pattern components are:

• complex and can contain context-specific logic
• highly opinionated to reflect the state of the admin when the component was built
• too rigid to fit the diverse needs of merchants across multiple admin experiences today
• often NOT composed from primitive components and instead have complicated, prop-based APIs
• difficult to update/evolve

How Might We...
Reduce the number of inflexible, monolithic components in polaris-react and still provide designers and developers with the tools to reuse established UI patterns anywhere in the admin?

[yurm04]

Our initial aiming for components and patterns includes:

• Scaling the quality of our primitive components so that they are more flexible and act as better building blocks
• Removing large, monolithic components from polaris-react
• Rebuilding large, monolithic components (pattern components) to be composed from our primitive components
• Creating guidance around how to compose common UI patterns out of our primitive components
• Providing tooling to easily build and share UI patterns as code (Playroom is one tool we want to explore for this)

Removing large, monolithic components from polaris-react

Removing these pattern components from polaris-react allows our team to focus on creating great foundational primitives that can be used to compose these UI patterns more easily. This would also reduce the number of components our team is responsible for, bundle size, and codebase complexity.

The biggest downside I see to removing these pattern components from polaris-react is developers no longer get these components for free wherever they already use Polaris. This could be a very significant downside if this is what our users ultimately need the most out of polaris-react

Some things I think we're high confidence on:

• We need better, higher quality, and scalable primitives
• We want our primitives to be highly composable
• Our users need UI pattern guidance to continue to build high quality merchant experiences

A few open questions I still have:

• Do our users expect or need UI patterns inside polaris-react?
• How can we separate primitive components from UI patterns and still provide both as reusable code?
• Would composability tooling be an acceptable substitute for packaged up UI pattern components in polaris-react?

[heyjoethomas]

@yurm04 This is an interesting one. I would also be very worried about the impact of removing large components. I think the negative impact there would be pretty high.

I also would challenge the premise a little bit. What you are calling a pattern is almost always just functionality. Some components have very simply functions and others are very complex. That is totally ok in my mind. The functionality of something like a comboBox means we have to define, make a pattern of, how this thing works.

Should some of our complex components be more flexible and composable...yes. But should we try and rid ourselves of those complexities and only focus on primitives...I don't think so. Some of these bits of interaction and experience are absolutely foundational to the admin experience and I think should be codified inside of Polaris. Evolving those will always be difficult but I think we should just embrace that.