Is it possible/reasonable to (effectively) impl <T: Display> IntoDynNode for Option<T>?

[EndilWayfare]

Preamble

First of all, love what you're doing here. I very recently came to dioxus 0.5 from several years of yew. I got tired of fighting tooth-and-nail to avoid clones, extra comparisons, and unnecessary re-renders. The "it's almost entirely static except for exactly where it isn't" paradigm is a game changer.

There are a lot of things that dioxus can accomplish more quickly, cleanly, and compactly, but there are still some rough edges where I find myself writing boilerplate or awkward constructions.

It's very possible I just haven't been around long enough to pick up necessary/useful idioms yet, but I have some questions about potential design decisions. Given the technical depth and complexity of this workspace, it's hard for me to quickly determine if my "why doesn't it do it this way" is a "because it turns out that's actually just a bad idea" thing, a "the compiler already does that/that's not actually meaningfully more efficient/perhaps because WASM quirks" thing, or a "we just didn't, hmm that's an interesting idea" thing.

Ok, The Actual Question

Many times, I have a data atom T where T: Display (because I want to render it sometimes) but I prefer to store/pass/operate-on it as a T and not as a String until the very end, right when I rsx!("{t}") it into the page. As T, that's straightforward enough; the overlap between rsx! and format!+friends makes it easy and familiar.

But not when it's an Option<T>. Because Option<T>: !Display even when T: Display, which is the sane default in most Rust programs. However, in the case of UI rendering, I think it's reasonable to say that almost always the behavior you want is the equivalent of

let expr = maybe_t.map(|t| t.to_string()).unwrap_or_default();

// Which, since `String: IntoDynNode` and `Option<T: IntoDynNode>: IntoDynNode`,
let expr = maybe_t.map(|t| t.to_string());

rsx! {
    // Am I correct to imagine that curly-braces effectively expand to `.into_dyn_node()`?
    {expr}
}

Obviously, the biggest technical roadblock to impl<T: Display> IntoDynNode for Option<T> is the limitations of the trait system itself. That blanket-impl couldn't coexist with the existing impl<T: IntoDynNode> for Option<T>. But that's a very "X/Y Problem" kind of thing. Really, the trait isn't what I care about , it's just a means to the "please god can i somehow avoid typing |t| t.to_string() it burns" end.

It may seem a bit petty, but this primarily crops up for me a lot in more higher-order-component-like, reusable-behavior, abstraction-because-come-on-abstractions-rule situations where extra noise can make it even harder to scan/grok what's going on at a glance.

Let's Get a Bit More Concrete

For the purpose of discussion, let's imagine we have some types something like these:

#[derive(Clone, PartialEq)]
pub struct Record {
    // Stuff and Things
    ...
}

#[derive(Clone, Copy, PartialEq)]
pub struct Revision {
    // Other Stuff and Different Things
    ...
}

impl Record {
    pub fn revision(&self) -> Option<Revision> {
        // Some actual computation.
        // Let's say, for fun, that there is no `Option<Revision>` member of `Record`
        // or any of its members recursively.
    }
}

It would be ideal if we could just

rsx! {
    div { class: "fancy",
        {record.revision()}
    }
}

instead of

rsx! {
    div { class: "fancy",
        {record.revision().map(|t| t.to_string())}

        // Or
        {record.revision().as_ref().map(ToString::to_string)}
        // but the `as_ref` needed for owned values kinda takes the wind out of the "not a trivial closure" sails...
    }
}

On its own, in isolation, it's not that bad. It's in already-noisy or highly-repetitive contexts where it starts becoming more of an issue.

pub fn content(&self) -> Element {
    rsx! {
        match self {
            Self::Foo(foo) => foo.map(|t| t.to_string()),
            Self::Bar(bar) => bar.map(|t| t.to_string()),
            Self::Baz(baz) => baz.map(|t| t.to_string()),
            Self::Quux(quux) => quux.map(|t| t.to_string()),
            Self::SuperDeluxe(deluxe) => deluxe.map(|t| t.to_string()),
        }
    }
}

It makes me feel like I'm doing something wrong, when I think this is about as clear/correct/elegant as you're going to get in that situation.

