Building a Stat Comparator That Refuses Invalid Deltas

When creating a comparison table that involves various types of stat values, it is important to avoid producing misleading results from values that cannot be directly compared. During the implementation of a Gear comparison view, an initial approach was to join rows based on visible labels and subtract right values from left. However, this method would allow a flat Attack Damage value to collide with an Attack Damage percentage, and it would wrongly treat missing values as zero.

To address these issues, a safer implementation was adopted using a small Map keyed by three pieces of semantic identity. The comparison result is modeled explicitly through a ComparisonRow interface, which includes fields such as key, label, source, unit, left, right, and delta. The source distinguishes between equipment baseline and attached modifiers, while the unit prevents visually similar values from being treated as interchangeable.

Null represents an unavailable published value instead of a measured zero. Those fields form the core of the comparison contract. If they are discarded before the UI layer, the original meaning cannot be recovered, regardless of how carefully the table is formatted.

To group rows properly, a semantic composite key is used, which takes the form of ` ${ source } : ${ stat . key } : ${ stat . unit } ` . This key ensures that only rows with identical stat identity, source, and unit are placed in the same comparison bucket. Even if interface labels share words, the composite key guarantees that rows answering different questions are placed separately.

This pattern is applicable in various scenarios beyond games, such as pricing tiers with monthly and annual amounts, analytics with counts and rates, and hardware with nominal and measured values. When accumulating values from both sides, the implementation walks through the projections and fills the same row map. The ?? 0 operator is used only if a stat entry is known to exist on that side, allowing for multiple normalized entries in the same semantic bucket without globally treating an absent side as zero.

This distinction is crucial, as there is a significant difference between a bucket containing entries that total zero and a release lacking that specific bucket. The delta calculation is intentionally straightforward, only being computed when both sides exist. If either value is unavailable, the delta is also marked as unavailable.

The formatter receives the unit from the row, rather than guessing it based on the label, ensuring accurate formatting according to the unit.