RFC: utility macros to minimize boilerplate

[davidon-top]

Hello,

I made a utility crate for rstml-component that helps me with making sites using rstml-component, for now its only on github (not yet on crates.io) because i think it could become part of rstml-component with a feature flag for example.

what it does

its an attribute proc macro that turns functions into components (an example of what the macro expansion might look like in the readme)

Additionally if it were to go upstream i could also make another macro that eliminates write_html!(formatter, ...) while keeping your ide helpers. Making a macro for it tricky and would lead to a lot of code duplication (same code in rstml-component-macro and my crate)

Would you be interested in heaving the utility crate be upstreamed into here or should i just publish it to crates.io as a separate crate? I'm willing to implement things from my crate into here and making a pr, i just don't want to waste time integrating it and then getting rejected in the pr.

[Alxandr]

That's kinda funny, cause rstml-component initially started with the following syntax:

rstml_component! {
  pub struct MyComp(prop_a: String, prop_b: impl HtmlContent) {
    <div /> 
  }
}

The issue I had was how to deal with branches and adding "normal" rust in top of the function, before you start with the html.

I believe most of the code to make this should already be available in this crate, and I'm definitely open to expanding it to make it more user friendly :).

What I don't really like about your syntax is the fact that make a function, but end up with a struct (with a different name no less). I find that somewhat surprising that if I write a function fn foo(...) {}, it doesn't exist, and can't be called just because you declared it an component. A better solution for this (I think) is to keep the function and also generate the struct. That means one of the impls can just call the other.

[davidon-top]

What I don't really like about your syntax is the fact that make a function, but end up with a struct (with a different name no less).

The reason why i made it that way is because of lint errors. Leptos uses the function ident and then it complains about non snake case functions. But i can see how that would be somewhat unintuitive so ill try and figure out a better solution.

I'm definitely open to expanding it to make it more user friendly :).

Awesome, ill get started on integrating it and drafting a pr.