Feedback and related subtypes don't derive deserialise

[Firstyear]

Hi!

I was trying to use this library and noticed that when I add it to a type that has Serialise and Deserialise an error is raised:

#[derive(Serialize, Deserialize)]
struct MyStruct {
    fb: Feedback
}

...

error[E0277]: the trait bound `zxcvbn::feedback::Feedback: v1::_IMPL_DESERIALIZE_FOR_SchemaError::_serde::Deserialize<'_>` is not satisfied
  --> kanidm_proto/src/v1.rs:61:21
   |
61 |     InvalidPassword(feedback::Feedback),
   |                     ^^^^^^^^ the trait `v1::_IMPL_DESERIALIZE_FOR_SchemaError::_serde::Deserialize<'_>` is not implemented for `zxcvbn::feedback::Feedback`
   |
   = note: required by `v1::_IMPL_DESERIALIZE_FOR_SchemaError::_serde::de::VariantAccess::newtype_variant`

I'm wondering if perhaps you are missing:

#[cfg_attr(feature = "ser", derive(Serialize, Deserialize))]

On the Feedback and related child types.

Thanks!

[Firstyear]

Sorry, should mention: I'm using 2.0.0.

[shssoichiro]

The Serialize trait is implemented, but not Deserialize. This was intentional--I didn't see a use case for needing to deserialize the data types, since the data structures from zxcvbn are very much "output-only" in design.

Do you have a use case where deserializing these types from a JSON string would be helpful?

[Firstyear]

So I'll explain what I'm doing and maybe that will help provide a use case or you can suggest better what I can do. I'm implementing an IDM server in Rust and the client communicates to the http server via json. This means there is a native client at both ends. My intent is that in one of the Error cases for InvalidPassword IE zxcvbn considers it's score too low, that we return a type of:

Error::InvalidPassword(Feedback)

So "on the wire" this would be json to the client, but the client would then re-create this to native types.

The major thought behind this is the client then can access your Feedback formatter to get your messages rather than inventing my own. It prevents sending text blobs in the response. And the best benefit is that when I implement internationalisation, I can then have a localised translation of each feedback in my client that we can pattern match on (rather than having to create my own enum of all possible warning/feedbacks).

This way the json is a "protocol" rather than "human readable" and it's up to the client to transform this as required to gain human messages.

Is that a reasonable line of thought here?

Thanks!

PS: Thanks for the awesome library, I'm very impressed by how it works.

Edit: missed a point re enum.

[sbking]

@shssoichiro Any chance you'd consider this again?

Use case: Writing an isomorphic web app with Leptos, running Rust on both the server and the browser with WASM. As long as a type implements both Serialize and Deserialize, it can be sent across the wire as server function arguments and/or results. I want to send Feedback to the browser and then deserialize it as a Feedback so I can render it with match for i18n.