Component-Driven Development

‚ÄčComponent-driven UI (Design Systems)

primo sites are made of components in the most literal sense. The focal point of component-driven UI is the component library. Normally you build components in isolation, separated entirely from their context or data. Since the IDE and CMS are one, you can build and integrate in one go, reuse components, and enable content editors to build entire pages using the component library.


In the past, any given web artisan thought of a website as a collection of templates. A template is a pre-built page which is meant to have its content overwritten in-place. A template is like a starting point, but one meant to be filled out rather than modified. A better way to think about it might be as a form, which works perfectly for predictable values of a particular type.

The adoption of templates probably came from an understanding of websites as print publications (which use templates extensively), if not engineering reasons. After the emergence of components - presentational rectangles that may or may not exist on any given area of the site - templates were thought of as pre-built pages which should have their content filled out (including component content).

The immediate problem of this approach is what one should do when they can't fill out a component. Assuming they have a way to hide it, hiding it often breaks the entire page design and layout. Besides that, content editors started finding cases where they wanted to do things like replace one component in a template with another. The end result of this was an endless list of "templates" that mostly just deviated based on which components they contained.

Once we realized that the main deviations from one page to another were its components, we replaced templates with static layouts (e.g. sidebar, sidebar-left, split-column) and a component library - a list of reusable components (usually presented in a Design System) which act as a toolkit for content editors when building pages.

Atomic Design. The toolkit varies in functionality and flexibility, but the conclusions are the same - that websites are made of components, so our development should be component-driven.

How primo does it

  • Developing and editing component-by-component

  • Encapsulating styles

  • Symbols

  • Page Sections