Dealing with Dependencies Inside Design Systems – EightShapes – Medium
Decomposing Features to Master Change Up the Chain
#5 of 6 of the series Releasing Design Systems:
Outputs | Cadence | Versions | Breaking | Dependencies | Process
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.
Many, many components depend on
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.
Atlassian’s AtlasKit exposes dependent relationships visibly in NPM. Their published components reveal
icon‘s dominance of 62 dependents that exceeds
avatar‘s 19, and
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.