The document provides an overview of CycleJS and reactive programming (RP). It discusses why the author chose CycleJS and RP due to their component model, declarative code, and explicit data flow. It addresses some initial concerns with RP like requiring a "brain rewire" and barriers to reuse. It demonstrates a simple app called Brian designed for people with cognitive disabilities. It describes the learning process of getting used to RP concepts like state management and higher order operators. Resources for learning more about CycleJS, RxJS, and debugging reactive apps are provided. The author notes improvements from the XStream library and looks forward to better visualization and debugging tools.
2. Why CycleJS & RP?
• Background in embedded realtime
comms & early Windows
–Async messages, events, signals
• Result of review of client side tools
• Good components model
• Declarative code
• Explicit data flow & transformation
3. Concerns
• Requires a “brain rewire”
• High barrier to reuse & contribution
• How do Progressive Enhancement?
• Slower initial development
• Are custom element tags clearer?
5. Quick Demo of Brian
• Designed for people with cognitive disabilities
– eg dementia or learning disabilities.
• Easy access to media and communications
• Various grades of UI complexity
– https://brian.opendirective.com
– https://brian.opendirective.com/assistant
– https://github.com/opendirective/brian
8. Drowning?
• Cycle opinionated use of Reactive frameworks
– All side effects in drivers
– Main made of pure function(s)
• Drivers are not complex– one liners are common
• Imagine flows splitting and joining (aka a
graph)
– Split: const stream2$ = stream1$
– Join .merge()
– Needs visualisation tools
– Play “Where’s my water”
9. Brain aches
• State, state and state!
– Problem for imperative too; cycle brings clarity
– Externally persisted eg user settings
– DB via API (eg pouchdb)
– Scan or single atom?
– Is single atom as bad as global state?
• Higher order operators eg flatMap – XS helps
• How to map web app experience to RP
11. Stop Press!
Stalz’s announcement of the XStream reactive
streams library for CycleJS means a good
number of the issues I hit have disappeared 0/
• http://staltz.com/xstream/
• http://staltz.com/why-we-built-xstream.html
12. XStream happiness
• Web apps use few of the many RxJS operators
– map, startWith, filter, merge, scan,
combineLatest, withLatestFrom,
mergeMap
• Hot vs cold, plus interaction with splitting
• Schedulers
• RxJS size on mobile
13. Debugging / testing
• http://staltz.com/how-to-debug-rxjs-code.html
• .do(x=>console.log(‘txt’, x))
• .subscribe(x=>console.log(‘txt’, x))
• Log all inputs and outputs (in production too)
• Unit test win with pure functions, less mocking
• ASCII Marble test descriptions 0/
• Global exception handler may be useful?
14. Relax, don’t sweat it
• This is RP with Observables, not full FRP
– Observable + iterator = streams
• No guilt - use non pure main function
• But, refactor out any code smells and anti
patterns as soon as possible. Pay your
Technical debt early
16. Wants
• Visualisation and debugging tools
• RxMarbles to cover higher order operators
• Examples of common idioms / patterns
• Repository of drivers
• Enhancing newbie on-boarding
17. Possible Bugs
• DOM driver seems to change capture/bubbling
– .do(preventPropagation()), cough
• No error event for img loading
– In line function handler with VDOM
• Extra click event on a removed node
– .filter(.parentElement !== null)
• Crazy bug with driver not getting item but added
subscribe does
• Reactivex.io docs for Observable.from missing