Yes, in a way Reagent's model is probably more DOM-centric (or UI-centric, DOM is such an ugly word :)).
Just to make one thing clear: you definitely don't *have* to pass UI definitions to children - component functions can take any arguments, and typically you would give them something that's a lot easier to handle than a structure you would have to tree-walk. So there's no "data representation constraint" whatsoever on their arguments. They must *return* something that can be rendered, though. So, for a pure function [my-component x1 x2] is semantically identical to (my-component x1 x2) typically. The only difference is that in the first case the function isn't actually called until render time, and doesn't get re-evaluated if its arguments don't change. Totally agree about the tradeoffs. But that's where all the fun is to be had :) /dan On 6 mar 2014, at 23:30, David Nolen <[email protected]> wrote: > On Thu, Mar 6, 2014 at 4:48 PM, Dan Holmsand <[email protected]> wrote: > For example, if you have: > > [:div > [my-component > [:span "foo"]]] > > my-component is passed the span thing as a normal vector, and is free to do > whatever it likes with it (replace every :span with :blink, translate "foo" > to Swedish, animate it, store it somewhere else for later use, etc). If the > UI definition is opaque (as in plain vanilla React), there's much less you > can actually do with it (basically either render all the children, or don't). > > I'd argue that this still a DOM-centric point of view that emphasizes > manipulating a DOM representation even if the manipulation is incredibly > expressive. In Om data-centrism occurs immediately with the application state > and all interesting manipulation of the UI happens on the *original* data - > React DOM and Om components are just pluggable details. Your example of > replacing "foo" is actually illustrative of the fundamental difference - > you've settled on a Hiccup representation forcing all subsequent > transformations to necessarily be tree walks. In Om no such data > representation constraint has been imposed. > > Again this all boils down to tradeoffs and which parts of the respective > systems are simple / easy. > > David > > -- > 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. -- 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.
