Conditional Formatting
Problem
The graph library currently renders all data points with uniform styling regardless of their semantic meaning. There is no way for a dashboard author to declaratively express that a value crossing a threshold should turn red, that an outlier deserves a badge, or that a positive trend should be visually distinct from a negative one. Without conditional formatting primitives, analysts must either accept flat, undifferentiated charts or resort to manual post-processing outside Dataface. This is a key differentiator for KPI storytelling — the ability to encode business logic (thresholds, exceptions, trend states) directly into the visual layer so that charts communicate meaning, not just shape.
Context
- Conditional formatting rules are supported across priority chart/table surfaces.
- Rule precedence and conflict behavior are deterministic and documented.
- Performance and readability remain acceptable on large result sets.
Possible Solutions
- A - Keep styling uniform and require manual data shaping for all emphasis: simplest, but weak for common BI needs.
- B - Recommended: define declarative conditional-formatting rules with bounded targets and deterministic evaluation.
- C - Allow arbitrary custom code to decide formatting at render time: flexible, but outside the desired contract.
Plan
- Define conditional rule syntax and expression capabilities in config.
- Implement styling evaluation in render pipeline with predictable ordering.
- Add test coverage for threshold, banded, and multi-condition rules.
- Validate accessibility/contrast behavior for condition-based styling.
- Document best practices and anti-patterns for dashboard authors.
Implementation Progress
- GitHub issue: https://github.com/fivetran/dataface/issues/48
Review Feedback
- [ ] Review cleared