Scalable UI Component Systems

Continuing on From the UI/UX System From Before...

Level 1: Formation of Varied UI/UX Configured React Components

In my last article I had discussed how using a scalable UX system to create exportable configuration objects can be utilized to created scalable and expansive UI elements in view libraries like React. The previously described UI/UX system has an output of JSON configuration objects that describe various DOM elements. These rules are described by UI/UX designers and are the inputs into an abstract and configurable React component class, such as <Button {...cta_button} {...methods} />. In this example, I have used React, in the wild, any view library will support this concept through use of ES6 JavaScript to build abstract classes of DOM components that knows nothing except the shape of its various inputs and the types of methods it will be executing upon events as function of its output.

What occurs when we combine and execute two matrices of configuration components and ux/ui configuration objects, is a varied system of different specific DOM elements that match the UI/UX specifications. Full featured buttons, paragraphs, inputs that function as expected and look and feel as expected too. I call these components UI/UX Configured React Components.

Level 2: Formation of Compositional Components

With all the work now complete in level 1, we move on to level 2, where elements within the level 1 system combine to create a new varied abstract UI components that can be composed together later to create view fragments (in level 3). There can be multiple kinds of <LightBox> components that have different overlays, different headings, and layouts based on combinations of elements in the level 1 system.

Level 3: Formation of View Fragments (Composed Components):

With the formation of varied compositional components in level 2, the elements in that system can now be combined to create a much larger abstraction, called a view fragment. These are components that encompass a large level of complexity in a tightly interconnected relationship to perform a single function. An example is a <Navigation> component that allows a user to click on the <BrandLogo> and <CTAButton> or <FunnelButton> and have that entire component able to wire up those component I/O and export the data from that system to a yet even more complex component, called a view component (level 4).

Level 4: Formation of a View (Component):

A view component is what I consider the highest level of a component. It is on the edge of what is a smart component that knows about its context. A step further would be considered a container component that is responsible for it's IO and event system, but that's another article. The interactions of the components in this system are so abstract that the details of this interaction are hard to reason about without knowing what's going on under the hood. Yet, due to the simplicity in the structure of the elements within each system, it is scalable and easily configurable.

The Benefits

Because of the nature of needing to adapt to UI/UX requirements, we will need to adapt our UI components. Through this structure, where each level is a combination of the interactions between lower elements, the UI/UX requirements trace back down to the first level of configuration. Nothing within the component system defines it's own styles, methods or data. All of these critical parts are provided to the component system as a configuration object. Should UI/UX ever require an entire change to the UI, it is as simple as editing the configuration files that are implemented by the React Configurable Components and any component that has a schema defined by the UI/UX system.

The Drawbacks

Developers will need to embrace CDD (Configuration Driven Development) and if they are inexperienced in that area, the base configuration component may look so abstract that it worries an inexperienced dev. Another drawback is that because the component system is a hierarchical structure, where the current system leads to the development of the next one, if the library responsible for rendering the UI changes, the whole component system has to be re-thought. However, with non-configuration based UI systems, they usually toss out the old code anyways as it's too expensive to maintain. A plus, is even though the component system is replaced, the rules of UX remain abstracted away from the component system and will exist for the next view library.

-Daniel Ram