On Saturday, January 25, 2014 10:38:14 AM UTC-5, David Nolen wrote:
> On Sat, Jan 25, 2014 at 3:57 AM, Jonas Enlund <[email protected]> wrote:
> 
> 
> 
> 
> On Saturday, January 25, 2014 9:49:56 AM UTC+2, David Nolen wrote:
> 
> > Nice. I do consider the non-modularity of `update-contacts!` here to be one 
> > of the big things I try to address in Om. The Reagent `update-contacts!` 
> > knows too much. In Om, it doesn't matter at all where :contacts lives in 
> > the app state, the Om contacts-view can still update it.
> 
> 
> 
> 
> So if I understand correctly the 'app' arg in (defn contacts-view [app owner] 
> ...) doesn't have to be the root of the app-state atom?
> 
> 
> It can be at any location in the app state and it will always work. This is 
> important for component composition and re-usability.
> 
> 
> 
> If I was to describe the difference between Om and Reagent it would be that 
> Om is draconian about component modularity in order to encourage component 
> reuse. Directly manipulating the app state from a component in Om is a 
> anti-pattern. Components communicating with each other via functions is also 
> an anti pattern (use channels).
> 
> 
> 
> DavidĀ 

One thing that's important to note is that code clarity is equally as valuable 
as reusability. In this particular example we're talking about making 3 lines 
of code reusable at the cost of adding additional complexity to the code base.

I come from Java background where the culture of making things generic for the 
sake of genericity is taken to the extreme. This often results in code that's 
much more opaque, difficult to reason about, and harder to maintain than 
non-reusable code would have been.

When it takes more work to reuse a components than to write them from scratch 
the value of reuse becomes questionable. You often end up with a lot of 
incidental code that obscures the purpose of the program.

While Om approach is much more prescriptive when it comes to making reusable 
components that doesn't always result in code that's easier to reason about and 
maintain.

-- 
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.

Reply via email to