A Field Rule is executed only whenever that specific field is edited by a user. To create a field rule, select the field in the design tree, and right-click to see the context menu for that field. Choose "+" to add a field rule.
Field rules are rarely used. In most cases, following the rule execution order, you can use a value rule as a more appropriate place for your logic. The only time you would want to use a field rule is when you want some logic performed before the option filters are run. All other rules are run after the option filters.
We suggest you minimize your use of this rule. Usually, placing the Snap block logic you wrote here into a value rule will give you the same results. Furthermore, by placing your logic into a value rule or one of the other standard rules, you centralize your code and make your configurator easier to maintain.
Arguments
Arguments are variables passed in to the rule. You can find them by using the Get/Set variable snap blocks. In this rule type, the Get block exposes these arguments:
| Name | Type | Description |
|---|---|---|
| configurator | Configurator | the current running configurator. |
| environment | string | "dev" if you are in the development environment, "test" if you are in the test environment, and "prod" if you are in the production environment. |
Example 1: Cleaning input
A field rule can be used to strip whitespace, reformat, or otherwise clean the input before it's used to drive logic elsewhere. Here, we strip any leading and trailing whitespace, and reformat to Title Case. See also the textbox mask as a way of gathering clean data.
Example 2: Updating a computed field used by an option filter
Problem: Your option filter, based on query logic that includes a field that is computed, shows results which are "one click behind" the user interface. For example, options should disappear, but they remain on-screen until the user makes some other field edit: then they appear correctly.
Source of the problem: The computation is running after the option filter is refreshed, instead of before the refresh. For example, if your computed field is maintained by a Value Rule, the order of operation shows us that value rules run after option filters are refreshed. So, the option filter will be based on outdated data that's one edit out-of-date.
Solution: Instead of calculating that field's value in a Value Rule, copy your calculation code from the Value Rule into one or more Field Rules associated with the fields the calculation is based on. Now, the calculation will happen before the option filter, rather than after, and your option filter results will be immediate, and not one click too late.
For example, let's say you have a cube configurator, which has editable fields for Height, Width and Depth. The configurator also has a 4th computed field, called Volume, which is the product of the first three fields.
Usually, you would calculate the Volume field in a value rule.
However, if an option filter is using Volume in its logic, then copy the calculation code from the value rule into those 3 editable fields as 3 value rules. In this way, the Volume field will update immediately after any of the the Height, Width or Depth fields are edited, and before the option filters are refreshed.
Tip: since you might be placing the same code into multiple locations, try storing your calculation logic in a function in a global rule. That way, even though you are calling the logic from multiple places, it is written in only in one place so it's easier to maintain.