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.
