I am modifying a component to add flashing animation between two colors while an item is in transition.
Currently, the icon props.color is easily assigned to either white or green depending on the presence of an item. This is done via simple, one line expression binding, outputting constant "white" or "green". if(itemPresent, "white", "green")
While maintaining the binary color choice, I would like it to also animate between the two while the object is in a transition phase - i.e. 'conveyor in motion'.
Item not present and conveyor not moving -> white
Item present and conveyor not moving -> green
Conveyor is moving, expecting item -> pulse white/green at 1hz.
I found that adding a Style Class and indexing it for Animated is suggested for how to manipulate this property with respect to time. This also works on its own - muting props.color.
The trick is layering them both together.
In props.color, using a Map Transform for my Style Class, it literally outputs the name of the style class (or the object, I suppose) rather than executing the Style class. So, this cannot be done within color AFAICT.
Separately, adding classes under style, I can add a Map Transform to output and execute my style class.
I can't seem to do both as props.color overrides props.style.classes (where I would actually like to switch that) and they seem to be incompatible types so I cannot figure how to stitch them together in some expression. Any ideas here?
You should not be doing any "animation" like this through expressions; you should handle this directly inside style classes (CSS) so that the animation happens locally in the browser (ultra fast) rather than via the gateway (slow and inefficient).
That aside, style classes (i.e. CSS rules) are applied to components via the various classes props, e.g. most commonly style.classes. They apply the CSS styles defined within them to the component itself. For example if the style class contains color: black, it would write the component's colour prop to black. You cannot apply a style class to a specific prop like props.color - this doesn't make sense.
CSS rules are applied based on their specificity. The higher the specificity, the higher its priority. Styles that are defined on the element itself are of the highest specificity (with the exception of styles applied with the !important override), such as props.color. Defining the colour here will override any other definition of this you try apply via style classes, so you need to make sure that the props.color is not set (i.e. is blank
) in order to let the style class set it
These would all be individual style classes.
i.e.
Styles:
Stopped_ItemNotPresent (your white colour)
Stopped_ItemPresent (your green colour)
Running_ItemExpected (animated flash between colours)
Then you simply switch between these style classes to change the styles applied.
(Obviously group and name these styles better...)
Don't think of them as colours, think of them as styling for the device states
In some other context, I could appreciate that distinction/perspective.
In my situation, these are literally some small beacon lights of specific colors within a much larger screen. So literally these Styles will be used only for these specific icons, each of a specific color.
Sort of a lot of digging for the next person to come along for dev who might not be savvy on props.style.classes. Where the current method of coloring in props.color is very 'in your face' and impossible to misunderstand.
Hmm, well instead of defining the colours then in the style classes, you could use a filter inside the style class instead which changes the brightness of the colour defined in the element style (props.color) to make it white... it's far less flexible, but if it's only the colour that changes it should work.
In the style classes for white and animated white pulsing, don't set a color and instead add ; filter: brightness(10) to one of the string prop values (e.g. background image)
Thanks for that example. I'll try it out to see how it fits.
I do have to say though, this strikes me as a clumsy solution for a simple feature add. As far as I understand, the only reason for me to use Style Class is effectively to leverage the utility of the timer function being handled implicitly. Unfortunately, the trade-off is that it makes a super simple detail into an awkward multi-step configuration.
is there not some internal system variable timer I could reference and AND it? Such as 100ms, 1s timers?
Both of these would require back and forth to the gateway for animation purposes, which puts more strain on the gateway (less scalable) and means animations will be more laggy (e.g. "1s" might be a range from 0.5s-1.5s; 100ms would be impossible, and would result in very sporadic animation).
The idea of style classes is to move bespoke, magic styling into a centralised global space which makes managing, maintaining, and ultimately delivering projects easier with far better styling standardisation. It adds more weight to upfront configuration though. If you're used to working in Vision or in most other SCADA platforms where styling is all element-based, I can understand your frustration. But webpages and by extension Perspective, need a paradigm shift. Element-based styling is clumsy by comparison; simpler to configure yes, but much harder to manage and maintain in the long run, as well as being very easy to end up with very different styling standards across pages
