You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
One thing that came up in the review of #26 is that the
Widget
trait now depends onMessage
, 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. TheMessage
type is perhaps an acceptable type to bring into the widget layer, as it's basically just aVec<Id>
and aBox<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.The text was updated successfully, but these errors were encountered: