Serde on the Builder?

[rdong8]

Is there a way we can serialize/deserialize the builder of a struct?

[Veetaha]

Hi, today it's possible only to derive Debug and Clone on the builder itself using #[builder(derive(...)]. Serde traits aren't supported on the builder (yet?😳).

Could you elaborate a bit more on your use case. I.e. what builder syntax origin are you using (struct, function, associated method), and why would you like to have serde traits derived for the builder (how will this then be used?).

I'd like to understand the problem domain on a specific example. Maybe it indeed makes sense to support serde derives on the builder, or maybe not, I just need a bit more context about your specific use case.

[rdong8]

Hey, the use case is for state management with the Teloxide library to build Telegram bots. On each message, the bot parses the text and updates the state enum to another variant (like a FSM).

Without Bon, it would look something like this:

First way

use serde::{Deserialize, Serialize};

enum OrderState {
    ReceiveItemId,
    ReceiveFullName {
        item_id: ItemId,
    },
    ReceiveAddress {
        item_id: ItemId,
        full_name: Name,
    },
    ReceiveCreditCardNumber {
        item_id: ItemId,
        full_name: Name,
        address: Address,
    },
    ReceiveCreditCardPin {
        item_id: ItemId,
        full_name: Name,
        address: Address,
        card_number: CardNumber,
    },
    ConfirmOrder {
        item_id: ItemId,
        full_name: Name,
        address: Address,
        card_number: CardNumber,
        card_pin: CardPin,
    },
}

fn update_state(message: String, state: OrderState) -> OrderState {
    match state {
        OrderState::ReceiveItemId => OrderState::ReceiveFullName {
            item_id: message.parse(),
        },
        OrderState::ReceiveFullName { item_id } => OrderState::ReceiveAddress {
            item_id,
            full_name: message.parse(),
        },
        OrderState::ReceiveAddress { item_id, full_name } => OrderState::ReceiveCardNumber {
            item_id,
            full_name,
            address: message.parse(),
        },
        // ...etc
    }
}

Second way

struct OrderBuilder {
    item_id: Option<ItemId>,
    full_name: Option<Name>,
    address: Option<Address>,
    card_number: Option<CardNumber>,
    card_pin: Option<CardPin>,
}

enum OrderState {
    ReceiveItemId,
    ReceiveFullName,
    ReceiveAddress,
    ReceiveCreditCardNumber,
    ReceiveCreditCardPin,
    ConfirmOrder,
}

fn update_state(message: String, state: OrderState, order: OrderBuilder) -> (OrderState, OrderBuilder) {
    match state {
        OrderState::ReceiveItemId => (
            OrderState::ReceiveFullName,
            OrderBuilder{item_id: Some(message.parse()), ..order},
        ),
        OrderState::ReceiveFullName => (
            OrderState::ReceiveAddress,
            OrderBuilder{full_name: Some(message.parse()), ..order},
        ),
        OrderState::ReceiveAddress => (
            OrderState::ReceiveCardNumber,
            OrderBuilder{address: Some(message.parse()), ..order},
        ),
        // ...etc
    }
}

With Bon it would look like this:

#[derive(Builder)]
struct Order {
    item_id: ItemId,
    full_name: Name,
    address: Address,
    card_number: CardNumber,
    card_pin: CardPin,
}

enum OrderState {
    ReceiveItemId,
    ReceiveFullName,
    ReceiveAddress,
    ReceiveCreditCardNumber,
    ReceiveCreditCardPin,
    ConfirmOrder,
}

fn update_state(message: String, state: OrderState, order: OrderBuilder) -> (OrderState, OrderBuilder) {
    match state {
        OrderState::ReceiveItemId => (
            OrderState::ReceiveFullName,
            order.item_id(message.parse()),
        ),
        OrderState::ReceiveFullName => (
            OrderState::ReceiveAddress,
            order.full_name(message.parse()),
        ),
        OrderState::ReceiveAddress => (
            OrderState::ReceiveCardNumber,
            order.address(message.parse()),
        ),
        // ...etc
    }
}

However this wouldn't actually compile because Teloxide stores the state in a database between messages, but the builder that Bon generates cannot be serialized.

I'm now realizing that Bon implements each builder as a different type so I guess this would not work either way though.

[rdong8]

Perhaps Bon could add a type erased builder that just stores all the variants of the builder in an enum? Not 100% sure how it would work.

[Veetaha]

Yeah, I don't think bon fits this use case, because here you have a complex dynamic type state that should be represented manually.

I can suggest a couple of alternative approaches.

An improved "Second way" approach. In this case we don't need an enum of state. The order builder with Option fields already delivers enough state info:

struct OrderBuilder {
    item_id: Option<ItemId>,
    full_name: Option<Name>,
    address: Option<Address>,
    card_number: Option<CardNumber>,
    card_pin: Option<CardPin>,
}


fn update_state(message: String, mut order: OrderBuilder) -> Result<OrderBuilder> {
    match order {
        OrderBuilder { item_id: None, .. } => order.item_id = Some(message.parse()),

        // When we are in this branch we know `item_id` was `Some(_)`, so it's time to get the full name
        OrderBuilder { full_name: None, .. } => order.full_name = Some(message.parse()),

		// Similar thing, here we know that both `item_id` and `full_name` are `Some(_)` already.
		// Any subsequent match arm requires previous arms not to match, and we can use that
		// feature of Rust's match
        OrderBuilder { address: None, .. } => order.address = Some(message.parse()),
        OrderBuilder { card_number: None, .. } => order.card_number = Some(message.parse()),
        OrderBuilder { card_pin: None, .. } => order.card_pin = Some(message.parse()),
        _ => {
            // Handle invalid state. Return an error
            anyhow::bail!("Invalid state, all fields are `Some(_)` already 👮")
        }
    }

    let OrderBuilder {
        item_id: Some(item_id),
        full_name: Some(full_name),
        address: Some(address),
        card_number: Some(card_number),
        card_pin: Some(card_pin),
    } = order else {
        // We are not in a terminal state yet, continue state transitions
        return Ok(order);
    }
    // handle the terminal state
}

The other approach with more type safety is with state composition. Every next state contains the previous state as a field, this way there is less repetition. You can optionally use some macro like from_variants::FromVariants to automatically generate From<Variant> implementations for your state enum and avoid manually wrapping the states in an enum using into instead.

#[derive(Serialize, Deserialize)]
struct ItemIdReceived {
    item_id: ItemId,
}

#[derive(Serialize, Deserialize)]
struct FullNameReceived {
    #[serde(flatten)] // optional to make the output more flat
    prev: ItemIdReceived,
    full_name: Name,
}

#[derive(Serialize, Deserialize)]
struct AddressReceived {
    #[serde(flatten)] // optional to make the output more flat
    prev: FullNameReceived,
    address: Address,
}

// ...etc

#[derive(from_variants::FromVariants, Serialize, Deserialize)]
enum OrderState {
    #[from_variants(skip)]
    ReceiveItemId,
    ReceiveFullName(ItemIdReceived),
    ReceiveAddress(FullNameReceived),
    ReceiveCreditCardNumber(AddressReceived),
    // ...etc
}

fn update_state(message: String, state: OrderState) -> OrderState {
    match state {
        OrderState::ReceiveItemId => ItemIdReceived { item_id: message.parse() }.into(),
        OrderState::ReceiveFullName(prev) => FullNameReceived { prev, message: message.parse() }.into(),
        OrderState::ReceiveAddress(prev) => AddressReceived { prev, message: message.parse() }.into(),
        // ...etc
    }
}

[rdong8]

Really nice. Thank you!