serialise with the json / valuable features like so:
{"Red": []}
as a full JS object with an empty list, presumably to accommodate potential inner fields for variants that have them. Upstream logging / monitoring platforms have been observed to not play well with this representation, rendering it strangely or deleting it entirely as "empty data".
Serde supports multiple Enum Representations. Indeed, the default is to just render the variant name as-is, as can be seen here:
#[derive(Debug, serde::Serialize)]
enum Colour {
Red,
Green,
Blue,
}
fn main() {
let c = Colour::Red;
let json = serde_json::to_string(&c).unwrap();
println!("{json}");
}
Red
Proposal
It depends on how this representation is viewed. If the current representation is deemed a bug, then the default output could simply be altered in the case of variants that contain no inner fields.
On the other hand, in the spirit of https://github.com/tokio-rs/valuable/pull/75 , this could be considered an opportunity to provide greater control over how enums are represented as JSON.
In the short term, my person vote is for the former, but would like to see the latter implemented eventually as well.
Alternatives
Changing the default representation for the fieldless case may surprise current users who currently depend on it. There's no way to know if anybody currently does, however.
Another alternative would be to return to something that was explicitly avoided in the original announcement, namely general logging support for anything that has serde::Serialize .
Feature Request
Crates
tracing-subscriber
(I think)Motivation
Currently, plain variants of enums like:
serialise with the
json
/valuable
features like so:as a full JS object with an empty list, presumably to accommodate potential inner fields for variants that have them. Upstream logging / monitoring platforms have been observed to not play well with this representation, rendering it strangely or deleting it entirely as "empty data".
Serde supports multiple Enum Representations. Indeed, the default is to just render the variant name as-is, as can be seen here:
Proposal
It depends on how this representation is viewed. If the current representation is deemed a bug, then the default output could simply be altered in the case of variants that contain no inner fields.
On the other hand, in the spirit of https://github.com/tokio-rs/valuable/pull/75 , this could be considered an opportunity to provide greater control over how enums are represented as JSON.
In the short term, my person vote is for the former, but would like to see the latter implemented eventually as well.
Alternatives
Changing the default representation for the fieldless case may surprise current users who currently depend on it. There's no way to know if anybody currently does, however.
Another alternative would be to return to something that was explicitly avoided in the original announcement, namely general logging support for anything that has
serde::Serialize
.