I just encountered a situation where I would like to produce three distinct events that are also produced by buttons when I get one of three keypresses. To support this, I made my message an Option:
type Message = Option<Message>;
I think an easier approach would be to support flat_map on Subscription. Right now, Subscription has a method map. This method is useful to convert to events, but some subscriptions might lead to several events being produced or no events being produced. Currently, I see no API to accommodate that. I think we should add a flat_map method to Subscription. This would allow us to return anything that impls IntoIterator from flat_map and produce a new subscription that flattens the iterator. An example should be provided that uses a flat_map with Option so people are aware that is possible (many don't know Option impls IntoIterator).
I am willing to set up a PR for this if this makes sense. Just let me know.
vadixidav
>All comments
I am not convinced we should complicate the subscriptions API to potentially allow combinators with complex logic.
A Subscription always produces messages with a given contract. I find it's easier to think about them this way. Then, your update logic can choose to handle the relevant messages and ignore the others. This forces users to keep message logic centralized in a single place.
hecrj
on 1 May 2020
Related issues
aentity
路
3Comments
cetra3
路
3Comments
aentity
路
4Comments
Gohla
路
4Comments
johannesvollmer
路
4Comments
Most helpful comment
I am not convinced we should complicate the subscriptions API to potentially allow combinators with complex logic.
A
Subscriptionalways produces messages with a given contract. I find it's easier to think about them this way. Then, yourupdatelogic can choose to handle the relevant messages and ignore the others. This forces users to keep message logic centralized in a single place.