Virtual DOM in Elm

Another Elm inspired approach is re-frame (https://github.com/Day8/re-frame) which is a framework for writing SPAs in Reagent (http://reagent-project.github.io).

re-frame doesn't get enough love so here's an overview. re-frame encourages you to keep the state of your app in one map and treat it like a database. re-frame has 4 main parts:

- DB: where your global, shared state is stored. If that sounds scary and you use databases often, that's logically inconsistent. The DB is usually a map in an atom. (so it is mutable via transactions).

- Views: Reagent components. for an aweosome live example checkout http://reagent-project.github.io

There are 2 ways for views to interact with the db - via dispatching handlers and subscribing to subscriptions.

- Handlers: analogous to stored procedures on the database. Handlers are pure functions that act on the database. The value returned by the handler is the new value of the DB. The handler gets registered and can be used as a high level declarative function from the views. Here's an example from our current app:

    (register-handler
     :cart-order-failed
     (fn [db [_]]
         (assoc db :cart-order-failure true)))

- Subscriptions: analogous to materialized views on the database. Allows you to watch a specific part of the state-map, do some computation, and rerun only when that specific part is updated. Here's another example:

    (register-sub
     :user-info
     (fn [db [_]]
         (reaction (->
                    ;; never give out the password if it's there
                    (get @db :user)
                    (dissoc :password)
                    (dissoc :pass2)))))

So the data flows like this:

      DB -> Subscription
       ^             |
       |             v
    Handler   <-   View

The view also turns into a react.js component and is rendered to the vdom using immutable data structures, but that's Reagent not re-frame.

Semi-tangential note: React comes with the helpful `React.addons.update`, which implements "immutable data structures" in an extremely simple way.

I'm working on a medium-sized React application where all application state changes go through this function—there's one big state object with all substate, and we don't do any mutation inside of it. We haven't needed to benchmark anything yet, nor do we have any extreme performance requirements.

Since all our state updates work like this, we can use `PureRenderMixin` on all components, which gives us the kind of shallow equality behavior you describe.

According to the git history, it was posted June 16, 2014 (1136ce4).

Do you recall any specifics? I used Elm for a couple of weeks but found no unexpected behaviors in the batteries included.

Could you give some examples of the bugs you found? I would like to contribute to elm and this looks like a good place to do it.