Avoiding Msg types

[maurerdietmar]

I noticed that Component Msg types are quite a lot of typing, and I wonder why we need it at all.

Instead, we could simply send a closure like:

pub struct Msg {
    update_fn: Box<dyn Fn(&mut PwtTest, &Context<PwtTest>) -> bool>,
}

impl Msg {
    pub fn new(cb: impl Fn(&mut PwtTest, &Context<PwtTest>) -> bool + 'static) -> Self {
        Self {
            update_fn: Box::new(cb),
        }
    }
}

The update function would be as simple as:

    fn update(&mut self, ctx: &Context<Self>, msg: Self::Message) -> bool {
        (msg.update_fn)(self, ctx)
    }

One could use that inside the view function:

       let onclick = Callback::from(move |_| {
            link.send_message(Msg::new(|me, _ctx| {
                me.count += 1;
                true
            }));
        });
        
        html!{
            <div {onclick}>{format!("This is a test counter {}", self.count)}</div>
        }

Are there disadvantages of such approach?

[futursolo]

This is a valid pattern and the function component used to use this approach with a boxed function being the message type.

However,

If a boxed function is used as the message type, it will incur an allocation every time a message is sent to the component.
If a type with a known size is used as the message type, the message queue can pre allocate multiple spots in batch which leads to less allocation.

In addition, boxed functions are dynamically dispatched, which means the compiler will not be able to apply most optimisation.

This would result in:

• Potentially larger application size
  (This is not always the case, dynamic dispatch can also be used to optimise the bundle size.)
• Slower function call

[intendednull]

Another advantage to the long-hand approach is predictable behavior. There's one location where messages are handled, so only one place to look for side-effects. A little more typing isn't all that bad a trade-off for greater control.

And we always have functional components for people who don't care for that level of granularity.

[maurerdietmar]

I see. Many thanks for your answers!