Display Logic

Using conditional rendering, enabling, styling, and opening, Skuid’s display logic feature allows page builders to control component and/or component element style, as well as how—and when—data is displayed to end users.

  • With conditional rendering, criteria must be met for the component or element to display (or render), otherwise it is hidden.
  • Conditional enabling displays a feature (such as a button), but disables it until the designated conditions are met.
  • With conditional styling, criteria must be met for the component or element’s visual styling to change.
  • Conditional opening determines whether a component feature will load in an open or closed state.

Types of Display Logic

Imagine an app that gives members of a customer success team access to information about their accounts.

Use conditional rendering to:

  • Hide components until they are needed by the user, to make the desired workflow obvious.
  • Display (or hide) data based on the user’s privileges.
  • Step the user through a workflow, providing just-in-time information as they progress.

A few examples:

  • If the account’s contact prefers email, phone fields are not displayed. This means the rep can’t mistakenly phone the customer when an email is more welcome.
  • If the account type is “partner,” the app displays a partner information tab in a Tab Set.
  • If the end user is a manager, the page includes the account profitability table. (If the end user is not a manager, the table isn’t displayed.)

On the other hand, conditional enabling might be used to display a button that is greyed out until the user performs certain actions.

Use conditional styling to:

  • Change form fields to green after they’ve been correctly filled out.
  • Visually show a change in app state.
  • Highlight a button once it is conditionally enabled.

Conditional opening can be used to display an Accordion component with specific sections open (or closed) upon page load.

Using Display Logic

All types of display logic rely on established conditions: criteria that determine whether or not the component or element displays (or is activated) so that end users can interact with it.

Configure a render condition on a component or element

Start with a page that has components attached to a working model.

  • Select the component (or element) you want conditionally render.
  • Determine the Render if… criteria.
  • Click add Add new render condition to create one (or more) conditions that Skuid will evaluate to determine whether or not to render the component.
    • Configure each condition, starting with the Source type, which determines which other properties are available for the condition.

Selecting the source type

There are a number of different Source types (the type of value or property the condition evaluates) to choose from. How do you choose the one that’s best for your needs?

  • If the rendering/enabling is driven by data—specific criteria in the data model—the Model field value, Model property, or Row property are good places to start.
  • If the rendering/enabling is driven by user privileges— some users can see the content, others cannot—build the condition on Running user attribute, Running user has permission, or Data source user attribute.
  • If the rendering/enabling is driven by changes in the page environment—choices that the end user makes on the page—try Model or Row property.

Configure an enable condition on a component element [[]]

The process for creating an enable condition is identical to that for creating a render condition: click the field or button you want to conditionally enable, select the Enable if … criteria, and configure the desired condition (or conditions).

Configure a select condition on a Navigation component [[]]

Start with a page that has a Navigation component attached to a working model. Click the navigation item you want to conditionally select. From there, the process is identical to creating a render condition.

Configure a style variant condition on a component or element [[]]

Start with a page that has components attached to a working model.

  • Select the component or element you want conditionally style.
  • Navigate to the Display logic tab and select Style variant conditions.
  • Click add Add new rule to create one (or more) condition rules that will determine which style variant to apply and what logic apply to the condition rules.
  • Then within that rule, click add Add a new condition to create one (or more) conditions that will determine whether or not to render the alternate style variant for that component or element.
  • Configure each condition, starting with the Source type, which determines which other properties are available for the condition.

Configure an open condition on an Accordion component [[]]

Start with a page that has an Accordion component attached to a working model. This component has:

  • In the General tab, set Sections initially open to Determine by section.
  • In the Accordion, select the section you want conditionally open. Set its Initial state to Determined by Open Condition.

Now, set the condition in the Display tab:

  • Determine the Open if … criteria.

  • Click add Add new open condition to create one (or more) condition rules that Skuid will evaluate to determine whether or not to open the section.

    • Configure each condition, starting with the Source type, which determines which other properties are available for the condition.

