Awaiting for Rx

How to use Rx along with async/await, presented at NDC London

Transcript

1. Awaiting for Rx: ! A Play in Five Acts
2. /paulcbetts
3. Why Rx?
5. code is communication between people ! (that incidentally, also runs on a computer)
6. await doesn’t help you get away from state
7. tasks don’t help you with events
8. Rx in 5 minutes
9. IObservable is a better event
11. events are lists
12. observable as timeline OnNext OnNext OnNext OnCompleted ‘A’ ‘B’ ‘C’ OnError!
13. tasks are just events that happen once
14. task as observable ‘A’ Task.Run(() => /*…*/)
16. + Task<T>
17. you
18. can
19. await
20. IObservable
23. the catch
24. you must guarantee that the IObservable terminates
26. The two ways to make things awaitable: Take and Aggregate
28. someTask.ToObservable(); <=> someObservable.ToTask();
31. async-friendly Rx operators SelectMany Create Defer Switch IScheduler.Schedule StartAsync Using Concat Merge
32. await often introduces unnecessary ordering constraints
35. this is MapReduce (or in C# lingo, SelectAggregate™)
37. always use Rx for UI events
38. always use Rx for UI events
39. ಠ_ಠ
40. always use Rx for UI events
43. describing an entire process in one place is the goal
45. describing an entire process in one place is the goal
46. Rx is particularly good at describing pipelines of data
47. declarative, functional code is easier to test
48. imperative await methods get the job done
52. use extensions to provide Task-friendly apis
55. – the average developer “hwæt.”
59. Rx makes testing eas(ier)
62. test ordering, not concurrency
65. Thanks!