-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Handle all things asynchronous internally with RxJS #50
base: master
Are you sure you want to change the base?
Conversation
1e1c243
to
4926513
Compare
Hmm Looking at the code I guess this would be equivalent to overriding Thoughts? |
I like the idea of separating the serialization/deserialization process. Let me give it more thought as I'm still getting started with Observables. Also, the bundle size is huge with RxJS v4 as there is no way to cherry-pick methods. I'll have to switch to RxJS v5 and reimplement |
I'm still eyeing toward this by the way (cc @guyellis @princjef). I think it'd be a very nice way to implement a database driver and it will allow the addition of tons of new higher level features very easily. I was thinking about:
Observable are just so powerful. |
I only use |
I'm also working on https://github.com/jbmusso/zer which will basically allow us to do a |
Changes Unknown when pulling 1cc986a on rxjs into ** on master**. |
I'm trying to lower the size of the dependency as well as make it easier to add new features (throttling, auto reconnect, etc.). My goal is:
highland
andreadable-stream
dependenciesrx
lightweight dependency since I'm only using very few Rx operators internallyAll incoming and outgoing messages are now handled with RxJS streams. I'm unsure about the performance but I don't think this should be a concern when compared to network I/O.
Observable
are essentially higher level streams that can be converted to Node.jsStream
. They are currently a stage-1 candidate for addition to the EcmaScript standard. Upcoming RxJS v5 Observable tries to be compliant with the EcmaScript Observable Spec. I addedrx
v4 dependency since it's stable and offers more higher level methods absent inrxjs
v5, especially.pausableBuffer()
(absent in v5) which is quite handy for buffering outgoing messages until the WebSocket connection is actually open. I should add that regarding package names,rx
is stable v4 on npm whilerxjs
is experimental/beta v5 (or so I figured ?!).This cleans up the code quite a bit and also removes the
executeHandler
thing which I've never been a fan of.Most tests pass, except those related to the previous
Stream
API obviously (.stream()
and.messageStream()
). I currently added a public (though undocumented yet).observable()
method which currently returns an RxJS stream..execute()
now calls.observable()
internally.Question : do people even use
.stream()
and.messageStream()
? Even though these are public and documented methods, they've also been used internally by.execute()
(which I believe most people use). By using RxJS, these two stream methods will no longer be necessary internally and I could just drop them from the public API altogether. It's also worth noting thatObservable
can be easily converted to Node.jsStreams
with a third party library https://github.com/Reactive-Extensions/rx-node (I don't think it's worth adding a dependency for this considering how trivial it is).This PR is heavily experimental and I'll most likely send another clean PR when confident. This will most likely be a major version bump (3.x) depending on whether we want to keep the old Stream API or not.
Thoughts welcomed. Yeah, I'm looking at you @PommeVerte ;).