Added AlarmDataInternal type to support logic to find and filter alarms with inputProperties
Updated useAlarms hookHelpers to pass through the AlarmDataInternal
Introduced filterAlarmInputProperties() to handle logic for setting the inputProperty AlarmData field
Removed logic for setting the status.errors field. Decided to not use this field until we determine its purpose.
Why?
Did not implement setting the inputProperty of AlarmData correctly. There are two use cases:
Alarm request has an inputPropertyId
Need to collect all alarms for an asset, then after fetching each alarm's IoT Events alarm model we can determine which alarm actually has the input property. The easiest way to do this with the cascade of hook calls in useAlarms is to keep track of the original request for each alarm and the asset/assetModel properties so the property object can be set in the inputProperty field.
Alarm request does not have an inputPropertyIdinputProperty will be resolved after the alarm models are fetched. The AlarmDataInternal.properties field will be filtered down to the property that matches the alarm model input property.
Minor changes:
Added type to all relevant imports
Updated file names to accurately depict modules instead of utility files
Updated function names and comments
Verifying Changes
Scene Composer
For scene-composer package changes specifically, you can preview the component in the published storybook artifact. To do this, wait for the Publish Storybook action to complete below.
Click on the workflow details
Select the Summary item on the left
Download the zip file
To run the storybook build locally, you need a local static web server:
npm install -g httpserver
cd <Extracted Zip Directory>
httpserver
Overview
Major changes:
AlarmDataInternaltype to support logic to find and filter alarms with inputPropertiesuseAlarmshookHelpers to pass through theAlarmDataInternalfilterAlarmInputProperties()to handle logic for setting theinputPropertyAlarmData fieldstatus.errorsfield. Decided to not use this field until we determine its purpose.Why?
Did not implement setting the
inputPropertyof AlarmData correctly. There are two use cases:inputPropertyIdNeed to collect all alarms for an asset, then after fetching each alarm's IoT Events alarm model we can determine which alarm actually has the input property. The easiest way to do this with the cascade of hook calls inuseAlarmsis to keep track of the original request for each alarm and the asset/assetModel properties so the property object can be set in theinputPropertyfield.inputPropertyIdinputPropertywill be resolved after the alarm models are fetched. TheAlarmDataInternal.propertiesfield will be filtered down to the property that matches the alarm model input property.Minor changes:
typeto all relevant importsVerifying Changes
Scene Composer
For
scene-composerpackage changes specifically, you can preview the component in the published storybook artifact. To do this, wait for thePublish Storybookaction to complete below.To run the storybook build locally, you need a local static web server:
Then open the website http://localhost:8080 to run the doc site.
Legal
This project is available under the Apache 2.0 License.