Problem
MatchEvent.MinuteText is stored as a raw string all the way through the model layer.
That preserves display fidelity, but it also means sorting and timeline placement have to re-parse minute strings later in the UI layer.
Current behavior
MinuteText carries values like 45+1 and 90+2- render helpers call
minuteSortKey() to recover ordering information from that text
- parsing responsibility is split between site parsing and UI rendering
Why it matters
The site layer should be the boundary where source text becomes normalized domain data. Keeping minute parsing deferred into the UI makes ordering logic easier to duplicate, harder to test, and more coupled to display formatting.
Suggested direction
- keep the original display string if needed, but add structured minute data at the site boundary
- a small value type or parsed pair is enough; this does not need to be elaborate
- move event ordering to structured data instead of reparsing display text in render helpers
Acceptance hints
- event ordering does not require reparsing display text in the UI package
- stoppage time and ordinary minutes sort correctly from structured fields
- parser tests cover minute normalization and ordering behavior
Problem
MatchEvent.MinuteTextis stored as a raw string all the way through the model layer.That preserves display fidelity, but it also means sorting and timeline placement have to re-parse minute strings later in the UI layer.
Current behavior
MinuteTextcarries values like45+1and90+2minuteSortKey()to recover ordering information from that textWhy it matters
The site layer should be the boundary where source text becomes normalized domain data. Keeping minute parsing deferred into the UI makes ordering logic easier to duplicate, harder to test, and more coupled to display formatting.
Suggested direction
Acceptance hints