March 16, 2021
newsletterHave you ever been reading proposals for a new component and seen this conversation play out?
Reviewer: Nice proposal, but I think we’re missing a potential use case. Can this Button component support an icon?
Proposer: Oh, I forgot about that. Shouldn’t be a major change. We can add an icon prop and people can pass an Icon component to it. Something like this:
const Icon = () => <svg />;
<Button icon={Icon} />;
Reviewer: Hm, I’m not sure I’d do it like that. I think this approach would be better:
<Button>
<Icon />
Click me
</Button>
End scene. Good thing I took up coding instead of screenwriting.
Design systems teams need to agree on the API they will offer to their consumers, and they generally have two choices: configuration or composition.
In the example I shared, the proposer is recommending configuration over composition. In their example, the consumer should be able to pass data to the component, and the component should know exactly how to render itself based on that data. This approach has a lot of benefits!
The reviewer, on the other hand, is recommending composition over configuration. In their response to the proposal, they are suggesting that consumers should be able to take small building blocks and combine them together in whatever order they’d like. This is a very powerful model that a lot of design systems prefer.
Like most questions in design systems, the approach you choose depends on a few different factors. You should ask yourself the following questions to help determine which approach to take:
My only recommendation is to get this conversation out of the way early, and to make sure the whole team is aligned on the how and the why of your chosen approach.
If you liked this post, please consider sharing it!
Sign up for the Design Systems Newsletter today!