Require braces around prop values

[lukechu10]

This proposal makes braces required around prop values:

// before
html! {
    <Component prop=prop_value other_prop=other_prop with more_props />
}
// after
html! {
    <Component prop={prop_value} other_prop={other_prop} ..more_props />
}

This makes it possible to use the .. operator instead of with for specifying extra props: #1636

To make it more ergonomic, literals (such as "a string", 123, 123usize, false etc...) should be allowed without any braces (same as current syntax).

As a bonus (inspired by svelte), we could also allow a shorthand syntax when the prop is the same value as an identifier name:

// after with shorthand syntax
let prop = ...;
html! {
    <Component {prop} />
}

(svelte docs)

For normal components, I doubt this would be too useful because local variables are relatively rare in the view function. However, this would be immensely useful with functional components because all state are stored as if they were local variables.

Pros

• This would allow the .. syntax for destructuring props (Use Rust's .. syntax instead of with in html! #1636)
• This makes the separation between HTML markup and Rust code more distinct.
• Makes the html! syntax more consistent. Html blocks already require curly braces around expressions.
• This could allow for better error messages with unfinished expressions
• This would match JSX syntax more closely, making React and other JSX framework users feel more at home
• This would eventually allow for a shorthand syntax which is not ambiguous with bool props/attributes (e.g. disabled)

Cons

• Makes the code slightly longer
• VERY BREAKING CHANGE (almost all yew code would need to be rewritten)
• Fix all the docs :(

Please react with 👍 or 👎. If you have further opinions on whether this is a good or bad idea, feel free to respond in the thread.

[hamza1311]

VERY BREAKING CHANGE (almost all yew code would need to be rewritten)

We are gonna have to make breaking changes anyway. I think we should roll this change, #1646 and similar changes together to avoid breaking too much every release.

[lukechu10]

This change might also be better if rolled together: #1758

Even though it is not strictly a breaking change (<p>{ "string" }</p> should still work), it might be nice to emit a warning to tell the user to remove the braces. If some projects deny warnings in CI, this would be equivalent to a breaking change to them.

[intendednull]

Not a huge fan of this, but can see the benefits. Mostly because my projects are getting big, and this will be a lot of typing/regex gymnastics.

As a bonus (inspired by svelte), we could also allow a shorthand syntax when the prop is the same value as an identifier name

Okay with the extra typing if it makes this possible. Though one worry is my html formatter may get confused.

For normal components, I doubt this would not be too useful because local variables are relatively rare in the view function

Personally this would be incredibly useful. I only put local variables inside html!. Essential for refactoring large projects, as rust-analyzer won't touch anything inside macros. Also keeps html readable, and easy to maintain.

[lukechu10]

Not a huge fan of this, but can see the benefits. Mostly because my projects are getting big, and this will be a lot of typing/regex gymnastics.

It should be possible to create an auto-migrate tool with some "regex gymnastics" 😄

[K4rakara]

Requiring {}'s would mess with the borrow checker, making it so that you can't use references in props. IE:

let foo = "Hello world!".to_owned();
html! {
  <div data-foo={&foo}/> // Borrow checker error
}

Heres an alternative that wouldn't cause the same borrow checker issue:

let foo = "Hello world!".to_owned();
html! {
  <div data-foo=(&foo)/>
}

This also works in current Yew!

This isn't correct, see replies.

[K4rakara]

Oh, oops. I'm not certain whats required to get it to happen, but in certain cases, if you use a borrowed value, it errors because the {}'s introduce a new block, and therefore can't return a reference.

[lukechu10]

For example, the following would not work:

{
    let x = 1;
    &x // return reference to variable inside scope
}

But this would not work with current syntax either so I don't see any problem.

[K4rakara]

Oh, i think I know what i was thinking of:

let some_string  = String::from("abcdefg");
html! {
  <div data-foo={ &some_string.to_lower_case().replace("a", "Z") }/>
}

But now that I'm more used to rust, this is because you're sending already borrowed data into a function, mutating it into new data, and then trying to return a borrowed copy of the data, which doesn't work.

[lukechu10]

Oh, i think I know what i was thinking of:

let some_string  = String::from("abcdefg");
html! {
  <div data-foo={ &some_string.to_lower_case().replace("a", "Z") }/>
}

But now that I'm more used to rust, this is because you're sending already borrowed data into a function, mutating it into new data, and then trying to return a borrowed copy of the data, which doesn't work.

Yeah, you're taking a reference to a temporary created inside the block. But this wouldn't work even without the braces because you are still taking a reference to a temporary.

[Diggsey]

Also, I think this is irrelevant, because there's no reason that the macro has to treat the {} as part of the expression. They can simply be delimeters that are consumed by the macro.