IMO The trickiest part of building an internal component library is figuring out the line between flexibility vs. complexity of components
I came up with 6 areas of component functionality from least to most likely to need flexibility from the perspective of the dev
I came up with 6 areas of component functionality from least to most likely to need flexibility from the perspective of the dev

1. Cross-browser compatibility
Basically no one wants to have to worry about browser compatibility when using a library
A component lib for an org should know the supported browsers so the components should support all of 'em
Basically no one wants to have to worry about browser compatibility when using a library
A component lib for an org should know the supported browsers so the components should support all of 'em

2. Accessibility
Similarly the lib should be fully accessible, so not much flexibility is needed
Components may need to take an `id` or `label` that will be used for ARIA attributes
Similarly the lib should be fully accessible, so not much flexibility is needed
Components may need to take an `id` or `label` that will be used for ARIA attributes
3. Color
The overall color palette should be expressive enough (a red for error, a blue for links, etc.)
A component should be able to be built from the palette and its colors really shouldn't be changeable
An exception is theming where colors are abstracted to semantic names
The overall color palette should be expressive enough (a red for error, a blue for links, etc.)
A component should be able to be built from the palette and its colors really shouldn't be changeable
An exception is theming where colors are abstracted to semantic names
4. User interaction
Most of the configuration is here, although the more options the more complex the component will be. Definitely avoid mutually exclusive options
Also accept callback functions that will be called at key events (i.e. onSubmit) for inversion of control
Most of the configuration is here, although the more options the more complex the component will be. Definitely avoid mutually exclusive options
Also accept callback functions that will be called at key events (i.e. onSubmit) for inversion of control
5. Visual design
Ideally the component looks the same everywhere but at times designs call for the component to act the same but look different
Provide inversion of control where the dev renders the UI themselves but still get everything else. Basically render props in React
Ideally the component looks the same everywhere but at times designs call for the component to act the same but look different

Provide inversion of control where the dev renders the UI themselves but still get everything else. Basically render props in React
6. Layout & spacing
Probably the trickiest & most annoying. Mocks want the same visual design but different internal spacing. The bigger the component the more potential tweaks
Let devs compose components internal components together, kinda like compound components in React
Probably the trickiest & most annoying. Mocks want the same visual design but different internal spacing. The bigger the component the more potential tweaks
Let devs compose components internal components together, kinda like compound components in React
If you made it this far you're probably sufficiently interested in this topic so I wrote it up in long-form for you to read and get more details
https://www.benmvp.com/blog/configurability-design-system/
It's helped me, so hopefully it helps you too!
https://www.benmvp.com/blog/configurability-design-system/
It's helped me, so hopefully it helps you too!

Oh and I've got a minishop called Sharing React Component Logic coming up where we'll learn about a few of these design patterns (render props, compound components, etc)
https://www.benmvp.com/minishops/sharing-react-component-logic/
You can sign up to be notified when the date is officially scheduled
https://www.benmvp.com/minishops/sharing-react-component-logic/
You can sign up to be notified when the date is officially scheduled