I also use an "invisible" management component to handle updates from outside of Om. Works great.
If you wrap your root with this component, everything should work just fine, but if you create go blocks inside components that can be unmounted, you have to remember to kill the go block from IWillUnmount or it will stick around after the component is unmounted - if the component gets mounted again, you will have two go blocks running! And while its unmounted, accessing owner will cause problems. The way to fix this (other than avoiding go blocks in components that might unmount) is to close the channel being listened on in IWillUnmount (if this component owns the channel) or use core.async/alt to listen on a "kill" channel as well as the actual channel if this component does not own the channel, then simply close the kill channel in IWillUnmount. This way go blocks only exist while the component is mounted. On 22 June 2014 14:51, Dave Della Costa <[email protected]> wrote: > Sure, the main reason for us is to keep things modular. It makes it > simpler to restructure things, since it's just another component. > > We wrap our root component in this "invisible" component, so it just > calls build on the root component itself (that is, the invisible data > listener component becomes the actual root component). > > (2014/06/22 22:28), Andrew Stoeckley wrote: > > Ok thanks guys, that provides some confidence. That other thread also > > mentioned having an invisible Om component do the listening. Not sure > > I understand the point of that; why not just add the go block to > > anything already in the IWillMount of your root Om component? If you > > were to make it invisible, just put an empty om/div on there with no > > contents? (since a component must be returned) > > > > On Sun, Jun 22, 2014 at 9:24 PM, Gary Trakhman <[email protected]> > wrote: > >> Let's also not forget that JS is single-threaded. I'm guessing all the > >> components will be recursively mounted before the contents of the go > block > >> can do anything at all. > >> > >> > >> On Sun, Jun 22, 2014 at 9:20 AM, Dave Della Costa < > [email protected]> > >> wrote: > >>> > >>> Hi Andrew, > >>> > >>> We ended up doing exactly the sort of thing you describe. We have a go > >>> block inside IWillMount, listening for messages from the server (in our > >>> case via browserchannel, but exact same idea). Inside this go block we > >>> apply updates from our server by calling transact! on the app data. > >>> > >>>> Since the block is asynchronous, couldn't the Om protocol (whichever > >>>> one is best) return before the go block actually does anything? Or > >>>> what happens when the go block does something at a different time > >>>> than the Om protocol is getting called? > >>> > >>> componentWillMount (a.k.a. IWillMount in Om) is called once at the very > >>> beginning of the React lifecycle > >>> > >>> ( > http://facebook.github.io/react/docs/component-specs.html#mounting-componentwillmount > ), > >>> so it's not going to cause the kind of strange behavior you're > concerned > >>> about. If a message comes in and transact! gets called, an update will > >>> be scheduled and rendering will happening as expected. > >>> > >>> DD > >>> > >>> (2014/06/22 21:24), Andrew Stoeckley wrote: > >>>> I was reading this thread: > >>>> > >>>> > https://groups.google.com/forum/#!msg/clojurescript/V5J1Rf0k84M/JgspX_AyoGgJ > >>>> > >>>> It was suggested that all state changes to the Om atom should occur > >>>> within an Om component. Currently I am swap!ing outside Om. > >>>> > >>>> A lot of my state changes are the result of an infinite <! loop > >>>> inside a go block, which is reading a websocket. What happens if I > >>>> put this inside an Om component, and where is the best place to do > >>>> so? IWillMount? > >>>> > >>>> Since the block is asynchronous, couldn't the Om protocol (whichever > >>>> one is best) return before the go block actually does anything? Or > >>>> what happens when the go block does something at a different time > >>>> than the Om protocol is getting called? > >>>> > >>>> Or perhaps more likely there is a better way. Any suggestions on good > >>>> approach here are appreciated. > >>>> > >>> > >>> -- > >>> 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 a topic in the > >> Google Groups "ClojureScript" group. > >> To unsubscribe from this topic, visit > >> https://groups.google.com/d/topic/clojurescript/DHJvcGey8Sc/unsubscribe > . > >> To unsubscribe from this group and all its topics, 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. > -- 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.
