Rules That Fight Each Other
A loan application Adaptive Form has three interacting behaviors: (a) a visibility rule hides the co-applicant panel unless marital status is Married; (b) a calculate script sums incomes only when the co-applicant panel is visible; (c) a validate script on the co-applicant income field requires a value when the panel is visible. Testers find that changing marital status from Married to Single leaves the co-applicant income in the total, and that submitting sometimes throws a validation error for a hidden field. A developer proposes fixing it by adding a fourth rule that clears the co-applicant fields on change. A separate developer wants to move the logic into a custom client library component for performance.
1. Explain the ordering/execution problem behind the stale total and the hidden-field validation error.
Read the worked answer
The symptoms come from rule execution order and the visibility/validation dependency, not from missing rules.
- When marital status changes to Single, the visibility rule hides the panel, but the calculate rule's condition ("panel visible") and the total are evaluated in an order that can read the pre-hide state, or the calculate does not re-run after visibility changes. Result: the co-applicant income remains in the total.
- The hidden-field validation error means the validate rule evaluates the field's value even when the panel is hidden, or runs before the visibility rule has settled. A field that is hidden but still required will fail validation on submit.
This is a classic dependency-chain bug: visibility, calculation, and validation are coupled, and the form's rule engine does not guarantee the order the developer assumed.
2. Evaluate the 'add a fourth rule to clear fields' fix versus restructuring, and evaluate the custom-component proposal.
Read the worked answer
Fourth rule (clear on change): It treats a symptom. It can work only if it reliably runs before the calculate and after visibility, which is exactly the ordering that is already unreliable. Adding rules increases the coupling and the chance of a race. It also does not fix the hidden-field validation, because the field can still be validated while hidden. Reject as the primary fix.
Restructure instead:
- Make the calculate condition depend on the value of marital status (or an explicit flag), not on inferred visibility, so the total is correct regardless of render timing.
- Make validation conditional on the same explicit flag so a hidden field is not required. Do not rely on visibility to suppress validation.
- Clear subordinate fields as part of the state transition (single source of truth for "co-applicant active"), so there is one place that governs all three behaviors.
Custom client library component: Moving logic to a custom component can improve performance for heavy computation, but it does not by itself fix ordering; it can make it harder to reason about because logic is now split between declarative rules and imperative code. Only justify it if profiling shows the rule engine is the bottleneck - not as a fix for a correctness bug.