On this page

All pages

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space TDDM and version 1


A single Tui component contains all of the above technology chunks within the same file not only for convenience, but also to encourage component-based encapsulation. The following images illustrates the change in the separation of concerns between our legacy approach and Tui.

Separation of concerns diagram.Image Modified



  • Atomic Design, in that there are low-level SFCs that do one thing, medium-sized SFCs that aggregate those smaller components, and page SFCs that control layout and are the entry point for PHP to render a Tui component
  • 'Smart' and 'Dumb' components, in that we would prefer to avoid 'super components' that do everything, breaking them apart into smaller components facilitates re-use, but also can simplify understanding of how a given component works

Organising components

Within Tui core, we mostly follow a structure where components are organised based on what they do, e.g. form components are organised into client/component/tui/src/components/form, as this makes reuse more obvious. Within plugins, however, grouping components by related functionality can make a feature more understandable for other developers, and in the future will make deprecating component trees more manageable when required.

Renderless components

Sometimes creating a wrapper that provides functionality is required, but HTML is not. Adam Wathan describes this well: