In traditional web development, most interactions are of the request/response variety with a typical lifecycle consisting of a user navigating to a page, the required data is loaded based on a full fetch of the data model from a REST API. Updates to the data are performed when the user returns to the page or explicitly refreshes the page. In many cases, edit operations receive all (or a significant amount), of the data model to be returned and incorporated into the page model.

This model doesn’t apply in KOS as almost every interaction on the dispenser is potentially long-running and asynchronous. The KOS platform provides abstractions that make managing the complexity easier.

By using the KOS Model framework provided by the SDK, it is possible to create reactive application behavior that is driven by the KOS data model. Changes to the data model state are automatically reflected on the screen without needing any special listeners or loading actions.

Considering the event-driven nature of the dispenser architecture, the UI will need to be able to response to extremely fine-grained updates in a highly responsive manner. The KOS Model framework supports complex state objects that include computed properties that can be used to provide highly focused state updates to UI components with minimal overhead.

The KOS Model framework provides a state management capability that is tuned to the intricacies and underlying complexity of a KOS-based dispenser.

Most frontend web applications assume that the backend is driven by one or more backend applications servers with a highly optimized database services. As a result, many of the API calls from the frontend are built with the current "page" in mind with most of the data views and projections being produced in the backend.

In an embedded system, most of the system state exists in live operational data (control processes, etc…​) vs. sitting in a database. This means many api calls return narrow slices of data related to a particular function. As a result, it’s very common for a UI component or page to need data from multiple sources to display correctly.

So, unlike web applications where the architecture can be scaled horizontally and/or vertically relatively easily and cheaply, resources on a dispenser are limited to hardware on the device. So while the KOS architecture supports HTTP-like endpoints and controllers, the persistence layer and underlying device architecture makes it impractical to have complex endpoints with high amounts of processing. The result of this is that it’s up to the KOS Model framework to provide a baseline projection of the data model that will be updated based on small, focused events being sent over WebSockets from the backend.

The KOS Model Framework has built in support for this sort of interaction with Web Socket subscriptions and lifecycle management that is tuned to the expected behavior of a dispenser.

By using the KOS Model Framework and the KOS UI SDK, much of the underlying infrastructure will be ready to use out of the box saving time and reducing development complexity.

Provides an entity model and state management framework that is tuned to the behaviors and lifecycles associated with KOS-based dispensers.

A set of React hooks and utilities that enable the consumption of KOS Models and concepts in a form that will be more familiar to developers used to working with React on more traditional web-based projects.

One of the goals of the KOS UI SDK is to allow development of React UI Components within a KOS dispenser feel as natural as possible. For that reason, it is not opinionated about the use of third party component libraries or utilities when designing your Consumer UIs. Feel free to use any of the popular React component libraries (Material UI, Ant Design etc) or other third party utilities (emotionjs, css-in-js) from NPM or write your own as needed.