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

combine is a stream, not a property #44

Closed
kcarnold opened this Issue Feb 4, 2015 · 3 comments

Comments

Projects
None yet
3 participants
@kcarnold

kcarnold commented Feb 4, 2015

I was trying to do something like https://github.com/niklasvh/react-bacon-flux-poc/blob/master/lib/store.mixin.js in Kefir (see the blog post) and ran into trouble. A minor problem is that Kefir lacks combineTemplate. The major problem, though, is that Kefir's combine, unlike Bacon's, is always a stream, which means that I don't get the initial values of the properties that go into it -- which means I can't get an initial component state until one of the source streams yields an event.

What's the rationale for having combine be a stream? And any ideas on how to implement something like that state-management pattern (or something even better) in Kefir?

@rpominov

This comment has been minimized.

Show comment
Hide comment
@rpominov

rpominov Feb 4, 2015

Member

You can always convert it to a property: Kefir.combine([a, b]).toProperty() should work same as default Bacon .combine.

What's the rationale for having combine be a stream?

Why not stream? :) If you combining two streams it intuitive to get a stream. We could decide what type of observable to return based on what observables being combined (p+p=p, s+s=s, s+p=?), but it'll only be more confusion. I think it better if a method always return same type.

Member

rpominov commented Feb 4, 2015

You can always convert it to a property: Kefir.combine([a, b]).toProperty() should work same as default Bacon .combine.

What's the rationale for having combine be a stream?

Why not stream? :) If you combining two streams it intuitive to get a stream. We could decide what type of observable to return based on what observables being combined (p+p=p, s+s=s, s+p=?), but it'll only be more confusion. I think it better if a method always return same type.

@dchem

This comment has been minimized.

Show comment
Hide comment
@dchem

dchem Feb 4, 2015

Just chiming in to say that it definitely makes sense for result of a combine to be a stream, at least for me. In my simple example (https://github.com/dchem/node-ibapi-addon/blob/develop/examples/atsExample.js) I do something like this:

//    [Currency Data Stream]
//       |
//       |-->[svrError]-->(print it)
//       |           
//       |-->[tickPrices]-->(print it)
//                 |
//                 |-->[bid prices]--|
//                 |                 |-->(calc midpoint price)
//                 |-->[ask prices]--|         |
//                                      [last n prices]
//                                             |
//                                             |-->(isBuySignal?)-->(buy)
//                                             |
//                                             |-->(isSellSignal?)-->(sell)

and combining bid and ask data stream to yield another stream makes intuitive sense to me. Just my two cents.

dchem commented Feb 4, 2015

Just chiming in to say that it definitely makes sense for result of a combine to be a stream, at least for me. In my simple example (https://github.com/dchem/node-ibapi-addon/blob/develop/examples/atsExample.js) I do something like this:

//    [Currency Data Stream]
//       |
//       |-->[svrError]-->(print it)
//       |           
//       |-->[tickPrices]-->(print it)
//                 |
//                 |-->[bid prices]--|
//                 |                 |-->(calc midpoint price)
//                 |-->[ask prices]--|         |
//                                      [last n prices]
//                                             |
//                                             |-->(isBuySignal?)-->(buy)
//                                             |
//                                             |-->(isSellSignal?)-->(sell)

and combining bid and ask data stream to yield another stream makes intuitive sense to me. Just my two cents.

@rpominov

This comment has been minimized.

Show comment
Hide comment
@rpominov

rpominov Feb 9, 2015

Member

Ok, I guess we're good here. Closing.

P.S.
I've added a "Current values/errors in streams" section to the docs (it's slightly related to this issue).

Member

rpominov commented Feb 9, 2015

Ok, I guess we're good here. Closing.

P.S.
I've added a "Current values/errors in streams" section to the docs (it's slightly related to this issue).

@rpominov rpominov closed this Feb 9, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment