Building engaging, response UI requires a specific set of capabilities from the platform. Beyond the obvious need to specify dimension, position, margins, and paddings, the platform lets you specify a large number of styling options that affect layout, shadows, background gradients, typography, and animations.

This section describes two ways to dynamically control the UI style. Dynamic control of styles is needed to ensure that you can manage the look-and-feel of your UI based on runtime states. For instance, let's say you want to show the background color of a UI element to be green when a custom state, say "sales", is greater than $10,000, yellow if it is greater than $5000, but less than $10000, and red otherwise.This can be achieved in two different ways:1. Using display classes (Recommended):a) Create three different display classes which set the background to red, yellow and green b) Define conditions on yellow and green display classes that evaluate to true for 5000 < sales < 10000 and sales > 10000 respectively c) Ensure that the display classes are in the order red, followed by yellow, followed by green2. Using inline runtime styles: a) On the UI element, choose the function icon to reveal inline runtime styles option. b) Define a custom transform which takes the sales state as input and returns a background object with the appropriate color based on the sales data.

An extremely common scenario is when you want to show/hide certain UI based on state. In that case, the recommended approach is to create a "hidden" display class that has the "Display" style set to "none". The conditions for that display class can be designed to return true when you want the UI to be hidden. You just need to ensure that the hidden class is not later overridden by another display class that has the display value set to "Flex".

While both approaches work, there are trade-offs with each approach. The first approach is a lot more designer-friendly. Designers can simply select the class and change the styles visually. It also has the added benefit of visually inspecting how the UI would look with a display class at design time by using the designer override option. It is recommended to use the inline runtime styles only when the style information is not known at design time (for instance it comes from the server, or for instance, is derived from a runtime state. For example, you might want to make the background redder as the sales number goes to 0).

Last updated 5 years ago