yew has a similar problem, honestly.

let value: Html = record.revision().map(Html::from).to_html();

html! {
    <div class={"fancy"}>
        {value}

        // You don't need the `.to_html()` unless the type of the expression is important, 
        // e.g. returning `Html` as a common type from a function
        {record.revision().map(Html::from)}
    </div>
}

For some reason, I (subjectively) have less of a revulsion to .map(Html::from) than to either .map(|t| t.to_string()) or .as_ref().map(ToString::to_string).

The "single method-call wrapper" closure feels too ad-hoc, or like a hack.

The "to string to string" feels transparently, redundantly repetitive. Not to mention, requiring as_ref because of the trait method signature.

Why IntoDynNode as a Separate, Explicit Trait?

I'm certain there is a good, thoughtful reason. I'm just not sure what exactly it is, and I feel like it would give me a better "gut feel" for how I'm supposed to reason about the dioxus codebase if I knew.

Is it for clarity of intent? Is it to separate value-transformation/conversion from "static monomorphized dynamic dispatch" semantics? Is it a publicly-namable "semi-sealed" trait? Is it a proc-macro thing, perhaps related to expansion-time type resolution limitations?

Side-note: What is with the <A = ()> type parameter? I don't see that it's actually used in the impls.

yew has a very similar trait, ToHtml. It seems to, similarly, be more about "type-plumbing" than about "formatting transformation", and to be specifically about "curly-brace expansion in macros". However, there are two main things it has additionally:

1. ToHtml impls for Rust primitive values. Contrarily, you can't rsx!({42}), you have to rsx!("{42}"). Not necessarily relevant, just interesting.
2. impl<T: ToString> From<T> for VNode, which is why Html::from is a thing. (Html is just a type alias to VNode.)

What would be the downside of impl<T: ToString> From<T> for DynamicNode?

That wouldn't get us all the way to "Option<T>s just work", but it would get us to "about on-par with yew", which would be an improvement, in my opinion.

yew has the "advantage" of only having a single "virtual DOM node" type, instead of the static/dynamic distinction that makes dioxus more powerful. So, the question is, might that get us into trouble, somehow?

Are there cases where a formatted value could be a static node? Where it can't change value over the lifecycle of a template? (Is that even possible currently, in userland, outside of the rsx macro? I don't know enough about the internals.) And so it could be a mistake to prematurely couple "from ToString" to "is dynamic"?

Would it be "too magical", or cause type-inference issues that I'm not foreseeing?

If From<T: ToString>, why not further?

The trick seems to be (at a minimum) avoiding the "upstream crates may add a new impl of trait std::fmt::Display for type std::option::Option<_> in future versions" conflicting implementation error. That, and the blanket impl<T> From<T> for T.

Back-of-the-envelope type-checking seems to suggest that something along these lines would technically compile:

impl<T: ToString> From<T> for DynamicNode { ... }

// Explicitly `impl From<T> for DynamicNode` for the types that explicitly impl `IntoDynNode` currently.
//
// Blanket `impl<T: Into<DynamicNode>> IntoDynNode for T` would cause "upstream crates may".
// Blanket `impl<T: IntoDynNode> From<T> for DynamicNode` would break `From<T> for T`.

// impl<T: IntoDynNode> IntoDynNode for Option<T> { ... }
impl<T: Into<DynamicNode>> IntoDynNode for Option<T> { ... }

I know I would do this, because I have a bit of a tendency to go full "type astronaut" and get entirely too carried away with clever-sounding constructions. That doesn't necessarily mean that it's a good idea.

Alternate Solution I Guess

Just add another trait!

// TODO: Bike-shed the living daylights out of the trait name
pub trait ForDisplay {
    type Out: IntoDynNode;

    fn for_display(&self) -> Self::Out;
}

impl<T: ToString> ForDisplay for Option<T> {
    type Out = Option<String>;

    fn for_display(&self) -> Self::Out {
        self.as_ref().map(ToString::to_string)
    }
}

rsx! {
    // Not as snazzy as "it just works", but better than the status quo.
    // This is more-or-less what I'm doing currently in my own usage.
    {record.revision().for_display()}
}