Before how it works, it is better to clarify how to make it work. To consume MynahUI, there is only one single requirement, npm access. Adding @aws/mynah-ui to the package.json dependencies will allow the consumer to grab the desired version of MynahUI and allow them to create an instance of it to be rendered in the desired dom element.
To install:
npm install @aws/mynah-ui
And to create the instance:
const mynahUI = new MynahUI({...});
As indicated above in the section, it expects data and sends events. The expected data from the MynahUI can be passed with several ways like defining them during the initialization, updating the data store directly or adding one or more chat items during the runtime. Let’s take a look to the basic flow between MynahUI and the consumer:
As we can clarify from the flow, MynahUI expects data from the consumer app and renders new elements or updates existing ones on the UI. And it is also responsible to deliver the user events to the consumer app to let them run their logic.
MynahUI relies on three core structures, the Data Store, Global Event Handler and Dom Builder. The combination of these 3 basically drives the MynahUI structure.
The data store consists of 2 parts. The main data store holds all the current data for the tabs. Since MynahUI supports multiple tabs, each tab has its own data. And the second block in the data store is the data for each tab.
Global Data Store → Tab Data Store 1, Tab Data Store 2 ... Tab Data Store N
Tab Data store holds every single content related with that tab, like chat items, tab title, background, prompt input field related information etc.
Here’s an overview of what it looks like:
The global event handler can be used by any component, to listen or fire a non data related event happened through the system. And more importantly, they can also fire events to inform the subscribers.
For example, when a tab gets focus (basically being selected) it fires an event through the global event system which is called TAB_FOCUS. And if there is any subscriber to that event, their attached handler function will be called.
DomBuilder is at the heart of the rendering part of MynahUI. Basically, every single UI (HTML) element is being generated from the DomBuilder. It helps to manage dom manipulation from one single space. For example when you need to add some specific attribute to any dom generated in the MynahUI, it will be handled from this singleton class.
The main class (MynahUI) handles all the creation of these core parts and the communication between them.
To clarify how all those structures work together, a simplified flow can be showed as follows:
Components are using the DomBuilder to build up their HTML elements. Or, they can also use other components as well.
Each component should have their render, which should also be just an HTMLElement or an ExtendedHTMLElement which is the output of the DomBuilder.
For the styling of the elements and components, MynahUI uses basic css structure. However to make it as clean as possible to read and generate proper hierarchies, we’re building the output css from SCSS.
But an important notice here, we’re trying to avoid using SCSS variables as much as possible and keep every possible thing as a CSS Custom property.
The styling of the components cannot have static values or inline values. With the support of the CSS custom properties, it is possible to theme it in every single detail like colors, paddings, sizings, fonts even animations and transitions.
Here’s a general look of a component structure:
