When building components meant to be used in different contexts, adding features can require adding complexity and code size. If the added features aren’t utilized by all consumers, some consumers pay the cost of supporting features they aren’t using. This is something library authors want to avoid.

Additionally, single components with lots of features can become quite unwieldy to develop and test. The authors of such components must weigh the cost of adding new features against the benefits they bring.

My talk gives architectural advice and tips/tricks for designing such large components in ways where the code for various features is decoupled, so consumers that don’t use specific features don’t pay for them in their bundles. Adopting these patterns may also increase maintainability in the long run.