Using refresh and visible when conditions

Avoid using refresh other section and instead, use refresh on change based on a property change.

Refresh on section action has several issues:

• The section name is defined in the action configuration and can become difficult to maintain 
• Better to use Declarative programming instead of Reactive programming
• The action set does not need to know which section to reload

Refresh on change is very often a better and more granular approach - It can be applied on a dynamic layout (as well as on a section) and avoid the need to move the dynamic layout into its own section. Using refresh on change can help reduce the number of nested sections.

Example:

A property in a header needs to be updated when the property pyWorkStatus changes in a different section.

Using several visible when conditions in a section included in a repeat list are expensive.

• Try to consolidate the visible when rules.
• Use expression instead of when rules are much as possible (does not go through rule resolution).

Client visible when avoids round trips to the server when showing or hiding the layout, but this configuration makes the DOM larger.

If you have a large section, you might want to consider using the server-side visible when rule instead of the client-side visible when rule.

This is especially important when using these client-side visible when rules in repeating list because the initial load and rendering of the list is increased.

The Icon Class option can use a property reference. This is a great approach to avoid having different fields using visible when conditions inside the same dynamic layout in order to display different icons based on certain values