Comments (13)
skip/take subset, connect (as far as we have publish), selectProperty, repeat (if we'll include skip/take), merge
from rxjs.
Ok, added those.
from rxjs.
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. :)
from rxjs.
@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
from rxjs.
All the tests pass for now but here's what I have Feedback welcome!
Ok, how about the following so far:
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!
from rxjs.
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
from rxjs.
@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.
from rxjs.
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.
from rxjs.
@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());
from rxjs.
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.
from rxjs.
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.
from rxjs.
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).
from rxjs.
For now closing this as lite is good enough, and then creating smaller ones based upon this.
from rxjs.
Related Issues (20)
- (SystemJS) XHR error (404 Not Found) loading http://localhost:1762/node_modules/rxjs/operators.js HOT 1
- Import of switchMap from rxjs/operators is not working. HOT 1
- startWith undefined on aot build HOT 1
- Spy on observables with Rx 5.5
- Unable to display object elements inside a main object HOT 1
- fetch data from a database using observables HOT 1
- old-way rxjs operators and factory methods vs lettable ones HOT 2
- Installation proble of Angular IDE
- bower install by default gives version 4 HOT 1
- documentation missing for Observable#subscribe() HOT 2
- jQuery promises are not working with retry HOT 1
- source.lift is not a function
- question about buffer operators HOT 2
- flatMap "this" referring to MergeMapSubscriber
- [rx-lite] Passing a non-natural number to repeat causes infinite loop
- How is my implementation of Observable? HOT 3
- How am I supposed to import observable methods?
- takeUntil does not complete delay HOT 1
- Update the google coding style link in wiki
- rxjs-compat subscribe have no effect HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rxjs.