Actually this raises a question: if IWillMount runs repeatedly, wouldn't the go block inside it get generated every time? Normally I'd have a single go block living outside the Om stuff, and it listens; but you'd have multiple go blocks created if they were coded inside IWillMount, wouldn't you?
On Sun, Jun 22, 2014 at 10:17 PM, Paul Cowan <[email protected]> wrote: > I have a go block in IWillMount here 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 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.
