These are chat archives for pozadi/kefir

22nd
May 2015
Juha Paananen
@raimohanska
May 22 2015 09:10
Hi @pozadi, did you get to a conclusing regarding discarding Property value when it's unsubscribed?
I thought it'd be a good idea to do that for non-ended Properties, but found an unfortunate edge case
It feels a bit strange that if you pick the current/initial value with a take(1) subscriber, the value will be immediately lost for the next one. Not sure how to proceed from here. Gotta think. Ideas?
Juha Paananen
@raimohanska
May 22 2015 09:20
oh, you're @rpominov now :)
Roman Pominov
@rpominov
May 22 2015 09:23
yep, renamed myself :)
regarding removing current value on end, I almost certain we shouldn't do that
there is some technical issues with it, as (in Kefir at least) before end always happen a deactivation, and we remove current value on deactivation. But this is implementation detail.
perhaps, we could remove previous current on the activation instead
@raimohanska ^
Juha Paananen
@raimohanska
May 22 2015 09:44
maybe, but that wouldn't fix the problem with the transient subscriber snatching the value in my test case
unless we do some nasty checks
which I cannot figure out
Roman Pominov
@rpominov
May 22 2015 09:45
ah, I see
Juha Paananen
@raimohanska
May 22 2015 09:45
And I wouldn't want to complicate things
Roman Pominov
@rpominov
May 22 2015 09:46
so the next subscriber misses the initial 0 right?
Juha Paananen
@raimohanska
May 22 2015 09:46
yup
Roman Pominov
@rpominov
May 22 2015 09:50
I think, we should treat initial value differently. The Property should fallback to the initial value on each activation. But for this to work well, initial value should be defined as a callback, so on each activation property will get a fresh one.
This already done in Kefir, btw.
Juha Paananen
@raimohanska
May 22 2015 09:58
that's a pretty big re-definition of Property
Or should we call it Behaviour :)
Roman Pominov
@rpominov
May 22 2015 09:58
:)
Juha Paananen
@raimohanska
May 22 2015 09:58
I thought really hard if I should call the guy Behavior in the very beginning. But I just liked Property more.
The Behavior term is of course well established in the FRP world, but for Javascripters I it might have a weird sound. At least for me it's weird :)
But them again it's just me
For all cases I've used Property for, it always just gets a value from an underlying stream, so the callback thing would not really help
Roman Pominov
@rpominov
May 22 2015 10:02
it probably stay "Property" in kefir, otherwise there will be a lot of confusion because it still will be called "Property" in all discussions before the rename
Juha Paananen
@raimohanska
May 22 2015 10:02
I like Elm's Signal very much. That would be my choice
I agree with you. I don't think renaming is a good idea at this stage
Maybe we'll make a whole new library where there are just Signals :)
Roman Pominov
@rpominov
May 22 2015 10:05
about callback, if you're getting value updates from underlying stream, then you can't define proper initial value anyway (example: mouse position)
so in this case you just don't define it pos = mouseMoves.toProperty()

Maybe we'll make a whole new library where there are just Signals :)

tried this, btw, at one point there was only properties in Kefir, didn't go well though :)