RxJS Functions (Part 2)

bindNodeCallback

One thing I’m really growing to love about ReactiveX is the shear number of functions that exist in the API. It’s kind of like lodash for Observables. Often I’ll find myself trying to use two or three of the functions I’m familiar with only to discover later that a single function in the API already does what I need.

Previously, I posted an example of bindCallback which takes a standard function that uses a callback, and converts it into an Observable. If you’re accustomed to NodeJS however, you may have noticed that bindCallback is not well suited to handle the Node (error, result) => {} callback structure. bindNodeCallback illustrates well the sugary-ness of RxJS mentioned above.

bindNodeCallback

It’s just like bindCallback, but the callback is expected to be of type callback(error, result).

Like the description above from the docs says, bindNodeCallback is the same as bindCallback. The only difference is that you would use bindNodeCallback when the signature of your callback function matches that of NodeJS’s. Let’s look at our previous example of a function which takes a callback:

When the click event is fired, the listener we setup with addEventListener will call the function onClick and pass it the value of the click event. So the function signature would be (event) => {}.

However, in NodeJS, the standard callback function signature in this scenario would be something like (error, event) => {}. If any error is thrown during the execution of the function using our callback, it will pass the error to the callback.

Let’s try to use bindCallback on a function using a callback with this type of signature and see what happens:

When this code is run you’ll see that an Error object is logged normally to the console. The error was passed to the next function instead of the err function. Why? Because bindCallback assumes that the first argument passed to the callback (in this case the ‘Oh no!’ error) is a normal value. That’s where bindNodeCallback comes in:

Now when we run the code, we see an error output to the console as expected. The only difference is that bindNodeCallback was used instead bindCallback. The first argument passed to the callback is truthy, so the err function is called on our observer instead of the next function.

Note: Like bindCallback, bindNodeCallback also completes after it emits once.

While bindNodeCallback is definitely useful, the name is a little wanting. The error first callback syntax is just a convention. It could be used anywhere, and not just node. Maybe bindErrorFirstCallback?

Stay tuned for Part 3. Things will start getting more interesting now as the next couple of functions deal with manipulating the data streams themselves instead of just creating them. And be sure to check out Part 1.