New component macro is dependent on a variable name 'root' about relm4 HOT 11 CLOSED

That need to be addressed for sure. I've had the idea to add a syntax like this:

let widgets = view_output!(model, root);

Or we could use the function signature to figure out the names, but then still something like this would be necessary to be 100% correct:

let widgets = view_output!(model);

from relm4.

I think there isn't any reason to explicitly specify the root widget, if we can just infer it from function parameters. The second option seems fine, and it would allow for arbitrary variable names for the model.

from relm4.

I wonder if we could reduce the amound of boilerplate by stripping out the type info from the function parameters,

so this:

fn init_parts(
        counter: Self::InitParams,
        root: &Self::Root,
        input: &mut Sender<Self::Input>,
        _output: &mut Sender<Self::Output>,
    ) -> ComponentParts<Self, Self::Widgets> {
        let model = AppModel { counter };
        let widgets = view_output!();
        ComponentParts { model, widgets }
    }

turns into this:

init_parts! (counter, root, input, _output) {
        let model = AppModel { counter };
        let widgets = view_output!();
        ComponentParts { model, widgets }
}

This is not very rusty, but it looks nicer.

from relm4.

Oh, I see, you've been suggesting the same idea in #99. So what do you think now?

from relm4.

I think, Rust will actually prevent you from using this syntax. It's weird but everything that isn't the direct input of a macro must be somewhat valid syntax. But in any case you're right and I will experiment with solutions to reduce the boilerplate.

I think the types could be reduces, too, if everything that isn't explicitly declared defaults to () unless it's something important like Widgets.

from relm4.

I did get a syntax similar to this to work with macro_rules in my original ccs prototype.

from relm4.

Rust permits it as long as the user provides ident arguments

$(#[$attr4:meta])*
fn init(
    $argsv:ident: $args:ty,
    $rootv:ident,
    $inputv:ident,
    $outputv:ident
) $init_view:block

from relm4.

I had a similar syntax planned for the menu macro but it didn't work. Rustc doesn't like something like macro!(param) { other code }, even if it's part of an attribute proc-macro.

The solution with fn could work, though. Yet I still have to test because, macro_rules! and proc macros are quite different.

from relm4.

We will have a problem with custom syntax and macros in Rust, it seems. Rust only likes custom syntax once you have at least an outer macro! { input } to put everything into.

/// Custom syntax NOT allowed
#[test]
struct Test(Custom) {
    test: u8,
}

/// Custom syntax allowed
test! {
    struct Test(Custom) {
        test: u8,
    }
}

This mean that attribute macros like #[component] don't allow custom syntax on their own. Yet once we use a normal proc-macro we might loose support for some tooling including cargo fmt if I'm not mistaken. Also, it's usually kind of nice that Rust catches invalid syntax in the trait impl before the macro has to do anything.

TL:DR we can't use custom syntax in attribute macros directly and it would be nice to keep the macro as attribute macro (to keep the code as natural as possible).

However, what we can do is to use valid Rust syntax for our advantage.

For example, we can do something like this:

    // Initialize the UI.
    #[args(params, root, input, output)]
    fn init_parts() {
        ...
    }

It'd definitely support cargo fmt and looks more Rust-ish, I think.

from relm4.

#[args(params, root, input, output)] sounds like a good idea if it can work better with IDEs.

from relm4.

Should be fixed now. The macro looks the function parameters and the returned model to figure out the name of the model and to root.

from relm4.