Visit the preview URL for this PR (updated for commit 97eecad):

https://yew-rs-api--pr3274-html-omit-conditiona-9cjbipiu.web.app

_{(expires Fri, 26 May 2023 16:57:33 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

Size Comparison

⚠️ The following examples have changed their size significantly:

Benchmark - SSR

Yew Master

Pull Request

Thank you for the pull request!

However, after examining the original issue, I believe the current behaviour is intentional and correct.

Here are the reasons why I think the current behaviour is correct:

Rust is primarily an expression language

Quoted from Rust Reference Book:

This means that most forms of value-producing or effect-causing evaluation are directed by the uniform syntax category of expressions.

In other words, this means that almost every piece of code that actually does something in Rust are most likely expressions.

This design choice dictates several iconic language features in Rust. The main feature that is relevant in this case is expressions always produce a value.

E.g.: if b {} is an expression and let a = if b {}; is a valid statement. () is assigned to a.

At a glance, it might be intuitive to assume that the following code

let h = html! {
    <>
        if b {
            <span>{ "C" }</span>
        }
    </>
};

is roughly a syntax sugar of:

let h = {
    let mut nodes = VList::new();

    if b {
        // html! actually uses an iterator to construct children.
        // This example is trying to simplify what it does in this case.
        nodes.push(html! {<span>{"b"}</span>});
    }

    VNode::from(nodes)
};

However, if we take a look at the last expression of the if block, we can find that the block has a return type of Html instead of (). This means that it is an expression and not statement as "The type of ExpressionWithBlock expressions when used as statements must be the unit type.". As expressions always produce a value, it should desugar to:

let h = {
    let mut nodes = VList::new();

    nodes.push(
        if b {
            html! {<span>{"b"}</span>}
        }
    );

    VNode::from(nodes)
};

The VList here is not relevant, so we can further simplify this to:

let h = if b {
    html! { <span>{ "C" }</span> }
};

If you try to compile the above code, Rust compiler will generate a compiler diagnostic stating that this is invalid because the else branch is missing and the complier expects the default value of this block expression to be returned (()).

This is not difficult to understand, as blocks are expressions, they need to evaluate to a deterministic value type.
With block's else omitted, all existing conditional blocks must return the default value of ().

In this case, for if b { html! { <span>{ "C" }</span> } }, both Html and () are possible, which confuses the compiler.

To satisfy the compiler, one would need to write:

let h = if b {
    html! { <span>{ "C" }</span> }
} else {
    Html::default()
};

The next question becomes: how do we interpret if expressions in html!?

To solve this situation in html!, I can come up with 2 solutions:

1. Require an else block in html!.
2. Make default value of block expressions inside html! VNode::default().

The first solution is to make sure that every time an if expression is used, an else block is required. I.e.:

html! {
    <>
        if b {
            <span>{ "C" }</span>
        } else {
            <></>
        }
    </>
}

I think it is not difficult to reach a conclusion that this is cumbersome to write and in many cases, an unnecessary burden imposed on Yew users.

For the second solution, it should now make sense, that we make block expressions to evaluate to VNode as their default value if an else block is missing.
(The implementation is a little bit different and would allow any type that is accepted by VNode::from. But the above rationale should still stand.)

<></> is actually useful and important in some situations

Consider the following example (borrowed from @WorldSEnder from #3256, adapted for Yew):

use yew::prelude::*;

#[function_component]
fn App() -> Html {
    let a = use_state_eq(|| true);
    // hooks syntax is different in the master branch.
    // dependency should be placed as the first argument when testing with this pr.
    let on_set_a = use_callback(
        |_v, input| {
            input.set(!**input);
        },
        a.clone(),
    );

    html! {
        <div>
            <h1>{"Hello CodeSandbox"}</h1>
            <video width="720" src="https://sample-videos.com/video123/mp4/720/big_buck_bunny_720p_1mb.mp4" controls={true} />
            <br />
            if *a {
                <>
                    <h2>{"Click the button below for some magic!"}</h2>
                    <br />
                </>
            }
            <button onclick={on_set_a}>{"Toggle a"}</button>
        </div>
    }
}

fn main() {
    yew::Renderer::<App>::new().render();
}

In Yew v0.20.0, clicking on the button will not interfere with video playing. However, after applying this pull request, the video will be interrupted when clicking on the button.

When a is false, it evaluates to <></>. This protects the structural integrity of a VList when it is constructed by html!. After applying this pull request, the video will be interrupted and will require a key to protect the video element.

Conclusion

In conclusion, my personal opinion is that the current behaviour is more favourable so I am not in favour of upstreaming this pull request as a fix to #3256.

Appreciate the detailed response @futursolo. You've convinced me this isn't the right fix. I will move my feedback to #3256