Decomposing Features to Master Change Up the Chain

Within a component library, what component has the most dependents (other components in the library that include it)?

“Button!” is a knee-jerk response. Good guess! Buttons are reused heavily by many other components. “How about paragraph?” someone suggests. Not exactly. Paragraph is usually reused as a style, not a component. I pause, then reveal “Would you believe… icon?” Ahhh, of course, icon.

Components that depend on the icon component

Many, many components depend on icon: checkbox, button, select, alert, list group, and so many others. Even a simple, atomic button can include two icons, one to the left and one to the right! Hopefully icon stabilizes early, and doesn’t change often. But when it does? All those dependent components must change too.

Compositional depth isn’t limited to two levels, and components don’t exist only on one prescribed level, anyway. A card can depend on a button, and both of them can depend on icon. Effective system teams understand this and cope with change across this hierarchical chain of dependencies.

(Some of?) Atlaskit’s component packages with the highest number of dependents.

Composability made concrete exposes the dependency chain that a team must maintain as a library changes over time. As systems mature, teams build, trace, and update components as change ripple up through the hierarchy to keep their library outputs in sync as much as possible.