pub fn render_diagnostics<'a>(
pairs: impl IntoIterator<Item = (&'a str, &'a str)>,
) -> StringExpand description
Render a set of field-level diagnostics as one user-facing message.
The single renderer for validation refusals. Both validation services use
it, so tix link and tix parent set report refusals in the same format and a
user who learned one does not have to learn the other. It lives here rather
than in either service because neither owns the other’s diagnostics, and a
second copy of this loop is how the two formats drift apart.
Takes (kind, message) pairs rather than either service’s diagnostic type, so
this module needs to know nothing about relationships or hierarchy.
Three properties, each of which a service message made necessary:
- Every diagnostic is reported, not just the first. A rejection can carry several, and showing one at a time makes a user fix and retry repeatedly to discover the rest.
- The kind is prefixed unless the message already names it. Several service
messages do (
cycle: 1 -> 2 -> 1), and prefixing unconditionally produced the doubled, stutteringcycle: cycle: .... - Duplicates are collapsed. A self-link is reported by the self-link rule and again by the cycle rule, so without this the most common rejection printed the identical sentence twice. Collapsing is presentation, and leaves the diagnostic set the service produced intact for any other consumer.
- The separator is
|rather than;because service messages contain;themselves, which made the rendered text ambiguous about where one diagnostic ended and the next began.