Architecture

Design Choices

The following topics are the specification and application of the design patterns/choices used in the development of the framework.

State Pattern

The state pattern is a behavioral software design pattern that allows an object to alter its behavior when its internal state changes. The state pattern can be interpreted as a strategy pattern, which is able to switch a strategy through invocations of methods defined in the pattern's interface.

The state pattern is used in computer programming to encapsulate varying behavior for the same object, based on its internal state. This can be a cleaner way for an object to change its behavior at runtime without resorting to conditional statements and thus improve maintainability.

The framework has a single state, when an event occurs, this state changes to a new state. The visual output of the framework is simply a reflection of the current state. The user is one source of events, when the user interacts with the dashboard - changing one filter prompt for example -, these events change the current state and then the visual output is updated to reflect the new state.

Mediator Pattern

“In software engineering, the mediator pattern defines an object that encapsulates how a set of objects interact. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior.

In object-oriented programming, programs often consist of many classes. Business logic and computation are distributed among these classes. However, as more classes are added to a program, especially during maintenance and/or refactoring, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes.

With the mediator pattern, communication between objects is encapsulated within a mediator object. Objects no longer communicate directly with each other, but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby reducing coupling.”

The mediator pattern allows developers to develop components that can listen and therefore interact with events happening in external components. The mediator allows for greater integration possibilities between two or more individual components.

Component Lifecycle

The components have lifecycle phases that can be used to perform actions. These are the lifecycle phases of any component:

• Component Construction
• Component Will Mount
• Component Render
• Component Did Mount
• Component Will Receive New Props
• Component Render
• Component Did Update
• Component Will Unmount

Tree Structure (Components)

“In computer science, a tree is a widely used abstract data type (ADT) that simulates a hierarchical tree structure, with a root value and subtrees of children with a parent node, represented as a set of linked nodes.

A tree data structure can be defined recursively as a collection of nodes (starting at a root node), where each node is a data structure consisting of a value, together with a list of references to nodes (the "children"), with the constraints that no reference is duplicated, and none points to the root.”

The components are stored in the state as a tree structure. But the current tree of components changes based on other variables in the state such as current page or current subpage. Only some part of the tree of components is being rendered at a time and it depends entirely of the current state.

Service layer pattern

“Service layer is a design pattern, applied within the service-orientation design paradigm, which aims to organize the services, within a service inventory, into a set of logical layers. Services that are categorized into a particular layer share functionality.

This helps to reduce the conceptual overhead related to managing the service inventory, as the services belonging to the same layer address a smaller set of activities.”

We have two distinct types of components in the framework, visual components and services. Services are centralized pieces of functionalities that provide specialized services such as:

• Report Service
• Filter Service
• Print Service
• Export Service

We have only one single instance of each service, but those single instances of each service can serve any number of components.

Services are still rendered as components and therefore have component lifecycle phases.

Single Multistate

Within one single state, we can have multiple different states based on anything that we need. For example, one possibility is to be able to customize what should be the visual output based on a screen resolution breakpoint. But we can go even further and have a different visual output for print and/or for fullscreen.