Meta

[sindresorhus]

Meta

[thgreasi]

Do you have any plans to exports as a UMD module? I find the CommonJS-only style too restrictive for a library.
Perhaps you could write it in ES6 + rollup/babel for UMD exports + system-import-transformer to replace the require() parts. Or at least (if we need to stay synchronous) test for the global exports of RxJS as well.
I would prefer to leave localForage-observable with as little dependencies as possible, but I think that it would be great to suggest users about using this library and how it can make their life's easier 👍

[sindresorhus]

// also @Blesh

[sindresorhus]

@thgreasi The user can export to any format at build-time. I don't see any point in adding that here.

I would prefer to leave localForage-observable with as little dependencies as possible

You already have a build-system for your module, so you can just bundle this module at publish time if you don't want an extra dependency.

but I think that it would be great to suggest users about using this library and how it can make their life's easier

The thing is. It only works if the libraries they depend on add it. They don't need to. So it's kind of a chicken-egg problem.

[sindresorhus]

And while I have you here, I just made https://github.com/sindresorhus/awesome-observables. Let me know if you have any suggestions ;)

[thgreasi]

@sindresorhus So, If I get it right, by doing a require('any-observable'), the choice of the Observable implementation used is left to the application authors.

• Is there a suggested ES6-like way to import (other than require('any-observable'))?
• How about the users that are using the RxJS umd package? I guess that require('rxjs/Observable').Observable will have no effect for them. Should we also try to retrieve the Rx.Observable from the global namespace?

[sindresorhus]

Is there a suggested ES6-like way to import (other than require('any-observable'))?

Same as require. You do const Observable = require('any-observable'); or import Observable from 'any-observable'; in your module. Your users do the same. They can also optionally manually set the Observable lib to use with require('any-observable/register')('zen-observable'), but it's normally auto-detected.

Should we also try to retrieve the Rx.Observable from the global namespace?

Yes, we could do that.

[jamestalmage]

the choice of the Observable implementation used is left to the application authors

Exactly, they just need to make sure the register function gets called before they load up your library that uses any-observable:

var desiredImplementation = require('rxjs/Observable').Observable;
require('any-observable/register')(desiredImplementation); // this must come before the line below 
require('localforage-observable');

Is there a suggested ES6-like way to import

As @sindresorhus stated, you can just do

import Observable from 'any-observable';

ES6 imports do present a problem for some code, since imports are hoisted.

The following will not work correctly:

import Observable from 'rxjs/Observable';
import register from 'any-observable/register';
register(Observable);
import 'localforage-observable'; // this is hoisted, so it actually occurs before the call to register()

To fix that, I've proposed #2, which would provide shortcut registrations for popular libraries.

import 'any-observable/register/rxjs'; // registers rxjs in a single import, avoiding the hoisting problem
import 'localforage-observable';

I think any-observable provides a nice solution for testing as well. For example, we will be adding observable support to execa, and while I may write my tests using a robustly featured Observable implementation like RxJs (taking advantage of all the goodies in the extended API to make my tests as succinct as possible), consumers are free to use a lighter weight Observable implementation in their own apps.

[jamestalmage]

Also, it's worth pointing out this idea is stolen from any-promise, that project is a pretty huge success (they clock nearly 20,000 daily downloads from npm).