On Thursday, January 23, 2014 10:13:49 AM UTC-8, David Nolen wrote: > Om's current API more or less follows this line of thinking - components are > machines. However both the opaque nature of machines and the lack of fine > grained control around immutable value storage (app state wrapped in an atom) > have their downsides. I want Om components to have knobs. So while a > component designer may decide to split their state in a certain fashion - > users of the components should be able to reconfigure this without the system > falling apart.
I am enjoying the ability to add behaviours to components via merging data into local component state. It's quite handy when trying to achieve orthogonal separation of concerns. For example - one might have several components on a page. Perhaps their primary purpose is to display certain items in various ways. Perhaps you have a group of items you want to split into different lists based on classification rules. One way to do this is to extend your sub-components, or to wrap them in a bigger component that manages the communication between them. Using Om's opts, local-state, and shared, lets me put all the logic (and inter-component communication necessary) for drag-n-drop into a separate namespace, and then I can pull into the components the DnD behaviour, and implement the few handler functions for the stuff that's specific to each component's concern (e.g. mutate app-state on a drop). Now, I've been dwelling in OO/Imperative land for a long time, so I'm sure there are cooler ways to do all this.. but I'm having fun with it :D -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
