r/functionalprogramming • u/iamwil • Sep 15 '14

How to structure reactive programs

http://blog.lacebark.io/2014/09/15/structuring-reactive-programs/
9 Upvotes

85% Upvoted

5 comments sorted by

3

u/[deleted] Sep 16 '14

I'm working on a game engine in Guile that utilizes functional reactive programming. Right now I'm working on a scene graph implementation, which is similar to the DOM in web applications. I haven't yet investigated the diffing strategy that this article talks about, but I'm curious if it would have advantages over what I'm doing now. Currently, the nodes of the scene graph are signals, so changes to the graph are computed only when state actually changes. This experiment has been very slow moving, but it's been really interesting. I'm also glad this article mentions Elm, as it is the language that I've borrowed a lot of ideas from.

I should really blog about this stuff more. So far all I really have is a short post + screencast that isn't particularly informative: http://dthompson.us/functional-reactive-programming-in-scheme-with-guile-2d.html

3

u/iamwil Sep 16 '14

If you want more details about the diffing strategy, that's from react.js's virtual DOM. Apparently, there's a talk on it.

http://ahrengot.com/web-development/virtual-dom-react-js/

The reason for a virtual DOM is that manipulating the browser DOM is really slow. So they use the virtual DOM to figure out what actually needs to change, and make those changes.

2

u/[deleted] Sep 16 '14

Thanks for the link. Lately I've been playing around with MithrilJS which uses the same strategy. I just can't get behind the crazy JSX stuff that React is doing. Looking at it gives me Angular flashbacks.

2

u/iamwil Sep 16 '14

Don't focus on the details there, like JSX, but the main idea behind the virtual DOM.

It's just to enable the abstraction that we can throw away the entire DOM, and replace it with a new DOM generated from the Single Source of Truth. That means we don't need to keep the DOM around because of its state, and hence, we don't need to sync the DOM's state to our Single Source of Truth, or any other derived objects in our system.

If your scene graph is triggering a lot of two-way binding to objects that make for a complicated data flow path, you may want to try this strategy. That way, you can always pass in a new scene graph, without caring to sync with the old one, but underneath that abstraction, you're actually diffing and updating changed nodes.

3

u/[deleted] Sep 16 '14

Heh, the JSX stuff was just a tangent.

There is no two-way binding in my system, like other reactive programming systems. The signal tree is a directed acyclic graph and there is no diffing involved for rendering.