Object-Oriented User Interface
Tags: qatesting, frontend, javascript, react
Published: 2023-05-25 07:26:18

---
title: Object-Oriented User Interface
published: true
date: 2023-05-05 08:36:43 UTC
tags: qatesting,frontend,javascript, react
canonical_url: https://anton-m.dev/2023/05/05/object-oriented-user-interface/?utm_source=rss&utm_medium=rss&utm_campaign=object-oriented-user-interface
---

Object-Oriented User Interface (OOUI) is a design methodology that aims to separate the implementation layers of a user interface. In contrast to actual Object-Oriented Programming (OOP), OOUI is more of a metaphorical expression that helps developers, QA testers, and designers reduce cognitive complexity and view UI development in small chunks. With OOUI, developers can break down the development process into smaller steps, see results earlier, and improve the overall efficiency of the development process. This article will explore the different stages of implementing OOUI, from the code abstraction stage to integration into a real application, and how it can help developers build UI components in an isolated environment, which allows for easier debugging and testing. Additionally, we will discuss why CSS styles should be implemented as independent units and not directly tied to functionality.

It’s not a rare case when developers are having hard time starting a new project or a feature. There are always a bunch of unknowns. In addition, almost every engineer faced the case of an “infinite” development process. When results are visible only in the last 5-10% stages of their work. OOUI helps to separate the process into smaller steps and see results much earlier than in the regular approach.

A UI component should be a black box. It receives an input, then returns an output. A component may have two types of outputs: visual representation, and output data.

Components should not be coupled. They should not interact with the store, or database or make HTTP requests. 

## The code (abstract class)

Let’s call it an “abstract component”. In the code internal logic, html structure, and styles are defined. There also we define which parts, sub-components it will use.

An abstract component is the code a developer writes. The major part of code writing is blind. Blind in the meaning that a developer sees only the code, but doesn’t see any visual representation. 

This stage should be separated into small sub-tasks. Otherwise, a developer’s motivation shrinks if the blind phase lasts a long period of time.

This implementation should contain **unit tests**. The type of tests which usually check the correctness of the work of functions/methods. In other words, a function receives some data and is expected to return some data or perform an action.

## Live example of a component (class)

Build UI components in an isolated environment where a developer can focus on a specific component instead of running the whole application. Isolation allows running and debugging a component without the fear of being impacted by other pieces of HTML, CSS, or Javascript.

That’s not a component in the real application. It’s a stand-alone example where a component receives an input, then shows or does something.

As input, we use mock data. An example should be created per each different usage of a component.

[Storybook](https://storybook.js.org/) provides a wide variety of tools to run isolated components.

## Integration into an application (object, implementation, integration)

After all the previous steps are passed a component is ready to be integrated into the real application. Usually, after the previous stages, there should not be a real reason for the component not to work as expected. Most issues that pop up will be related to the missing functionality. It’s not rare when during the development process an engineer forgets to implement some feature or didn’t have a clear enough technical overview.

This implementation should be tested via **e2e tests**. Accessibility tests are among them. Interaction tests as well. They show how a component reacts to user interactions such as clicks, keyboard interaction, scrolling, etc.

## CSS framework

This layer purposefully was not mentioned in the OOUI approach. CSS styles should be implemented as independent units which can be reused in any part of the application without any relation to the functionality. Later these styles are applied via HTML classes.

In conclusion, Object Oriented UI (OOUI) is not actual OOP, but a metaphorical expression that means separating implementation layers in UI development. By using this approach, developers, QA testers, and designers can reduce cognitive complexity and see results much earlier in the development process. The OOUI approach involves creating an abstract component, building live examples of the component in isolation, and integrating the component into the real application. This process should be separated into small subtasks to keep developers motivated, and each stage should be tested thoroughly to ensure the component works as expected. While CSS styles are an essential part of UI development, they should be implemented as independent units that can be reused in any part of the application without any relation to functionality. Overall, OOUI provides a structured approach to UI development that can lead to more efficient and effective results.

* * *

The post [Object-Oriented User Interface](https://anton-m.dev/2023/05/05/object-oriented-user-interface/) first appeared on [Anton Mi](https://anton-m.dev).