Best Practices When Using Display Logic

  • Conditional rendering is a valuable tool to limit what is displayed to different user profiles, but it’s not a substitute for strong security settings.
  • Be clear about the reason to hide or disable the feature. What’s the benefit? What are the downsides? Are you helping the users—or just irritating them? Be sure to write an informative Message to show when disabled to help guide the user.
  • Note if the values for your conditions are too narrow in scope, there will be few situation where the elements will render or enable. This may result in hiding/disabling too many things on the page.
  • Some elements (for example, Buttons and Fields) can be conditionally rendered or conditionally enabled. How do you decide which is the better option?
    • Would it be best for the end user if the element was hidden and only appeared as needed? If an element would only serve to distract a user from an intended experience or workflow, conditionally render it.
    • Would it be more helpful if the user could see the element—but not access it—letting the element’s disabled presence serve as a reminder for what needs to be completed in the workflow? Conditionally enable it.
  • Limit the number of render/enable conditions on a page. Too many conditions make the page:
    • too complicated for the user
    • too complex to maintain
    • too slow to load
  • If the Source type for the condition requires a source model, make sure to select the correct one.
  • Using conditional rendering on a button that’s part of an Ink button group? Don’t conditionally render the primary action button for that group—this may create a confusing user experience.
  • Be clear about the hierarchy of your conditional style rules. If a component–or one of its elements–has multiple style conditions, the conditions will be evaluated in the order in which they are created. The first condition that returns as true will be applied, as well as terminate the evaluation, even if more conditions remain.

Properties

The following options are found in the Display logic tab.

Render conditions [[]]

These conditions govern when an element or component will display.

  • Render if…: The conditions that must be met to enable the element’s display.

    • ALL conditions are met
    • ANY conditions are met
    • Custom logic is met
      • Condition logic: The custom logic for grouping and applying one or more conditions.
  • If hidden, model field changes should be: (only available on Field rendering tabs) If the field is hidden by conditional rendering, this property determines whether any changes made to this field (via Action Framework or JavaScript) are saved in the model, or canceled.

    Note

    Depending on the needs of your org, it could be bad user experience to update fields without direct user input especially when that user may be unaware of they are doing so.

    • Retained in model (the default)
    • Cancelled

Enable conditions [[]]

These conditions govern when a displayed element may or may not be enabled for use.

  • Enable if…: The model conditions that must be met to enable the field’s editing.
    • ALL conditions are met
    • ANY conditions are met
    • Custom logic is met
      • Condition logic: The custom logic for grouping and applying one or more conditions.
  • Message to show when disabled: A brief explanation for why the field is disabled.

Selected conditions [[]]

These conditions govern when a navigation item displays with “selected” styling.

  • Display as selected if…: The model conditions that must be met to style the navigation item.

    • All Conditions are met
    • ANY Conditions are met
    • Custom Logic is met
      • Condition Logic: The custom logic for grouping and applying one or more conditions.

Style variant conditions [[]]

These conditions govern which style variant is applied and displayed on a component or element.

Note

You can create one, or more, style variant conditions and set each individually.

  • Click add Add a new condition to add a new style variant condition.
  • Then, click the new style variant condition and configure.

When Skuid executes the display logic, the style variant conditions are evaluated in order.

  • Use this Style Variant if…: The model conditions that must be met to enable the styling.

    • ALL conditions are met
    • ANY conditions are met
    • Custom logic is met
      • Condition logic: The custom logic for grouping and applying one or more conditions.
    • Style variant: The style variant to be rendered if condition(s) are met.

Open conditions [[]]

These conditions govern if a component section will be open or closed at page load.

  • Open if…: The model conditions that must be met to enable the field’s editing.

    • ALL conditions are met
    • ANY conditions are met
    • Custom logic is met
      • Condition logic: The custom logic for grouping and applying one or more conditions.

For all conditions [[]]

Click either:

  • add Add new render condition
  • add Add new enable condition
  • add Add new selected condition
  • add Add new open condition
  • add Add Child and then Add a new condition.

