Define rx.lite.js

[mattpodwysocki]

Until we have custom builds under hand, would it make sense to create a smaller version of RxJS called RxLite which has a few operators. Which operators might fit?

Thoughts include the following:

Creation Operators

• create
• createWithDisposable
• empty
• fromArray
• fromCallback
• fromEvent
• fromEventPattern
• fromNodeCallback
• fromPromise
• interval
• merge
• never
• repeat
• return
• timer

Combinators

• do
• map/select
• filter/where
• flatMap/selectMany
• flatMapLatest/selectSwitch
• combineLatest
• zip
• distinctUntilChanged
• concat
• concatObservable
• merge
• mergeObservable
• multicast
• publish
• publishLatest
• publishValue
• repeat
• replay
• skip
• skipUntil
• skipWhile
• take
• takeUntil
• takeWhile
• throttle
• timestamp
• timeinterval
• toArray

Any that I'm missing that are high priority?

[theghostbel]

skip/take subset, connect (as far as we have publish), selectProperty, repeat (if we'll include skip/take), merge

[mattpodwysocki]

Ok, added those.

[cwharris]

Publish is super important. I'm glad we added those. Looks good to me.

If Erik were here, I'd hope he'd make a joke about RxLite just needing SelectMany. :)

[mattpodwysocki]

@cwharris it is true that you can write most operators in terms of selectMany but in the case of RxJS, selectMany is nothing more than select and mergeObservable

[mattpodwysocki]

All the tests pass for now but here's what I have Feedback welcome!

Ok, how about the following so far:

• rx.lite.js
• rx.lite.compat.js

To see what's in there, here's the GruntFile which has the highlighted operators. I might have too many on the time-based side, but would love feedback!

[RainerAtSpirit]

The "lite" version looks heavy to me.

rxlite.js: 5080 lines (4663 sloc) 210.757 kb

rxjs.js: 4301 lines (3915 sloc) 171.923 kb

[mattpodwysocki]

@RainerAtSpirit It is, but you have to realize, it has all the bindings, async/fromEvent/Promise/Callback stuff in addition to standard operators. Thus you don't need to bring in multiple files. I'd like to know which operators you think aren't needed.

[RainerAtSpirit]

Based on the description above I wasn't expecting a "all-inclusive" lite version, thanks for the clarification. re operators: started using rx.js just recently, so I don't feel comfortable recommending yet.

[mattpodwysocki]

@RainerAtSpirit @theghostbel @cwharris should we drop all notion of absolute time here? That might help file size since in JS, we'd rarely use that anyhow. Nothing is stopping you from doing:

var ts = 5000; /* ms */
var scheduleTime = new Date(Date.now() + ts);

var timer = Rx.Observable.timer(scheduleTime - Scheduler.now());

[cwharris]

I don't see any real need for absolute time. The cases in which one might need that seem far a few between, unless you're using it for testing, in which case you could presumable hot-swap rx.lite for the usual rx libraries.

[thlorenz]

As mentioned on twitter, IMO it'd be better to create actual separate repos for each module that addresses a clear separate concern.

For example all the from* modules could live together in one separate repo since they deal solely with conversion. Then all conversion tests would live in that same repo as well.

You'll probably also have some module which provides core rxjs functionality. Most likely all other modules will depend on it and need to be able to install it. So it makes sense to create a separate repo (including tests, etc.) for it as well.

For lots of the combinators the concerns are pretty much nicely spelled out with the name already. So if it doesn't make sense to have three packages for each of the publish functions, they could be combined in a rx-publish repository and maintained there.
Same goes for skip, take, etc.

The creation combinators should each be in a separate package, except for maybe create*.

Additionally when I require one of them, if possible they shouldn't just attach themselves to a prototype, but instead return me a function that I can call.

If however a mixin to the prototype is the only way to do this, it should be thoroughly documented what kind of functions are added where, since it's not as obvious at that point.
Ideally each require call would only mixin one function.

[Raynos]

If you wanted to break up RxJS into smaller modules (this may not even be worthwhile) I would look into splitting the core primitives into seperate packages. Like the pull system (observer) and the push system (observable).

I would also look into how the scheduler could be broken out to be optional and have each scheduler type be a package. You could also put the test helping primitives into a seperate package.

You don't need to break out all the functions that operate on Observer or Observable out. You can put all the Observer methods in rxjs-observer if you want and all the Observable methods in rxjs-observable

However functions like

• fromArray
• fromCallback
• fromEvent
• fromEventPattern
• fromNodeCallback
• fromPromise

Could be broken out into a rxjs-from module

• generate
• generateWithAbsoluteTime
• generateWithRelativeTime

And those could be broken out into an rxjs-generate module.

Note that if you do break out these functions, this style of seperating modules work cleaner in a functional style like generateWithAbsoluteTime(observable, ...) instead of having them be methods on the Observable primitive type.

Again this type of seperation is only worthwhile if you think these ideas can work together cleanly. It's definitely a lot easier if you don't have prototypical interface with 50 methods. Having seperate modules mutating a shared prototype leads to disaster if you ever include two versions of rxjs-from in your app (in different locations in your dependency tree at different depths / branches).

[mattpodwysocki]

For now closing this as lite is good enough, and then creating smaller ones based upon this.