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 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.
