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.
