View-level Message type in Widget

[raphlinus]

One thing that came up in the review of #26 is that the Widget trait now depends on Message, which is conceptually at the Xilem level. That's arguably a layering violation, and may make life more difficult for other possible reactive layers on top of the widget set.

The most flexible thing to do would be to make the Widget trait generic on the message type, but that would add a lot of type noise. The Message type is perhaps an acceptable type to bring into the widget layer, as it's basically just a Vec<Id> and a Box<dyn Any>.

Part of the reason I'm writing this issue is to get feedback about other potential uses of the widget layer. Is just having widgets produce Message good enough, or do we really need the type to be more flexible? Accommodating other reactive layers than Xilem feels a bit YAGNI right now, and perhaps we want to do a more careful review of layering if and when we get to that point.

[dhardy]

Sending a Box<dyn Any + Send> seems sensible. Adding a bound on Debug could be useful; unfortunately the only way I found of using this is sending the Box<dyn Any> alongside the pre-formatted debug repr.

Usually a message will only be sent to the corresponding View item (e.g. when a button widget is clicked), thus cx.add_message might be generic over M: Any + Debug + Send, and internally construct a Message with id_path resolved from the context (unfortunately a Cx does not currently contain the IdPath but only the Id).

Another possible application would be sending a message to a parent of the corresponding View item (for example, a Button contains a LabelWithShortcut which is activated on some key-press, and should trigger the button). This could be achieved by adapting View::model:

• Return MessageResult::Unused(message) by default
• While unwinding, if the result is Unused(..), try handling that message locally This is roughly KAS's current model for messages and I feel like it works well (but with the message routing logic provided; widgets only implement handle_message which does not expose the message path).

[DJMcNab]

Since #205 (and especially #290), this is no longer true - the association between id paths and WidgetId is now stored in the ViewCtx.

I think the situation is slightly different for web, but I think since an analysis for xilem_web isn't provided here, we can close this