class! improvements

[MartinKavik]

Suggested class! changes:

• Rename class! to C! to improve readability and make it consistent with A, S, E, and T.
• Accepts also String and other text types.
• Don't write empty class to HTML, i.e. class![] shouldn't be rendered as <div class>.

---

Note: We need to write if_ function.

[MuhannadAlrusayni]

I wouldn't vote for renaming to C! since we use this macro only once per node.
I would agree for the other points.

[flosse]

Suggested class! changes:

• Rename class! to C! to improve readability and make it consistent with A, S, E, and T.

👎

• Accepts also String and other text types.

👍

• Don't write empty class to HTML, i.e. class![] shouldn't be rendered as <div class>.

👍

[MartinKavik]

I have problems to read (longer) view's because class! looks like element macros so it takes me a while to decide if the given element has children or it has only class defined. The same for finding class attribute among other entities.
When I tried some options in source code, C! seems to me the most recognizable.

Counter arguments / other opinions or ideas?

[flosse]

Styles are key-value pairs for the attribute style (<div style="name:property;" />) so it makes sense to introduce a separate type S beside A. Event handlers are also special, so I can see why there is an E.
But class is just one of hundreds of attribute names (like id or so). So I would not expect a separate C! macro.
Of course it's a popular attribute so providing a convenient way to write it makes sense. But that's another bucket. Otherwise I would expect a I! for the popular id attribute, X! and Y! for the popular attributes x and y (in svg images), etc.

[MartinKavik]

I would rather use A.class("..") & A.id("..") and get rid of class! and id!.
However I haven't found a reasonable way how to express class conditionals class!["active" => active] in A.class(..) and remove verbosity caused by multiple items / classes.

[MartinKavik]

But class is just one of hundreds of attribute names (like id or so). So I would not expect a separate C! macro.

div![
    id!("submit-btn"),
    class!["btn", "btn-primary", &my_classes, "active" => active],
    "Submit",
]

vs

div![
    A.id("submit-btn"),
    A.class(["btn", "btn-primary", &my_class, if_(active, "active")]),
    "Submit",
]

Note: if_ would we usable also with elements, event handlers, etc. - ie. if_(cond, div![]) ~ if cond { div![] } else { empty![] }.

What do you think?

[MuhannadAlrusayni]

I haven't found a reasonable way how to express class conditionals class!["active" => active]

Another way to do it with function class():
https://gist.github.com/MuhannadAlrusayni/dd291089cb7f92510a20c80be81fa58b

Usage:

let attrs = vec![
    class("foo"),
    class("foo".to_string()),
    class(Some("foo")),
    class(vec!["foo", "boo"]),
    class(("foo_true", true)),
    class(("foo_false", false)),
    class(vec![Some("foo"), None, Some("boo")]),
];
// [Class(["foo"]), Class(["foo"]), Class(["foo"]), Class(["foo", "boo"]), Class(["foo_true"]), Class([]), Class(["foo", "boo"])]
println!("{:?}", attrs);

[MartinKavik]

OT: @MuhannadAlrusayni please use Gist or Rust playground for long code snippets.

[TatriX]

I wonder whether it's possible to do something like this:

node![div, ".foo.bar", ...]
// or maybe
node![div, ["foo", "bar" => active], "Text", span!["Hi"]]

[MuhannadAlrusayni]

@TatriX I believe we can achieve this, but might not be more readable than what we have now, imagine something like this:

node![
    div, .foo #foo#bar
    node![
        h1, .page-title #title,
        "Page Title"
    ],
]

vs

div![
    class!("foo", "bar"),
    id!("foo"),
    h1![
        class!("title"),
        id!("page-title"),
        "Page Title"
    ],
]

[flosse]

BTW: on the backend I really like to use maud, so I'd love to use it on the frontend too :)

div #submit-btn .btn .btn-primary class=(&my_class) class="active"?[active] {
  "Submit"
}

vs

div![
    A.id("submit-btn"),
    A.class(["btn", "btn-primary", &my_class, if_(active, "active")]),
    "Submit",
]

[MartinKavik]

• We can't use maud now because it requires nightly.
• I can imagine it would scare beginners - e.g. React developers would have to learn TEA, Rust, Maud and Seed API at once.
• I use consts for classes (e.g. C.btn) and I want to integrate something like this to Seeder. I don't know Maud very much, but it seems that it's not designed for similar cases.
• Is it possible to handle special things like element references or element keys with Maud?
• Both examples ^ seems pretty comparable to me, but I see your point - you can share the same template system with the backend and eyes are able to quickly identify symbols like # and . as ids and classes because we are used to see them often.
• I started to work on Seed because I was annoyed by Yew's html! macro - very cryptic errors, need to learn another language, not flexible enough..
• I'm afraid it'll make Seed code-base more complex and it would be another dependency and also key dependency without our direct control.
• I don't know about Maud IDE support, but I'm afraid it will be always worse than for Rust's native syntax.
• I can imagine that other people or even you will want to use another template system in the future (backend frameworks will pick different template lib; maintainer will deprecate Maud; there will be better template libs, etc.). - https://www.arewewebyet.org/topics/templating/ + https://lib.rs/template-engine
• Is it possible to transform Maud template to Seed "template"? E.g. Does Maud have some parsers / convertors / plugins for it?

[rebo]

So in my opinion the key thing for Seed's success has to be developer experience over and above all other considerations bar correctness and sensible performance.

My concern about the below is that it's very noisy, messy and annoying to write out every single time I want a class (which I almost always do for every element):

A.class(["btn", "btn-primary", &my_class, if_(active, "active")]),

Whilst it is conceptually and structurally true that class is just another attribute it is pretty much the most commonly used one. Therefore, from the developer experience perspective there is a reason to special case it.

Think about a developer experienced in JSX they are used to something simple like <div className = "btn"> we dont want to raise the barrier to new developers because they might look at all the extra syntax and nope out.

Personally I think

C!["x", "y", &my_class, if_(active, "active")];

is far more readable and maintainable than this:

A.class(["btn", "btn-primary", &my_class, if_(active, "active")]),

I think the C! version is far easier to scan so I can pick out the relevant classes.

So my solution is to allow both. A.class ... would be allowed precisely because class is 'just another attribute' but C! is effectively syntactic sugar to clean this up.

I definitely agree with using if_ though, it reads correctly in terms of english as well.

 if_(active, "active")

if active is true then use the "active" class.

[TatriX]

I think if_ looks a bit ugly, so maybe when/unless instead?

div![
    c!["x", "y", &my_class, when(active, "active")],
    unless(hidden, span!["xxx"]),
]

[TatriX]

Here's another option with several different types of syntax for attributes:

div![
     class => ["x", "y", &my_class, when(active, "active")],
     id = "foo",
     :style ["float": "left"],
     onclick: |_| Msg::Click,
     "Text here",
     span!["quux"],
];

Tag macro can contain either impl UpdateEl or attribute_name DELIMITER $value.