Open pepeiborra opened 7 years ago
Yes, I'm still planning to do replace the FRP implementation in Reactive.Threepenny and use Reactive.Banana instead. The reason I haven't done this yet is that Threepenny requires one or two weird primitives (e.g. for making domEvent
a pure function) that are not present in Reactive.Banana yet.
Would you accept contributions ? If there was a dev branch and a set of guidelines I might be able to help.
Sure, I'm happy to receive contributions! 😄
I used to have a develop
branch, but many people just submitted pull requests against master
, so I learned to make this work. So, just submit to master
if you like.
Since the project is still relatively small, I didn't make any formal guidelines. Use your best judgement; I usually review submitted code and give feedback.
That said, for this particular issue, it's probably fastest if I do the changes myself. The inner workings of reactive-banana are fairly complex and implementing the first missing primitive (Something similar to newEventsNamed
in Reactive.Threepenny) relies on unsafePerformIO
, which has all sort of unintended side effects (heh). The second missing primitive is about whether the UI
monad can be stacked on top of MomentIO
or whether a different solution is needed.
I intend to tackle these as I find free time; sorry that the state of FRP affairs in Threepenny is currently something unsatisfying.
The
switchE :: Event(Event a) -> m (Event a)
operation provided by reactive-banana is missing in threepenny. A while ago this question came up in stackoverflow.com and you mentioned plans to implement it in threepenny, or unify threepenny and reactive-banana. Are you still planning to do this ?I am writing a library of composable algebraic editors, and this comes up in trying to define the editor for a union type.