Layouts, Elements, and Buttons can change during run-time to create a dynamic user interface.
Modifying components during run time through Snap rules
After you define the default design of a UI component at design-time, Snap code can change those defaults during run-time. Just about any property of a layout, element, or button can be changed during run-time: see the examples below.
What can't be changed? UI elements in the design tree cannot be created or destroyed, nor can their order in the configurator explorer be moved. In most cases that seem to require creating, destroying, or re-ordering, simply hiding and showing components will give the same effect.
Gathering the components you want to change
Get element
You can also declare a variable as a pointer to the element using the get element block. Changes you make to that variable are applied to the element.
Get children of type
Changing component properties during run-time
To change many elements, use the get children of type block. This collects all the elements of a certain type in any given parent. One can gather up all the fields in an expander, or all the expanders in an accordion.
For example, say a configurator has a group called "Group". Regardless of how many other components are within this group, or how nested those components are, you can gather up all the fields within this group (and within all the components within that group) with one Snap block:
This Snap block will create an array of every field that appears indented beneath this "Group" element in the explorer view of your configurator.
Set element
If you need to make a simple adjustment to one element, find the element and adjust its properties in one line by using the set element block.
The enum block
Examples
Related articles
Once you have the collection of components you want, loop through them and use the set or set element block to change any of that component's properties, as seen in the examples below.
Some field properties expect a boolean, number, or text value. However, other field properties are a list of values you select as an administrator. To change one of these properties, use the enumblock. This special value block offers you the list of options for whatever property you are setting in the set element block.
The context of code like the examples below is usually in response to
- an edit the user makes to a field, via a value rule.
- a navigation the user performed, such as the page changed event.
- parameters passed into the configurator before it loads the first time (from a web embed, or from a salesforce integration). These are used to update the UI via a loaded rule.
Showing/Hiding fields
Sometimes, you may want to show the hidden fields and calculations in your configurator. Here's an easy Loaded Rule to expose this information, if conditions are correct:
If the user is a company administrator, and we're not in the production environment, then scan all the fields in this configurator: if a field has the text "(for Admins only)" in it's label, then make it visible. Once this run-time rule is in place, your design-time work is simple: change the label on any administrative field to include that phrase, and set the visibility checkmark on that field to false (make the field invisible). When this rule runs, those fields will become visible for administrators and hidden to everyone else.
Updating field labels
If you declare a variable as a pointer to an element, you can use the setblock to manipulate that element, such as updating the label of a field.
Changing the properties of a group of fields
Let's say you have a "fDesiredPrecision" field. It stores a number, but the control is a select list:
You can create a value rule which applies the precision the user selects to all the number fields within a certain group in the UI:
This results in the following user interface, where the "precision" field instantly changes the precision of all 6 user input fields.
Furthermore, if you want to add or remove a choice, you don't have to update your code. Just update the picklist choices in the "fDesiredPrecision" field.
Reading field values from a dynamic group of fields
Consider a cube configurator, which allows the user to specify the dimensions of a cube (height, width, and depth). They can also ask for a hole drilled through the cube. For structural reasons, the hole diameter can't be larger than any of those 3 dimensions, or the cube would fall apart. How can you be sure the maximum diameter of the hole meets these dynamic engineering constraints?
At first, you would create a validation rule to enforce this business requirement:
Which would give this user experience:
That's fine for 3 fields, but what if you have 20 to scan? Or more? If you have many fields you need to scan, try using the "get children of type" block. The updated code below scans all the fields within a group in the user interface. If any of those fields are a number field, then we see which of those fields is the smallest. We then use that smallest number to set the maximum allowable size for a completely separate field.
- The strength of this rule, compared to the previous one?
If our configurator design changes in the future, and new number fields are added to this group, they are automatically included in the business logic. - The weakness?
You are linking together your UI and your code: depending on where fields are in your UI, your code behaves differently. For many programmers, this breaks the model/view/controller separation of concerns, and would be considered bad design. For example, moving the "fHeight" field out of the group would prevent it from being scanned. It's up to you to consider if this makes your configurator easier or more difficult to maintain.
Dynamic max value of a slider
Continue the same example of a cube configurator, which allows the user to specify the dimensions of a cube (height, width, and depth). They can also ask for a hole drilled through the cube, but for structural reasons, the hole diameter can't be larger than any of those 3 dimensions (or the cube would fall apart).
An improvement would be to change the maximum allowed value of the Hole Diameter field in the user interface dynamically, based on the previous fields. Keep the existing validation rule, and add a new value rule:
Which would now give this new user experience, where the max of the Hole Diameter field changes dynamically: