Refactor Hit struct to be an enum? about genius-rs

[alt-art]

I don't use enums because I have no experience with them, the examples of the enum representation of serde seems disheartening, if you have an example of this I will check.

Genius API supports many types of searches, but they only offer developers a small music search, in a no longer future I will support these types.

[vrobweis]

Without confirming (I am away from a computer at present), a possible representation could look like:

#[derive(Deserialize, Debug)] 
#[serde(tag = "type", content = "result")]
#[non_exhaustive]
pub enum Hit {
    #[serde(alias = "song")]
    Song(Song)
}

This uses serde's support for adjacent tagging to handle possible outcomes. This sample code may not be ideal, as it does remove support for the index value, but by my recollection, that information isn't really something consumers of the crate would use, since they would presumably get whatever results they need in the Vec of Hits. If the index is used for pagination, that's a crate implementation detail.

[alt-art]

Hmm, the way you did it would be possible:

#[derive(Deserialize, Debug)] 
#[serde(tag = "type", content = "result")]
#[serde(tag = "type", content = "album")]
#[non_exhaustive]
pub enum Hit {
    #[serde(alias = "song")]
    Song(Song)
    #[serde(alias = "album")]
    Album(Album)
}

?

[alt-art]

I reviewed the API responses for certain types of search and I think that even, so I will have to write another structure to treat some cases.
See multiple types search, articles search and tiny song search.
The tiny music search will be separated from the others responses.