xilem: Add message_handler view

[azymohliad]

This PR implements @Philipp-M idea for a channel view from this message. For now I took liberty to rename it to message_handler, as it seems like the main purpose of the view, while the rest is just a machinery for extracting MessageProxy to it, but it can be changed of course.

I've implemented it just for practice and to aid the discussion, I'm not actually proposing to merge it (at least yet, UPD: I now think #463 is a more ergonomic option). Especially I'm not sure if my hack with deferring store_proxy to View::message call (just for giving it access to mutable app data) is a good pattern.

[Philipp-M]

if my hack with deferring store_proxy to View::message call (just for giving it access to mutable app data) is a good pattern.

Yeah that's not optimal, FWIW it's similar to what I did in #452.
The reason why only View::message has access to the state is historical, and is indeed also something I'd like to discuss (on zulip), since right now it should be possible to access it in either View::build and View::rebuild, as view building/messaging and rebuilding happens on the main thread currently.
Originally the app_logic was on a separate thread, parallel to the thread having access to the view context and the element-tree, to decouple rendering the view from rendering the actual widgets. It's not yet clear if that's necessary, but if app_logic takes too long to evaluate currently on the main thraed, that could mean hickups.

Other than that it looks good so far to me.

[azymohliad]

Originally the app_logic was on a separate thread, parallel to the thread having access to the view context and the element-tree, to decouple rendering the view from rendering the actual widgets. It's not yet clear if that's necessary, but if app_logic takes too long to evaluate currently on the main thraed, that could mean hickups.

Aah, that clarifies things! Thanks a lot for the explanation!

[DJMcNab]

This is another thing which interacts with hot reloading; in that case, we would definitely need to move things around.

I have a design in my, but it is yet to be tested/implemented.

[Philipp-M]

I don't think a web label makes sense here?

[azymohliad]

Btw, let's close this and #463 to clean up the list of PRs? I suppose there's no any value in them, besides just exploring how such views could be implemented

[azymohliad]

I'll close it for now to keep the PR list clean, but will keep the branch around for a while just in case.