{"id":584,"date":"2009-11-28T15:25:08","date_gmt":"2009-11-28T14:25:08","guid":{"rendered":"http:\/\/www.minddriven.de\/?p=584"},"modified":"2010-07-10T10:21:02","modified_gmt":"2010-07-10T09:21:02","slug":"rx-event-composition-single-valued","status":"publish","type":"post","link":"https:\/\/www.minddriven.de\/index.php\/technology\/dot-net\/rx-event-composition-single-valued","title":{"rendered":"Rx: Event composition – single-valued"},"content":{"rendered":"

In a first blog post<\/a> on the topic „event composition with Rx“ I presented operators that take several event input streams and create a single output streams, whose elements contain values from each input event („multi-valued<\/a>“ event composition operators). This second blog post instead treats \u201csingle-valued\u201d event composition. Multiple streams go into those composition operators and one single stream comes out, where each element of the output stream matches exactly one event\/value from any<\/em> input stream!<\/p>\n

Example solution, PPT slides and general information<\/h3>\n

In general, all introductory information on composition, description of the „multi-valued“ event composition operators and more bits-and-pieces can be found in my first blog post<\/a>.<\/p>\n

I’ve created a SL3 demo project where you can experiment with each composition operator. You can find the sourcecode<\/strong> (SL3 VS2008 project) here<\/a> and the live demo on Windows Azure<\/strong> here<\/a>.<\/p>\n

The PPT slides that contain all diagrams of the composition operators can be downloaded here<\/a>.
\nI would be glad if you could leave my name and\/or the blog URL (www.minddriven.de<\/a>) on every diagram.<\/p>\n

Merge()<\/h3>\n

The operator Merge<\/code> does serialization of all input event streams by firing an event everytime one of the input streams fires. The event\/value of the output stream will be the same as the event\/value on the input stream that has fired.<\/p>\n

The following code shows the simple usage of Merge<\/code>:<\/p>\n

\r\n    var composition = \r\n        Observable.Merge(stream1, stream2, stream3);\r\n<\/pre>\n
And the following example flow diagram shows the behavior of the operator under this code. Note how the incoming events are written to the output stream in exactly the same order as they come in:
\n\"Rx<\/p>\n
Amb()<\/h3>\n
Amb<\/code> comes from ambiguous<\/em> and has the following semantics. If you combine several input event streams with Amb<\/code>, the output stream will only contain the events from the input stream that fires first. The other input streams are not taken into account afterwards. That’s a kind of winner-takes-all<\/em>-strategy and could be valuable in some situations.<\/p>\n
Amb<\/code> can be used as follows:<\/p>\n
\r\n    var composition = \r\n       stream1.Amb(stream2).Amb(stream3);\r\n<\/pre>\n
And the following diagram shows an example composition situation. Note that stream 1 fires first and consequently Amb<\/code> only forwards events from this stream:
\n\"Rx<\/p>\n
Concat()<\/h3>\n
Concat<\/code> does (the name says it all) concatenation<\/em> of the input event streams. But wait: how can this work? In fact Concat<\/code> only<\/em> works when you have finite<\/em> event streams! On infinite<\/em> streams, Concat<\/code> watches the very first stream forever and the other streams don’t come to their turn. Thus use Concat<\/code> on finite event streams, when serialization of the input streams in the right order is crucial.<\/p>\n
The following code shows the use of Concat<\/code> on three finite input streams:<\/p>\n
\r\n    var composition = \r\n        stream1.Concat(stream2).Concat(stream3);\r\n<\/pre>\n
And here’s the concatenation done by this code in an example situation (the square brackets illustrate finite streams):
\n\"Rx<\/p>\n
Until()<\/h3>\n
The operator name says it all: Until<\/code> forwards events from an input stream to the output stream until<\/em> an event on a second stream occurs.<\/p>\n
The following code shows the usage:<\/p>\n
\r\n    var composition = \r\n        stream1.Until(stream2);\r\n<\/pre>\n
And the following diagram shows the behavior of Until<\/code> on 2 streams based on this code:
\n\"Rx<\/p>\n
WaitUntil()<\/h3>\n
Again the operator name speaks for itself: WaitUntil<\/code> does not<\/em> forward events from an input stream to an output stream until<\/em> an event on a second stream occurs. From then on every event of the first input stream will be forwarded.<\/p>\n
Here’s some code that shows how WaitUntil<\/code> works:<\/p>\n
\r\n    var composition = \r\n        stream1.WaitUntil(stream2);\r\n<\/pre>\n
And the following diagram shows WaitUntil<\/code>’s behavior based on this code in an example situation:<\/p>\n
\"Rx<\/p>\n
That’s it again. I hope you finde this information useful. As in the blog post on multi-valued event composition, I want to encourage you to give me active feedback and to improve the examples and descriptions of the composition operators above. Thanks!<\/p>\n
\"kick<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
In a first blog post on the topic „event composition with Rx“ I presented operators that take several event input streams and create a single output streams, whose elements contain values from each input event („multi-valued“ event composition operators). This second blog post instead treats \u201csingle-valued\u201d event composition. Multiple streams go into those composition operators … Rx: Event composition – single-valued<\/span> weiterlesen<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[198,197,181,195,179,178],"class_list":["post-584","post","type-post","status-publish","format-standard","hentry","category-dot-net","tag-combining","tag-composition","tag-events","tag-reactive-extensions-for-net","tag-reactive-framework","tag-rx"],"_links":{"self":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/584","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/comments?post=584"}],"version-history":[{"count":8,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/584\/revisions"}],"predecessor-version":[{"id":930,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/posts\/584\/revisions\/930"}],"wp:attachment":[{"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/media?parent=584"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/categories?post=584"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.minddriven.de\/index.php\/wp-json\/wp\/v2\/tags?post=584"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}