Reactive Magic

Hey there, just thought you might be interested in a little library I build on top of Flyd called Reactive Magic.

Perhaps the most interesting thing is how you magically combine streams:

const x = Value(1)
const y = Value(1)
const z = Derive(() => x() + y())

I built some abstractions and created an interesting React API. Its pretty neat actually. I don’t like how magical it is in some ways, but it actually makes it much faster to build things.

[paldepind]

Hello @ccorcos.

Thank you for sharing the library. That is pretty cool 😄 Back when I wrote Flyd I actually toyed with a similar idea myself. I agree with you that while it looks very cool it can seem a bit too magical.

it actually makes it much faster to build things.

I’d like to hear more about that and your experiences. As far as I can see it actually doesn’t offer that much.

The example you posted could be created with lift almost as easily.

const x = stream(1);
const y = stream(1);
const z = lift((x, y) => x + y, x, y);

And in my opinion the latter code has the advantage that the logic (the addition) is a “plain” function. This has the benefit that I could just as well throw in R.add.

const x = stream(1);
const y = stream(1);
const z = lift(R.add, x, y);

Again, thanks for sharing this. I’d love to hear more 😄

[paldepind]

@ccorcos Thank you for sharing your initial concerns. I really appreciate it.

Turbine looks really cool! Its basically Cycle.js from what I can tell. A couple concerns of mine:

I get why you say that. At first sight, it has some resemblance to Cycle. That is not a bad thing, Cycle is great in many ways. But there are actually many differences. The more you look at it the less it looks like Cycle I’d say 😉 Here are some of the differences:

• In Cycle the is one cycle. In Turbine each component has its own independent cycle as you can see here. On top of that one can create additional cycles if there are additional circular dependencies.
• We do not use selectors to get events from the DOM. Instead, our Component is a structure that returns streams along with the DOM it represents. Also, the desired output is explicitly declared in the view.
• There are no drivers. Instead, we use a library, IO, to express imperative code in a way that I think is more convenient.
• Turbine is completely pure. We are more strict in this regard.
• Our FRP library Hareactive is very different from RxJS.
• We don’t use virtual DOM. Behaviors/streams are plugged directly into the view and you don’t have to merge into a single state-stream.

Overall I’d say that Turbine has a slightly higher learning curve because we use some more advanced ideas from functional programming (monads, for instance, are crucial to our approach). But I hope the final experience is a framework that’s more convenient and powerful to use.

1. In this example here, the return value of the view needs to be parsed in order gather the outputs and pass them to the model. This seems nontrivial to implement and nontrivial to maintain typesafety.

You are definitely right that it is non-trivial to implement. We have to pull some tricks to establish the circular dependency. But conceptually it’s quite simple to understand. Creating types for it is actually easy. modelView (the function that creates components with separated model and view) has a type like this (I’ve removed some details):

function modelView<M, V>(
  model: (v: V) => Now<M>, view: (m: M) => Component<V>
): Component<M>;

As you can see, M is that value that the model function returns (the left side in the figure you posted) and V is the output from the view (the right side). The types say that the output from one of them must match the input to the other one. If they don’t it results in a type error.

1. In my purely functional experiments, I find myself spending a lot of time trying to partially apply callback functions while maintaining performance (you cant referentially diff these functions). So I’m curious how would create an arbitrary list of counters while binding the index of the counter to the callback function. Or how would you pass a “prop” to the counter (like an incBy number) that gets passed through to the model?

I don’t understand what you mean here. What sort of callback functions do you mean? I don’t think they exist in Turbine. We have a special function list for creating lists. The list function takes a dynamic list (a behavior of a list) and uses the data in the list to create components. It then collects the output from each components. We have a counters example that creates an arbitrary list of counters.

I’m not sure if that explanation makes sense or answers your question 😢. If you could expand a bit more on the question I’d like to give a better answer and/or concrete code that implements what you ask for 😄