I think I didn't understand entirely what constitutes a mount and unmount in Om; is an unmount similar to no longer calling build on a component that was previously getting built and rendered? i.e. a parent component decides to not call build any more on a child, thereby removing it from the screen, thus this would be an unmount?
On Sun, Jun 22, 2014 at 10:29 PM, Andrew Stoeckley <[email protected]> wrote: > 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.
