Support wrapping with a different type

[cshaa]

This is a really handy crate! However, it would be even better if it allowed me to wrap the fields not only in Option<...> but also in my own custom type. My specific use case is that I'm implementing styling support for our WebAssembly plotting library – and the styles can either have some specific value, or be None (which means "do not change") or Unset (which means "reset to default").

This is my code without using optfield:

#[derive(Serialize, Deserialize, Default)]
#[serde(rename_all = "kebab-case")]
pub enum OrUnset<T> {
    #[default]
    Unset,
    #[serde(untagged)]
    Set(T),
}

#[derive(Clone, Tsify, Serialize, Deserialize)]
#[tsify(into_wasm_abi, from_wasm_abi)]
#[serde(rename_all = "kebab-case")]
pub struct ComputedTraceStyle {
    pub color: TraceColor,
    pub points: TracePointsStyle,
    pub line: TraceLineStyle,
    pub line_width: u32,
    pub palette_index: TracePaletteIndex,
    pub z_index: f64,
    pub legend_priority: f64,
}

#[derive(Clone, Tsify, Serialize, Deserialize)]
#[tsify(into_wasm_abi, from_wasm_abi)]
#[serde(rename_all = "kebab-case")]
pub struct TraceStyle {
    pub color: OrUnset<TraceColor>,
    pub points: OrUnset<TracePointsStyle>,
    pub line: OrUnset<TraceLineStyle>,
    pub line_width: OrUnset<u32>,
    pub palette_index: OrUnset<TracePaletteIndex>,
    pub z_index: OrUnset<f64>,
    pub legend_priority: OrUnset<f64>,
}

#[derive(Clone, Tsify, Serialize, Deserialize)]
#[tsify(into_wasm_abi, from_wasm_abi)]
#[serde(rename_all = "kebab-case")]
pub struct TraceStylePatch {
    #[tsify(optional)]
    pub color: Option<OrUnset<TraceColor>>,
    #[tsify(optional)]
    pub points: Option<OrUnset<TracePointsStyle>>,
    #[tsify(optional)]
    pub line: Option<OrUnset<TraceLineStyle>>,
    #[tsify(optional)]
    pub line_width: Option<OrUnset<u32>>,
    #[tsify(optional)]
    pub palette_index: Option<OrUnset<TracePaletteIndex>>,
    #[tsify(optional)]
    pub z_index: Option<OrUnset<f64>>,
    #[tsify(optional)]
    pub legend_priority: Option<OrUnset<f64>>,
}

impl TraceStyle {
    pub fn compute(&self) -> ComputedTraceStyle {
        ComputedTraceStyle {
            color: self.color.or_default(),
            points: self.points.or_default(),
            line: self.line.or_default(),
            line_width: self.line_width.set_or(2),
            palette_index: self.palette_index.or_default(),
            z_index: self.z_index.or_default(),
            legend_priority: self.legend_priority.or_default(),
        }
    }

    pub fn patch(&self, patch: TraceStylePatch) -> TraceStyle {
        TraceStyle {
            color: patch.color.unwrap_or(self.color.clone()),
            points: patch.points.unwrap_or(self.points),
            line: patch.line.unwrap_or(self.line),
            line_width: patch.line_width.unwrap_or(self.line_width),
            palette_index: patch.palette_index.unwrap_or(self.palette_index),
            z_index: patch.z_index.unwrap_or(self.z_index),
            legend_priority: patch.legend_priority.unwrap_or(self.legend_priority),
        }
    }
}

With optfield, I can replace the code for TraceStylePatch and TraceStyle::patch with:

#[optfield(
    pub TraceStylePatch,
    attrs,
    field_attrs = add(tsify(optional)),
    merge_fn = patch_mut
)]
...
pub struct TraceStyle {
...
impl TraceStyle {
    pub fn patch(&self, patch: TraceStylePatch) -> TraceStyle {
        let mut patched = self.clone();
        patched.patch_mut(patch);
        patched
    }
}

However, TraceStyle and ComputedTraceStyle still have to remain duplicated.

[roignpar]

Thank you for the suggestion. This would be a nice addition. However it would make some features of optfield basically impossible to implement without requiring more information about the wrapper type: merge_fn and from.
An option would be to add a wrapper argument taking the type to use instead of Option and disable merge_fn and from when it is used.
I may look into it when I have the time, but would also gladly assist and review a PR.

[roignpar]

I started working on this: #9
Please provide any feedback in the PR. Thank you!