Skip to content
This repository has been archived by the owner on Jun 4, 2019. It is now read-only.

Named export for requiring RxJS #8

Open
adrianmcli opened this issue Jan 9, 2017 · 2 comments
Open

Named export for requiring RxJS #8

adrianmcli opened this issue Jan 9, 2017 · 2 comments

Comments

@adrianmcli
Copy link

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

@adrianmcli adrianmcli changed the title Named export for Named export for requiring RxJS Jan 9, 2017
@lilactown
Copy link
Owner

lilactown commented Jan 9, 2017

That's a really good point. Controlling bundle size is a big deal today with so many large front-end applications, often supported by even larger libraries.

My instinct is to go with "easy/ergonomic by default," which is why I'm leaning towards leaving it as is. Perhaps instead of offering an rxjs/full option, instead having an rxjs/lite for people who desire more fine-grained control over which RxJS methods are imported?

@adrianmcli
Copy link
Author

Yeah that's a good point. I can make a stab at doing this over the weekend, but unfortunately I don't know any Typescript. I just started a new job which requires Typescript though, so I'll probably be able to help very soon!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants