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