RxJS and Angular, I'm not feeling it

I read an article by on creating custom Closure builder for Angular, and apparently the "Architect" (yes, that's the name of the system) relies heavily on RxJS for consistent API.

Build Angular Like An Architect (Part 1)

Steve Belovarich ・ Apr 2 '19 ・ 19 min read

#angular #javascript #devops #webdev

Yet again, I'm thinking how much easier people would have it if we (Angular community) were ok to use Promises where they made sense. Here's an example snippet from the article:

return of(context).pipe(
    concatMap( results => ngc(options, context)),
    concatMap( results => compileMain(options, context)),
    concatMap( results => closure(options, context) ),
    mapTo({ success: true }),
    catchError(error => {
      context.reportStatus('Error: ' + error);
      return [{ success: false }];
    }),
  );

This is what it would look like with promises (in 'async' function):

try {
  await ngc(options, context);
  await compileMain(options, context));
  await closure(options, context);
  return { success: true };
} catch (error) {
  context.reportStatus('Error: ' + error);
  return { success: false };  
}

(This is just async function for handling one element from the stream, so you need a Promise.all in some top level to do the loop).

It's clear that the hotshots doing RxJS day in and day out can sling those concatMaps and mergeMaps in their sleep, but for an average developer - can you take a good glance at that RxJS and tell whether it's correct or not? Is the right operator being used? If you are speculating that a bug might be in that area of the code, how fast can you read and replay the flow in your head?

It is pretty clear that the wider web developer community already opted for Promises and async/await, how long does Angular community plan to go their own way?

(Before you ask, yes, I know Angular itself is built on RxJS - I have three pages of that in the call stack every time I hit a breakpoint).

Comments

[Andrei Gatej]

In my opinion, rxjs is a great tool and has a lot of use cases.

On a recent angular project I solved a tricky problem using rxjs and I couldn’t think of another way without using the magic of rxjs.

My point is, things make more sense with time and experience. Not to mention there’s a lot of articles out there that deep dive into concepts.

Of course, rxjs brings another layer of complexity which is why you shouldn’t use it if you are just making simple api calls for example. But there are certain situations where this tool could save the day.

[Miloš Lapiš]

RxJS concept is wider and more general than promises so are you suggesting that instead of using one building block you recommend using the mixing of two blocks? Where is the advantage? You make it just more complicated.

Not sure, but it would be probably a good idea to read a bit more about RxJS before making such a strong suggestion as rewrite it from the beginning.

[Ville M. Vainio]

The advantage of mixing is that code is usually more readable with async/await, when single value is being produced.

I’m not suggesting rewriting anything, but rather being more open to using Promises in own and library code.