Conditional logic

Digital experiences are not one-size-fits-all. Content or layout might need to adapt or change based on many criteria such as market or locale specific content, presence or absence or values of data from external systems, device or browser specific context, or even session or user specific data.

With Uniform, you can create adaptive experiences that allow you to tailor how content is displayed based on a variety of conditions. This guide will help you understand how to apply conditional logic in your compositions, entries and patterns.

Conditional logic can be applied on different levels:

• On a component level using Component visibility control
• On a property level using Conditional values

Common use cases for conditional logic#

By using conditional logic in Uniform, you can create adaptive experiences without having to write any code to handle your business or display logic for adapting content and layout. By moving this logic into the composition, you can empower non-technical users to build more sophisticated experiences while being less reliant on developers to make changes to logic-driven content and layout.

Component visibility control and conditional values are powerful features that can be used and combined to support a wide range of use cases. When they were originally built, the common use cases mentioned below were envisioned but we frequently learn about creative usages of these features.

Localize content#

Create conditional rules to adapt content based on the user's location, using either the current locale or geographic data from a GeoIP quirk. This allows you to customize experiences such as product offerings, pricing, and shipping information to match the visitor's country or region or cultural preferences.

Adjust dynamic content based on values from external data or URLs#

Conditional values and component visibility control offer powerful ways to add more flexibility to dynamic compositions. These features allow you to modify content according to values retrieved from external systems or dynamic routes.

For example:

• Display targeted promotion banners for specific product categories or query string parameters
• Adjust content visibility or property values based on the presence or absence of data from an external system
• Render different components inside of a loop component based on the type of content or data.

Adapt to device, browser or session specific context#

Conditional values can be used to respond to quirk values that are set in the front end, such as device types, viewport sizes, or session data. For instance, you could adjust the layout for different orientations on tablet devices, optimize content based on the user's connection speed, or modify the content based on the detected operating system. It can also take into account any session data that is available in the front end like log-in status, user preferences or data coming from a customer data platform (CDP).

Light-weight contextual personalization#

Often you want to adapt content to create personalized experiences for your users based on their current context or to react to data that is being consumed. The goal of such light-weight personalization is less about conversion optimization and more about creating an improved and consistent user experience.

Conditions#

You can apply conditional logic to components and entries using conditions. Conditions are boolean expressions that must evaluate to true or false. A condition consists of a left-hand side (LHS) criteria and a right-hand side (RHS) criteria separated by a comparison operator.

Multiple conditions can be combined into a condition set using an AND operator. Therefore the result of a condition set is true if all conditions in the set are true. It is false if any condition in the set is false.

Anatomy of a condition

Condition criteria#

The left-hand side (LHS) criteria of a condition is used to specify the criteria that must be met for the condition to be true. The right-hand side (RHS) criteria is used to specify the value that the LHS criteria must be compared to. Depending on the type of the LHS criteria, different comparison operators are available.

Following are the different types of LHS criteria that can be used in conditions:

• Locales
• Dynamic inputs
• Quirks
• Dynamic tokens

Locales#

The current locale being rendered may be used as a condition. It supports a plethora of comparison operators such as "is," "is one of," "does not start with," and more. With a locale condition you can realize scenarios such as "where the current locale is one of en-US, de-DE, zh-CN" to show components to specific locales or regions.

The following table lists the available operators for locale conditions:

Dynamic inputs#

Dynamic inputs from dynamic project map path segments or allowed query string values can be used as conditions for string comparisons. The current composition must be connected to a project map node that either is a dynamic node itself or has a dynamic node in its parent nodes.

The following table lists the available operators for dynamic input conditions:

Quirks#

Quirks from a visitor's classification may be used as conditions. Quirks live in the client-side, so these are evaluated later than other conditions. Quirk conditions enable scenarios such as displaying content based on customer attributes or ambient criteria such as viewport width. When a quirk has a specific set of options, those are available to choose from when designing conditions based on the quirk.

The following table lists the available operators for quirk conditions:

Dynamic Tokens#

Dynamic tokens can be used in conditions to compare against other dynamic tokens or static values.

They can be placed both in the LHS and RHS criteria. On the left-hand side, only one dynamic token can be used. On the right hand side, multiple dynamic tokens can be used and combined with any static string values.

The following table lists the available operators for dynamic token conditions:

Progressive evaluation of conditions#

Uniform intelligently evaluates conditional expressions when you make API requests:

• If a locale is resolved, via a locale node in project map or an explicit locale parameter, all locale expressions are evaluated (by the route API, composition API, or entry API).
• Dynamic input expressions are always evaluated by the route API.
• Dynamic token expressions are evaluated by default by all APIs unless skipDataResolution: true is passed.

When a criteria is evaluated, the result of the overall expression is checked. If an expression is always true or false after evaluating the criteria that are known to Uniform's API, we eliminate the conditional value definition and replace the default value with the resolved conditional value.

For example, with a condition like "where the query string utm_campaign is halloween", and you pass a route such as /en-US/home?utm_campaign=halloween to the route API, you will not receive a conditional value definition back: you will receive the matching conditional value as the value. In this example, it is the conditional value defined for the "where the query string utm_campaign is halloween" condition.

Client-side evaluation of conditions#

Progressive evaluation is important to understand when it comes to client-evaluated rules such as quirks. Because quirks only exist on the client side, conditional expressions based on quirks always are returned from the Uniform APIs so we can progressively evaluate the quirk expression on the client side.

The Uniform SDKs will automatically run quirk rules for you by default, but if you fetch data from the REST APIs directly, you may need to run evaluation manually. This is easy to accomplish using the following functions exported from @uniformdev/canvas:

Learn how to apply conditional logic#