David, I would love to read this. I've spent a lot of time working through Om architectural patterns and I think I have a sense of what works and what doesn't, but getting a more comprehensive higher-level take from you would be great.
I also want to thank Sean Grove for putting Omchaya out there and helping to get these conversations going. Along those lines, Sean, I'd love to hear more about what you've learned recently as well, as you mentioned in another email in this thread. I would like to put a blog post out there as well once I've had more time to think things through and there has been more discussion of what good patterns are on the list. But I will give a quick very high-level overview of our front-end app structure: We have an Om app that uses a server-push mechanism resulting in global app state changing "from the top." Any requests to update state from the client app go directly to the server asynchronously. This is very clean and works quite well for us, but I understand this may not reflect a common architecture--it certainly obviates the need for something like om-sync, and it means we don't have a lot of calls to transact!/update! in our app--we let the server worry about how updates to app data should be managed (generally speaking). We also rely on a page/routing protocol mechanism for communication of global state changes between disparate components--"page partials" which may have a lifespan across page changes vs. "page components." Otherwise components within a page really only have local state changes to worry about, and we use the mechanism (which seems to have been somewhat codified) wherein state and a channel gets passed to a child component which then can transmit updates to state back up the hierarchy via the channel. This is very simple to use and also quite clean. There are a few places where we leverage Google UI widgets and while we saved some energy porting some older code over, it's definitely obvious that there is an impedance mismatch there--there are a ton of channels managing state changes, and I had to be very careful to play nicely with the React update cycle. Not to harsh on Omchaya--it's the only example that anyone has been courageous enough to put out there to bash on!--but some of its more channel-heavy code really reminded me of this. I'm starting to think it's a bit of a smell when building Om apps. Anyways--I have to get going but I'm really interested to hear from and discuss more about this with everybody. DD (2014/03/30 1:23), David Nolen wrote: > This is getting closer but I think will write up my own > thoughts/opinions on Om application architecture soon. While the > existing tutorials are nice for understanding how Om works, I think a > rough guide to architecting Om applications would be useful to all - not > the least because it will likely need many refinements as we put the > ideas into practice. > > David > > > On Sat, Mar 29, 2014 at 5:22 AM, Daniel Bell <[email protected] > <mailto:[email protected]>> wrote: > > So, I figured it out, and wrote a blog post on why this is a > terrible idea: > > http://roninhacker.wordpress.com/2014/03/29/how-to-build-stuff-with-om/ > > -- > 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] > <mailto:clojurescript%[email protected]>. > To post to this group, send email to [email protected] > <mailto:[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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[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.
