A lot of modern JavaScript code uses async/await to handle asynchronous code. This is a great way to write code that is easy to read and understand. However, it is not possible to use async/await with Observables outside of the forEach() which requries more boilerplate than needed in order to do so.

Changes:

• Adds .all() to an observable instance allowing one to await the values it contains
• Adds a test for the new functionality

The current manner of ES imports is incompatible with the Node and Browser imports and @types/zen-observable

This manner of import should be supported and recommended.

import * as Observable from 'zen-observable';

This is the method used by symbol-observable and other packages (including RxJs/Observables).

The current usage is causing false negatives from the is-observable package in latest Node.

Running the following example from the README, then seems to be missing or not implemented.

Observable.of(0, 1, 2, 3, 4).reduce((previousValue, currentValue) => {
    return previousValue + currentValue;
}).then(result => {
    assert(result === 10);
});

Here is what I was trying to do:

"use strict";

const Observable = require("zen-observable");

Observable.of(1, 2, 3)
    .forEach(n => {
        console.log(n);

        // Since .forEach returns a promise I assumed that I should be
        // able to return it from here so that errors are propagated up.
        return Observable.of(4, 5, 6)
            .forEach(m => {
                console.log(m);
                throw new Error("ERROR!");
            });
    })
    .then(_ => console.log("completed."))
    .catch(err => console.error(err.stack));

Here is the actual result:

1          
2          
3          
completed. 
4          
5          ! ---------
6          !
4          !
5          !   How come both the forEach's survived an exception?
6          !
4          !
5          !
6          ! ---------

Observations:

• Errors are silently ignored.
• "completed." is logged before the inner list has completed.
• 5 and 6 get logged to the output... I had expected the 'throw' statement to abort the forEach().

What is the best way to handle such a use case with this proposal?

In modern bundlers (ex: Webpack and Rollup), .mjs have a higher priority than .js. This change will make those load ES modules instead of the commonjs versions, so the code can be treeshaked and hoisted.

This will bypass the Babel build, but in general bundlers will use a compiler to support the ES* features needed.

The map(callback) is called for each child subscription. That does not work for byte streams that can only be read once (Fetch API's response.json() for example can only be called once). Therefore the child observable should run the callback once and fan-out the result.

I've implemented it here: https://github.com/RickWong/fetch-observable/blob/master/src%2Flib%2FBetterObservable.js#L15 (this map() implementation also supports resolving Promises)

I have it as a dev dependency an I see it failing in older browsers at least because of "let" statement. Would you like to support any browser?

I'm using ES2015 modules (particularly with rollup) a lot for my personal projects these days. zen-observable almost works, but there were a couple of snags which this PR addresses. The docs suggest what this module can be required in using:

import Observable from "zen-observable";

but with default.js and the package file as they are in master this line needs to be:

import { Observable } from "zen-observable/default.js";

This PR adjusts default.js and adds a module field to the package file for rollup to pick up (and I'm told webpack too). This field is to ES2015 modules as the main field is to Node style CommonJS modules. These changes bring the behaviour of this module into line with the docs without affecting internal modules.

Hey there!

I just encountered a problem. ctor[Symbol.species] seems to be undefined in one of my use cases and I really can't tell why. Everything else seems to be alright, though.

So if it's possible that there is no Symbol.species set I propose a fallback for that case.

Objections?

Thx in advance!

If I do, for example, the following, nothing happens:

var obs = new Observable(observe => {/*... do set up here*/});
obs
  .filter(value => !value || !value.startsWith("//"))
  .reduce((collector,value) => collector.add(value), new Set())
  .forEach(set => console.log(set))

However, if I do:

var obs = new Observable(observe => {/*... do set up here*/});
Observable.from(obs)
  .filter(value => !value || !value.startsWith("//"))
  .reduce((collector,value) => collector.add(value), new Set())
  .forEach(set => console.log(set))

It works. However, that's obviously not ideal.