These are chat archives for pozadi/kefir

10th
Jun 2015
Artem Kozlov
@aindlq
Jun 10 2015 12:15
hi, I'm trying to get rid off deprecated Kefir.emitter, and can't figure-out how to do this when I want to emit value from callback. I'm using React, and want to emit some values to stream on dom element events. But the problem is that I need to emit event from the callback that is passed to element like: DOM.input({onChange: function(event){}}). Any ideas how to do this properly?
Roman Pominov
@rpominov
Jun 10 2015 12:35

Yeah, React callbacks is the one case where I also find myself wanting Kefir.emitter or something similar. It kind of unique case, where you subscribe to something by constantly returning a callback as part of a render tree from render() function, and never "unsubscribe" manually. Streams just don't fit well to that pattern. Normally you should create a stream from some source, but it hard to create a stream from that kind of source.

But there is still few options. You can create a Kefir.pool(), and then do <input onChange={e => myPool.plug(Kefir.constant(e))} />. Also you can create a stream using Kefir.stream() in componentWillMount and extract emitter from it as shown here, but at the end you'll probably also plug that stream to some pool.

If you'll use Kefir.stream(), you also probably should end the stream in componentWillUnmount
Artem Kozlov
@aindlq
Jun 10 2015 12:37
yes, that is the way I'm doing this right now. Just thought maybe there is a better way, because it looks slightly ugly :)
I think I like Kefir.pool() idea, any ideas about memory consumption?
render() method can be called many times, an basically on each re-render new stream will be created, right?
Roman Pominov
@rpominov
Jun 10 2015 12:38

yes, that is the way I'm doing this right now

which one, myPool.plug(Kefir.constant(e))?

Ulric Wilfred
@shamansir
Jun 10 2015 12:38
honestly I’ll miss Kefir.emitter().
Artem Kozlov
@aindlq
Jun 10 2015 12:39
nope, right now I'm using approach described here https://github.com/rpominov/kefir/issues/88#issuecomment-92512136
with end of stream in componentWillUnmount
Roman Pominov
@rpominov
Jun 10 2015 12:41
I see, it probably better than .plug(Kefir.constant(e)) from perf perspective. But I wouldn't care about perf cost of .plug(Kefir.constant(e)), it shouldn't be too much.

an basically on each re-render new stream will be created

that not true, it will be created only when callback is called

Artem Kozlov
@aindlq
Jun 10 2015 12:46

that not true, it will be created only when callback is called

yes, you are right

and with Kefir.poll, do I need to cleanup resource in the end?
Roman Pominov
@rpominov
Jun 10 2015 12:49
Well, you cant't end a pool, but if you remove all subscribers from it, and kill all references to it, it will be garbage collected.
Artem Kozlov
@aindlq
Jun 10 2015 12:50
ok, thank you!
Roman Pominov
@rpominov
Jun 10 2015 12:51
no problem)
Roman Pominov
@rpominov
Jun 10 2015 12:59

honestly I’ll miss Kefir.emitter()

I still think it's an antipattern. Authors of most.js also don't want too add similar thing cujojs/most#72 . And in https://github.com/zenparsing/es-observable proposal there is no mention of something similar.

Btw, here some discussion on subscribing to events in React using most cujojs/most#133
Ulric Wilfred
@shamansir
Jun 10 2015 13:08
Yeah, I know, there’s a lot of discussions here and there. And it could be an antipattern indeed, I’ll try to change it in my code and see if it’s better with pool, I honestly use emitters a lot.
(But that’s what I actually liked in previous versions of Kefir API — along with performance and small size, it was friendly for the code readability, and not as strict as other libraries. When you see .emitter, it’s quite obvious what it does and how to use it, when you see pool.plug(…) for the same reason, it’s looks like hidden somewhere)
@Nek am I wrong in this? :)
Artem Kozlov
@aindlq
Jun 10 2015 13:13
@shamansir , I don't agree with you. At least from my experience Kefir.stream and all other options are more readable. With .emitter you have more moving parts
Roman Pominov
@rpominov
Jun 10 2015 13:23
@shamansir perhaps you should structure you code differently. You should find a ways to convert primary sources of events (like button clicks, etc.) to streams properly. Then declare streams relationships and dependencies. And at the end add side effects, by subscribing to some result streams.
.emitter is an imperative pattern, but we should seek functional and declarative patterns.
Roman Pominov
@rpominov
Jun 10 2015 13:34
To me React events is the only case where .emitter would be a valid choice, in almost all other cases there is better (more declarative) ways to create a stream from a source of events.
Ulric Wilfred
@shamansir
Jun 10 2015 13:34
@rpominov Basically I use emitters as signals from my code to start some streams manually, like a handle or a trigger. Since my code mostly based on events fired from my API, for me it’s also a way to quickly fire some event.
So it’s like me is the one who is the primary source of events :).
Roman Pominov
@rpominov
Jun 10 2015 13:36
Well, there still should be some deeper original source of events e.g., you click a button, which result to some logic in your API.
Events can't come from nowhere :)
Ulric Wilfred
@shamansir
Jun 10 2015 13:49
I suppose my events are more like commands in Flux (“Get money from an account”, “Put money to account"), as I got it from watching presentations of it. So seems I use Kefir to implement Flux pattern. May be the problem is that my code is not the end-code, but also an API itself :).
So end-user may call some API method from the code w/o any UI, and the UI itself may call the same API method to fire the same events. In first case, events come from nowhere).
Roman Pominov
@rpominov
Jun 10 2015 13:54

May be the problem is that my code is not the end-code, but also an API itself :smile:.

I see. Probably this is another valid case for emitter.

But there are still tons of invalid cases)
If I'd need something like emitter for a valid case, I'd create some helper that builds something like emitter in user land.
It's not too hard :)
There is even reference implementations in that github issue.
Ulric Wilfred
@shamansir
Jun 10 2015 13:59
Yeah, I’ve just seen it somewhere in your links. You’re right, my case seems to be a rare one).