Add `Widget::Action` associated type

[PoignardAzur]

During various passes, widgets that want to signal a semantically meaningful event from the UI (eg a button that was clicked) can emit actions.

Actions are a centralized queue of messages intended for the root application, mostly for the app driver (eg Xilem) to handle. They are inspired by Facebook's Flux architecture.

Actions are currently under-designed. Right now, they only store the emitter's id, plus a payload among a small set of types with Box<dyn Any> as a wildcard. Ideally, we'd want a way to connect the type of an action from the widget that sent it, so that each widget would have an associated action type. This associated type would only exist for sized Widgets so that the trait remains dyn-safe.

[DJMcNab]

To clarify, this would mean that the action type is always downcasted? That seems reasonable to me.

I think Xilem would be able to make use of this for a slight ease-of-use improvement.

[PoignardAzur]

To clarify, this would mean that the action type is always downcasted?

Basically yes.

[test3211234]

This idea seemed great to me at first, but I'm not sure I really see how/why it would be used. Actions would still be Box<dyn Any> so that they can be stored in the central queue, so Widgets would just pass in whatever their event is to submit_action like normal. I don't see why the associated type exists, no method would use it. Or would they? I'm also curious why Daniel says this could make stuff easier in Xilem.

[Philipp-M]

I'm also curious why Daniel says this could make stuff easier in Xilem.

I think it's because View::message basically already receives a message: Box<dyn Any> which may just be casted down to View::Element::Action, it's "just" type information what the action may be for the relevant widget.

[not-my-profile]

View::Element::Action doesn't work because View::Element is bounded by ViewElement (rather than Widget).

I think if we have such an associated type it would be nice to constraint widget implementations to only emit actions of that type. That's not possible in a dyn-safe type but we could make Widget dyn-unsafe and automatically lift it to a dyn-safe trait via a blanket impl as such:

pub trait Widget {
    type Action: Any;

    fn on_text_event(&mut self, emit: &dyn Fn(Self::Action));
}

pub trait DynWidget {
    fn on_text_event(&mut self, emit: &dyn Fn(Box<dyn Any>));
}

impl<W: Widget> DynWidget for W {
    fn on_text_event(&mut self, emit: &dyn Fn(Box<dyn Any>)) {
        Widget::on_text_event(self, &|action| emit(Box::new(action)));
    }
}

Implementing this unfortunately takes some boilerplate but I think it would make implementing widgets more ergonomic. @PoignardAzur what do you think?

[PoignardAzur]

Yeah, it's one of the problems I bumped into when writing #939. I haven't found a boilerplate-free solution yet.

And yes, as time goes on I'm increasingly thinking that we want to split the Widget trait into a dyn-safe part and a generic part.

[DJMcNab]

View::Element::Action doesn't work because View::Element is bounded by ViewElement (rather than Widget).

WidgetView::Element is bounded by Widget though, which is the important thing here.

[not-my-profile]

@DJMcNab why is it the important thing? I'd say the important thing is that the View widget impls expect the correct Action type in View::message. Although it's not always the type of the associated Element since e.g. view::Textbox handles the actions from widgets::TextArea.

[DJMcNab]

If you're not a WidgetView, then why would you care about the associated type on Widget? The views which aren't WidgetView aren't views over widgets.

This is largely about ergonomics and easy correctness for the common case. That is, in most case you're handling Self::Element::Action, and so getting the name of the right type "by default" makes writing the WidgetViews most.
The case of Textbox is something to be aware of, but I think it's a very "but sometimes" argument.