Have we considered using named exports for specific methods so that we don't immediately require the entire RxJS bundle on behalf of the user (of this library)?
It would mean replacing this:
var Rx = require("rxjs/Rx");
...
subjectFactory: function () { return new Rx.Subject(); },
With this:
var Subject = require("rxjs/Subject").Subject;
require('rxjs/add/operator/filter');
...
subjectFactory: function () { return new Subject(); },
The benefit is that we are no longer pulling in the entire RxJS library for this library to work. But the downside is that the user needs to manually add in their own methods (because the observable passed to them will be "barebones").
For example, the observable the user gets back from fromComponent() will not have methods like .share() or .debounceTime(). They would need to add it themselves explicitly like this:
import 'rxjs/add/operator/share';
import 'rxjs/add/operator/debounceTime';
One option to get around this is to simply provide both options to the user. Maybe something like this:
// Imports the whole RxJS bundle
import { observeComponent, fromComponent } from 'observe-component/rxjs/full';
// Imports only the necessary objects and methods
import { observeComponent, fromComponent } from 'observe-component/rxjs';
The library might get bigger, but this gives the developer much more control if he wants to keep the bundle size small for production
Have we considered using named exports for specific methods so that we don't immediately require the entire RxJS bundle on behalf of the user (of this library)?
It would mean replacing this:
With this:
The benefit is that we are no longer pulling in the entire RxJS library for this library to work. But the downside is that the user needs to manually add in their own methods (because the observable passed to them will be "barebones").
For example, the observable the user gets back from
fromComponent()will not have methods like.share()or.debounceTime(). They would need to add it themselves explicitly like this:One option to get around this is to simply provide both options to the user. Maybe something like this:
The library might get bigger, but this gives the developer much more control if he wants to keep the bundle size small for production