TatriX
commented
4 years ago After writing tones of markup using old and new macros my subjective conclusions is that I really dislike uppercase and shortened macros. So I strongly prefer class![] over C![] and when!() over if cond { } else { } over IF!().
I would prefer module style syntax over javascripty version:
tag::custom("custom-element")
// instead of
TAG.custom("custom-element"),IIRC main reason to go for C![] over class! was that it's easy to confuse the later for with a tag. I personally never had that problem but I understand the logic. So perhaps we can solve this by using module for non-tag macros:
div![
attr::class!("center"),
attr::id!("app"),
]In this case one can add use attr::class; and use it like it used to be: div![class!["foo"]].
Instead of chaining I would prefer having a list of arguments. It makes moving, adding and removing easier and symmetrical:
attr::list(&[
attr::id("my-container"),
attr::classlist(attr::class!["container", "my-class"]),
attr::class("container my-class"),
attr::disabled(disabled),
attr::autocomplete(attr::Autocomplete::On),
attr::autofocus(true),
attr::custom("data-columns", "3"),
attr::custom("custom-boolean", true),
attr::width(300),
]),
// or in case you really add that many attrs often:
fn complex_container<T>() -> Node<T> {
use seed::attr::{self, *}; // or maybe `attr::prelude::*` with favorite attrs
div![
attr::list(&[
id("my-container"),
class!["container", "my-class"],
attr::class("container my-class"),
disabled(business_logic_check(&model.data)),
autocomplete(Autocomplete::On),
autofocus(true),
custom("data-columns", "3"),
custom("custom-boolean", true),
width(300),
])
]
}
Note, I'm using attr instead of at here, because that's more natural for me to read and write to.
flosse
MartinKavik
OYangXiao
nielsle
asvln
arn-the-long-beard
Previous work:
Let's design the final element API so we can stabilize it.
The first draft / a foundation for brainstorming: