I think integrating non-React components is always going to be a bit of a hack and there's not really much we can do about it: mutable component -> immutable component is going to have mixed results. At least it can be done and I would not consider the difficulties a smell but rather a fundamental impedance mismatch.
On Sunday, March 30, 2014, Dave Della Costa <[email protected]> wrote: > 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]<javascript:;> > > <mailto:[email protected] <javascript:;>>> 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]<javascript:;> > > <mailto:clojurescript%[email protected] <javascript:;> > >. > > To post to this group, send email to > > [email protected]<javascript:;> > > <mailto:[email protected] <javascript:;>>. > > 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] <javascript:;> > > <mailto:[email protected] <javascript:;>>. > > To post to this group, send email to > > [email protected]<javascript:;> > > <mailto:[email protected] <javascript:;>>. > > 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] <javascript:;>. > To post to this group, send email to > [email protected]<javascript:;> > . > 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.
