What Does a Scalable Component Mean?

Continuing on discussions about scalable UX systems that output configuration objects into a scalable component system, one might have questions as to what a scalable component means. The best example of a scalable component can be described in the view fragment component and in the case of an example, we'll consider the <Navigation /> view fragment component.

The <Navigation> component is an interesting one and a critically important one to any web application. Through this interface, the system provides an entry point to other parts of the system through various types of pages that are quite literally, inputs into the system and in a more simpler way, a navigation gives access to other functions of a system through different pages of the website. In a basic way, users can navigate on any device, on any page.

The <Navigation> is accessed by users on every page, on a varied number of devices and based on business requirements, may be subject to change to include more components within-it, to reduce components on screen width or to change the entire organizational structure of the <Navigation> while still keeping the composed components and containers still within it, just organized differently in another design structure.

So in our case, we must develop a <Navigation> component that can adapt to the organizational structure depending on an environment, or through a rule set by the UX/UI system. It must be extensible in that a new business requirement may need the navigation to now include a <AlertMessages> view fragment component. It could be that when we're on a device, we want a <Container> within the <Navigation> to be completely reorganized, extended and responsive.

When you build a system of UX/UI that outputs a configuration object for the components and also abstract out the structure and theme of the component to inputs to the system, this level of adaptability, responsiveness and reorganizational capacity can become a quality within the component itself and does not need a developer re-write or a write complete refactor of a component when there are new requierments. Quite truly, a refactor of a component means the design and abstraction logic within that system of a component was not thought out well enough to handle the requirements that would affect it in the future, it was not adaptable, non-responsive and unable to meet the changing business requirements, non-extensible to the needs of the business. It's akin, to linking a database with only a set number of read or writes, and if you need more, you have to unhook your database and hook a new one and copy over all the old data to the new one, just in this example, we're copying old logic by re-writing them by hand, like old copyrights did for books in the middle ages!

A system built from the ground up through the use of configuration based development, object oriented design and abstraction of logic in such a pattern where one system becomes an input to the next in a hierarchical organization of systems, easily sales and is easy to maintain and reason about and allows for extensibility, one of the most important factors of a growing business environment.

-Daniel Ram