Renderings (@r) are discarded

[nightkr]

According to the documentation you can send a @r property to override how holes are rendered in the message. However, this seems to be ignored silently, both when the hole has an invalid name, and when the hole has a valid but missing name. The @r field is not even preserved in the "download raw JSON" option.

Is this intended? Is the documentation a leftover from the upstream CLEF documentation? Is there validation that ensures that renderings are only used iff Seq is able to render the field anyway? Is there any way to refer to a subfield from the template?

[nblumhardt]

Hi Teo, thanks for getting in touch.

The @r field is only consulted/will only be preserved when properties in the message template include custom format specifiers.

So, if the template is:

"Counter is {N}"

then no @r property should be sent (it will be ignored).

If the template is:

Counter is {N:000}

then an @r property containing an array with a rendering for N will be accepted/consulted.

Does this match the behavior you're observing?

Best regards,
Nick

[nightkr]

Oh, I see. So there is essentially no way to emulate #1100 from the API client?

[nblumhardt]

Thanks for the pointer back to that ticket; it's done! 🎉 We're shipping the feature in 2021.3, but haven't had a chance to raise an issue in the milestone (will do so now).

Unfortunately, no - renderings don't provide a workaround for 2021.2 or earlier.

[nightkr]

Woo!