I was blown away by David Nolen's articles on CSP using core.async when I first read them last fall, and the concepts have stuck with me and really started to shape my thinking on designing UI components.
De-complecting UI concerns into event stream handling, event stream processing, and ui representation makes a ton of sense. In a past life, I did a lot of integration work on asynchronous message-based systems, so this model of passing data through a pipeline of coordinated processes comes very naturally. That also seems to be the "functional" way of doing things (maybe that's why I had an easier time learning functional programming than most old guys like me). Conceptually, I see the "app-state" (whether it's a single atom or several) as the rendering target for my CSP processes, just as David renders to JS arrays in some of his CSP examples. Then the job of React should be simply to detect and respond to changes in this state. Essentially, a React component is just a transformation from this app state to a DOM, which happens to be the UI representation being used in this instance. This seems to be how Reagent works, which makes sense to me. But Om seems to want to take over the management of the app state itself, which seems like complecting to me. Now, David is a really smart guy, and has been working in this particular area a lot longer than I have, so I'm sure he has his reasons. I'm just trying to figure out what's missing from my conceptual model? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
