-
-
Save takeoutweight/6311241 to your computer and use it in GitHub Desktop.
behave1 = ...//some FRP behaviour of Number | |
behave2 = ...//some FRP behaviour of Number | |
behave3 = ReaCtx.with(function(re) { | |
if (re.val(behave1) < 50) { | |
return re.val(behave2) + 1000; | |
} else { | |
return 3; | |
} | |
}); | |
// behave3 will update when behave1 changes | |
// it won't even respond to changes in behave2 until behave1 is first seen to be < 50 | |
// Crucially, there is no precompilation like FlapJax, and no manual lifting like Elm -- just JavaScript expressions |
Neat! I assume re.val() operates by throwing?
A danger would be side-effecting functions – this would leak out of the abstraction. (Still want Javascript continuations.)
Yep - it would need to throw in the case of Options or Futures. You wouldn't have to for FRP contexts as behaviours can deliver a value whenever they exist.
Definitely not equivalent to real effect handlers for the reasons you point out -- effectful values from the real world won't be closed over but recomputed every update. I suppose, as always, practical use-cases are needed to see what kind of confusion this might cause. I am optimistic because this is operationally similar to how Clojure's STM transactions behave: it seems to work okay just asking devs to be a bit more careful with effects when you're in a transaction context.
Also, I think this approach would work for lots of Applicative-style expressions. I think it would work for nicely for computing with Futures or over Option types, for example.