Filtering logic reference

As a builder, understanding the behaviors of filtering logic across various features helps ensure data consistency and functionality. This reference highlights how filters behave, their differences, and specific case sensitivities.

1. Page component filters (Data table / Data list / Data container)

Use case: Filtering a Data container to display items where “Category contains ‘tech’”.

Behavior:

• Case-insensitive: 'Tech' matches 'tech' and 'TECH'
• Partial matches are valid (e.g., 'technology' matches 'tech')
• Null or undefined values in the “Category” field are ignored

2. Page variables

Scenario: Assigning a variable value dynamically and using it for conditional rendering.

Behavior:

• Equals operator: case-sensitive when comparing string values ('Foo' ≠ 'foo').
• Handling null or undefined: null values often lead to conditional logic defaulting to false, ensuring no unintended data leakage.

Example: Prop value 'Foo' compared with null or "" (empty string) results in false.

3. Condition step (Actions)

Scenario: Using filters in actions for conditional execution.

Behavior:

• Supports static, dynamic, and input variables as operands
• Operators like Equals and Not equals are case-sensitive

Scenario: Filtering records in an action to execute only for items with “Priority greater than 3”.

Behavior:

• Supports numeric comparisons, ensuring precision (e.g., 3.0 equals 3).
• Null or missing priority values are treated as false for the condition.
• Comparison operators like Greater than and Less than are not case-sensitive, as they operate on numeric or date types.

4. Action variables (object & collection)

Scenario: Filtering a collection to find items meeting a condition.

Behavior:

• Operators like Contains and Starts with are case-insensitive.
• Misaligned types (e.g., comparing a string with a number) throw errors.

5. Roles and permissions

Scenario: Allowing access to a dashboard only for users assigned the “Manager” role.

Behavior:

• Role names are case-insensitive, so 'manager', 'Manager', and 'MANAGER' are treated equally.
• Null or undefined role assignments result in access being denied.
• Users with multiple roles are validated against all assigned roles for access.

6. Display logic: Box & Conditional components

Box component

Scenario: Display a component if the property value matches a condition.

Behavior:

• Case-sensitive by default for string comparisons.
• Filters may not display correctly if the string is mismatched in case (e.g., 'Foo' vs. 'foo' returns false).

Conditional display

Use case: Dynamically show or hide components based on user input.

Behavior:

• Follows the Equals operator logic for string sensitivity.
• Supports operators like Starts with, which are case-insensitive.

Key considerations across filters

1. Case sensitivity: Always verify the case requirements of operators used.
2. Null handling: NULL or empty strings are treated differently depending on the component or filter.
3. Operator Differences: Certain operators like Contains might behave differently across features (case-insensitivity in lists but case-sensitivity in actions).

Example scenarios

Example 1: Data table filtering

Filter: Property 'Status' equals 'Active'.

Behavior:

• Data table: Will not show items if the value is 'active' due to case sensitivity.

Example 2: Page variable in Conditional logic

Condition: Variable 'username' equals 'Admin'.

Outcome:

• Matches Admin, but not admin or ADMIN.

Example 3: Display logic

Condition: Display box if 'Title' starts with 'Hello'.

Behavior:

• Case-insensitive for Starts with: Matches 'hello world'.

Pages

Actions

 

This reference serves as a guide to the filtering logic’s nuances, aiding in predictable and accurate implementation within Betty Blocks. For detailed technical nuances, refer to the developer documentation.