UI compoment state persistency

[dacsystemsw (DAC Software)]

What product/components do you use and which version/fix level?

Cumulocity IoT (backend 1011.0.19 frontend 1011.0.4)

Are you using a free trial or a product with a customer license?

Customer license

What are trying to achieve? Please describe in detail.

Hi,
It’s Luca from DAC System.
We are starting to build a custom web application on top of cockpit. We are porting a 2D chart from a pre-existing application. This chart can be customized setting up some property from the UI like y-axis min/max value, lines color and so on. All these settings need to be persisted in some way, clearly we don’t want to set them every time we need to read the chart.

This is a very specific use case but I can generalize: what is the correct approach to persistency?

1. Use built-in API? What if the entity I need to persist doesn’t fit the “pre defined” collections i.e. inventory, alarms, events …?
2. Create some sort of persistency layer on a microservice? If this is the case I need some clarification on these statements I found on Cumulocity IoT docs. Here it’s stated that “All persistent states must be stored at the Cumulocity IoT platform via inventory, binary, tenant options and other APIs. Persistent volumes are not supported.” On the other hand here under the statefullness paragraph: " Avoid statefulness wherever possible, rather write data via REST requests or DB to a persistent shared storage […]" What is the difference between a persistent volume and a persistent shared storage in this context?

Every bit of info or direction to look at is welcome.

Regards,
Luca

[Christian_Guether1 (Christian Guether)]

Hi Luca,

if you are using the Web SDK for Angular, you can define a configComponent for your widget. The configComponent is hooked into the configuration of a widget when you add it to a dashboard and extends it. As an example, have a look at this widget, which displays the indoor air quality. In the module you can find the general configuration of the widget. It also contains the definition of the component for the configuration: configComponent: IndoorAirQualityWidgetConfigurationComponent.

The IndoorAirQualityWidgetConfigurationComponent defines an input called @Input() config. This config is also later forwarded to your actual widget component as an input. Everything you save in the config variable will be persisted in the configuration of the dashboard Managed Object for the respective widget. There is no need to manage the persistence of the configuration of your widget yourself in some Microservice or whatsoever.

You can also have a look at the tutorial application, which comes with the c8y/cli: c8ycli new <<your-app-name>> tutorial. There you have a simple example inside the directory called ./widget. See ./widget/demo-widget-config.component.ts for additional details. It also comes with extensive comments.

Best regards
Christian