I have a go block in IWillMount here <https://github.com/dagda1/web-game-of-life/blob/master/src/cljs/app.cljs#L57> that is called periodically on a timeout function.
Do I run the risk of having multiple go blocks running? Should I be killing the channel? Cheers Paul Cowan Cutting-Edge Solutions (Scotland) blog: http://thesoftwaresimpleton.com/ website: http://www.cuttingedgesolutionsscotland.com/ On 22 June 2014 15:07, Andrew Stoeckley <[email protected]> wrote: > Thanks Daniel and everyone; this has been quite helpful. > > On Sun, Jun 22, 2014 at 10:00 PM, Daniel Kersten <[email protected]> > wrote: > > PS: > > > > My invisible component is a container for the actual root - so I don't > > return an empty div, I return (om/build real-root-component app-state > > options-passed-to-root) > > > > > > On 22 June 2014 14:58, Daniel Kersten <[email protected]> wrote: > >> > >> 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 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.
