CwlSignal and Reactive Programming
The careful separation of “input” and “output” and the modelling of reactive programming as a channel is a distinguishing feature of CwlSignal. Other common implementations treat reactive programming as an implementation of the “Observer” pattern but this leads them to hide the input end of their channels or confusingly use types that are both input and output, when only an input interface is desired.
[…]
Unlike functional programming inspired transformation functions (e.g.
map,flatMap), the fundamentaltransformin CwlSignal does not return its result butsends it into theSignalNext(interface equivalent toSignalInputfor sending to the nextSignalin the chain). This design allows you to emit any number of values or an error.
In this article, I’ll explain why I consider reactive programming to be one of the most important design patterns for application programming by looking at three scenarios that are common in application development, yet are a drain on development time, lead to frequent bugs and make design and refactoring hard. I’ll show how reactive programming addresses the verbosity, eliminates the unsafety and restructures the code to aid maintainability.
[…]
The biggest advantage comes when you realize that in applying a solution to just one of these problems, you’ve gained a solution to the other three for free.