Then customize:

  • Source type: The value or property being evaluated to determine whether an element is conditional rendered/enabled.

    • Model field value: The condition evaluates a value located in a model field.

      • Source model: The model where the specified field is located

      • If no rows in model: Determines what happens if the model is empty.

        • Ignore this condition: (Default) Ignores this condition (assumes it to be true) but evaluates any following conditions.
        • Skip other conditions, and render/enable/use this style variant: No conditions are evaluated; the element renders/enables/is styled.
        • Skip other conditions and don’t render/enable/use this style variant: No conditions are evaluated; the feature doesn’t render/is not styled .
      • Field: The field in the model to be evaluated.

      • Operator: Standard Skuid operators are available.

      • Content:

        • Single specified value

          • Value: The value that triggers the condition.
        • Multiple specified values

          • Values: Values that trigger the condition.
        • Page/URL parameter value

          • Parameter: The page or URL parameter the field must equal to trigger the condition.
        • Skuid user attribute

          • Skuid user attribute: The user attribute that triggers the condition.
        • None - blank value

        • Result of a formula

          • Formula: The formula that triggers the condition, if evaluated to be true.
    • Model property: The condition evaluates a property of the model.

      • Source model: The specified model.
      • Model Property: The model property that triggers the condition:
        • # of rows in model
        • Doesn’t have data rows
        • Has data rows (default)
        • Has unsaved changes
        • Model label
        • Model plural label
    • Row property: The condition evaluates a property of a row on the model.

      • Source model: The specified model.
      • Row property: The property of the row that triggers the condition:
        • Has unsaved changes
        • Is new record (default)
        • Is existing record in database (default)
        • Is unsaved clone of existing record (default)
        • Is marked for deletion (default)
    • Page/URL parameter value: The condition evaluates a page or URL parameter.

      • Parameter name: The specific parameter.

      • Operator: Standard Skuid operators are available.

      • Content:

        • Single specified value

          • Value: The value that triggers the condition.
        • Multiple specified values

          • Values: Values that trigger the condition.
        • Page/URL parameter value

          • Parameter: The page or URL parameter that triggers the condition.
        • Skuid user attribute

          • Skuid user attribute: The user attribute that triggers the condition.
        • None - blank value

        • Result of a formula

          • Formula: The formula that triggers the condition, if evaluated to be true.
    • Running user attribute: The condition evaluates a user attribute.

      • User attribute: The specific user attribute.

      • Operator: Standard Skuid operators are available.

      • Content:

        • Single specified value

          • Value: The value that triggers the condition.
        • Multiple specified values

          • Values: Values that trigger the condition.
        • Page/URL parameter value

          • Parameter: The page or URL parameter the attribute must equal to trigger the condition.
        • Skuid user attribute

          • Skuid user attribute: The user attribute that triggers the condition.
        • None - blank value

        • Result of a formula

          • Formula: The formula that triggers the condition, if evaluated to be true.
    • Snippet returns true: The condition runs a JavaScript snippet. If the snippet runs, and returns a result of True, the condition renders.

      • Snippet name: The name of the snippet.
    • Viewport width: The condition evaluates the size of the page’s visible area.

      • Operator: Standard Skuid operators are available.
      • Viewport width: The specific size of the visible area.

      Note

      The viewport varies with the device, and is smaller on a mobile phone than on a computer screen. This property allows the builder to modify the user experience if the visible screen area is inherently smaller than that on a computer monitor.

    • Data source user attribute: The condition evaluates an attribute of the user’s account within the specified data source.

      • Data source: The data source to use.
      • Data source user attribute: The attribute of the data source that triggers the condition. Choose from:
        • User ID
        • Organization ID
        • Business Unit ID
        • Roles Names
        • Role IDs
      • Operator: Standard Skuid operators are available.
      • Content:
        • Single specified value
          • Value: The value that triggers the condition.
        • Multiple specified values
          • Values: Values that trigger the condition.
        • Page/URL parameter value
          • Parameter: The page or URL parameter the attribute must equal to trigger the condition.
        • Skuid user attribute
          • Skuid user attribute: The user attribute that triggers the condition.
        • None - blank value