[Devtools] Fwd: Debugging RxJS code

[Pete Muir]

Excellent writeup :-)


---------- Forwarded message ----------
From: Soumya Deb <deb at redhat.com>
Date: 19 May 2017 at 10:11
Subject: Debugging RxJS code
To: devtools-planner <devtools-planner at redhat.com>


Team,

Was having a chat with Michael and it came up that we need better ways
to debug our application, and as we're relying heavily on async
approach, debugging is significantly harder for us as the procedural
debuggers are limited in that aspect. So I looked into possible
solutions which can help us debug our application better, while using
all the goodness of RxJS Observables etc.

Some of these may already be known to many of you, but I'm just
putting them together, just in case you may find it helpful and
consolidated in one place (email isn't the best place for that, but
I'll start here and have the discussion, before moving it somewhere
better).

Ordered by the ascending level of rigorousness and descending
popularity of usage.

Strategy 1: using `do` in the data/process chains
===================================
Observable
.from([source])
.do(x => f(x))
// f(x) is a function that can be anything
// including, but not limited to, `console.log`
// *wink* *wink* *deadpan*
.subscribe(x => g(x))
// N.B: very same can be achieved with .debug(<string>), but that
implies you can't process the argument the way you like, it'll be
posted on the console output as is.

Strategy 2: allow long stack traces
=========================
var Rx = require('rx');
Rx.config.longStackSupport = true;
// This will make RxJS spew less utter bullshit
// and more relevant stack trace with better formatting
// which is actually less "long" than it usually is otherwise

Strategy 3: using more formidable Observable methods
========================================
There are several flow control operators, some of which make excellent
use for debugging.
For example: filter, debounce, lift, audit (and many more).

Strategy 4: use 3rd party tools
======================
Experimental Debugger: https://github.com/jhoguet/rxjs-debugger
Visualizer for RxJS streams: http://jaredforsyth.com/rxvision/

This is pretty much what I've gathered. Strategy 1 and 2 should be
useful to all of us and should be used project-wide IMO; whereas 3 and
4 are for the enthusiasts who want to go the extra mile.

I'll keep a lookout for any update on this topic, as after RxJS 5
release more debugging tools are to be expected, as this rewrite has
opened up some new avenues for it (which wasn't as viable in v4). If
you have suggestion, or something that I've missed to list, please do
let me know.

Thanks and hope it helps us.


-- 
Pete Muir
Technical Director, Red Hat Developer