RxJS Version 4.0

This is another release in terms of cleaning up our technical debt by simplifying a number of our infrastructure, including our schedulers both for regular usage as well as testing. There were will be a few more point releases from this repository before a switch over the more modern RxJS vNext, including modularity, expression trees, and so forth.

Before we go further, it's worth mentioning that since Microsoft Edge supports ES 2016 Async Functions, you can take advantage of them in whole new ways in RxJS, because as we've had support for returning Promises, we support async functions as well.

With a very quick example, we can do the following:

const source = Rx.Observable.of(1,2,3)
  .flatMap(async function (x, i) {
    var result = await Promise.resolve(x * i);
    return result;
  });

source.subscribe((x) => console.log(`Next:  ${x}`))
// => Next: 0
// => Next: 2
// => Next: 6

Included in this release are the following:

• A More Complete rx.all.js
• Scheduler rewrite
• Testing rewrite
• Collapsing of operators
• Performance upgrades

What's coming next in this release?

• Modularity
• More Performance Upgrades

A More Complete rx.all.js

In previous releases, rx.all.js and its compat counterpart rx.all.compat.js contained all of the operators in RxJS, but did not include any of the testing infrastructure. This has been changed so that you no longer need to bring in rx.testing in order to write your own tests.

Scheduler Rewrite

The schedulers have long had a long of technical debt when brought over directly from the .NET world. To simplify this, we will now have the following contract on the Scheduler as written in TypeScript so that it makes sense as an interface. You will notice that the previous versions which did not have state associated with them are no longer supported. This caused too much overhead to support both, so if you have no state to pass, simply pass null for the state.

interface IDisposable {
  dispose(): void
}

interface IScheduler {
  // Current time
  now(): number;

  // Schedule immediately
  schedule<TState>(state: TState, action: (scheduler: IScheduler, state: TState) => IDisposable) : IDisposable;

  // Schedule relative
  scheduleFuture<TState>(state: TState, dueTime: number, action: (scheduler: IScheduler, state: any) => IDisposable) : IDisposable;

  // Schedule absolute
  scheduleFuture<TState>(state: TState, dueTime: Date, action: (scheduler: IScheduler, state: TState) => IDisposable) : IDisposable;

  // Schedule recursive
  scheduleRecursive<TState>(state: TState, action: (state: TState, action: (state: TState) => void) => void): IDisposable;

  // Schedule recursive relative
  scheduleRecursiveFuture<TState>(state: TState, dueTime: number, action: (state: TState, action: (state: TState, dueTime: number) => void) => void): IDisposable;

  // Schedule recursive absolute
  scheduleRecursiveFuture<TState>(state: TState, dueTime: Date, action: (state: TState, action: (state: TState, dueTime: Date) => void) => void): IDisposable;

  // Schedule periodic
  schedulePeriodic<TState>(state: TState, period: number, action: (state: TState) => TState): IDisposable;
}

Now, to schedule something immediately, you must follow the following code snippet. The return value is optional as we will automatically fix it to be a Disposable if you do not provide us with one.

var d = scheduler.schedule(null, function (scheduler, state) {
  console.log('scheduled ASAP');
  return Rx.Disposable.empty;
});

Same applies to scheduling in the future:

// Scheduled 5 seconds in the future with absolute time
var d = scheduler.scheduleFuture(null, new Date(Date.now() + 5000), function (scheduler, state) {
  console.log('scheduled using absolute time');
  return Rx.Disposable.empty;
});

// Scheduled 5 seconds in the future with relative time
var d = scheduler.scheduleFuture(null, 5000 function (scheduler, state) {
  console.log('scheduled using relative time');
  return Rx.Disposable.empty;
});

You will also notice that the recursive scheduling as well as periodic scheduling removed the versions where no state was involved. Also, it is necessary to enforce that with scheduleRecursiveFuture determines the relative or absolute timing by the return value from the recurse call for example. If you don't wish to use state for the recurse call, simply use recurse(null, dueTime).

// Absolute scheduling
scheduler.scheduleRecursiveFuture(1, new Date(Date.now() + 5000), function (state, recurse) {
  if (state < 10) {
    recurse(state + 1, new Date(Date.now() + (state * 1000));
  }
});

// Relative scheduling
scheduler.scheduleRecursiveFuture(1, 5000, function (state, recurse) {
  if (state < 10) {
    recurse(state + 1, state * 1000);
  }
});

Testing Rewrite

One of the biggest undertakings in this release was to standardize and clean up our unit tests. Over the past releases, there was a bit of technical debt that needed to be paid off. In this release, our virtual time system as well as our test scheduling was rewritten as to put it more in line with the regular schedulers. We rid ourselves of the WithState operators, simply renaming them to their basic operators such as scheduleAsbolute and scheduleRelative.

With the TestScheduler, we cleaned it up so that you can easily specify when a particular timing for the creation, subscription and disposal of the Observable sequence. This is a quick example of a test in action using timing where in the scheduler.startScheduler method as the second parameter, you can pass in an object with some timings for creation, subscription disposal. If you omit this, it will default to the normal timings of 100 for created, 200 for subscribed and 1000 for disposed.

test('first default', function () {
  var scheduler = new TestScheduler();

  var xs = scheduler.createHotObservable(
    onNext(150, 1),
    onCompleted(250)
  );

  var res = scheduler.startScheduler(
    function () {
      return xs.first({defaultValue: 42});
    },
    { created: 100, subscribed: 200, disposed: 1000 }
  );

  res.messages.assertEqual(
    onNext(250, 42),
    onCompleted(250)
  );

  xs.subscriptions.assertEqual(
    subscribe(200, 250)
  );
});

All tests should look like this now making them much easier to read going forward.

Collapsing of Operators

Previously, we had a number of operators such as debounceWithSelector and timeoutWithSelector that were simply overloads of their respective debounce and timeout methods. To avoid confusion having more named operators, we have simply condensed those into debounce and timeout` so that they look like the following:

Debounce with relative due time:
Rx.Observable.prototype.debounce(dueTime, [scheduler])

Debounce with selector:
Rx.Observable.prototype.debounce(durationSelector)

Timeout with relative or absolute due time:
Rx.Observable.prototype.timeout(dueTime, [other], [scheduler])

Timeout with selector and optional first timeout:
Rx.Observable.prototype.timeout([firstTimeout], timeoutDurationSelector, [other])

Performance Upgrades

In this version, we addressed more performance as we rewrote many operators to minimize chained scopes in addition to writing operators from the bottom up instead of relying on composition from other operators. This had some significant increases in some areas. In addition, we also did some shortcuts for example if the Rx.Scheduler.immediate was used, we could swap that out for an inline call with returning an empty disposable.

In RxJS vNext, many of the performance concerns will be addressed and have shown great progress.

What's Next

There will be a number of more releases for 4.x until vNext is ready which will address a number of issues including:

• Modularity
• Performance

Modularity

Now that the operators and schedulers have largely stabilized for performance, we're going to fix more of the modularity story, allowing you to bring in only what you need. Work had already begun on this part of the project, but now that the majority of the technical debt has been paid, this makes for a much easier transition.

Performance

Although many operators have been rewritten to minimized chained scopes, there are a number of operators that have not. In this release, we intend to get those operators such as timeout to be optimized for performance and making it more optimized for the GC.