I'd be curious what you all think of this strategy for using a channel for updating the Om atom inside a component. I have several different places in the app that need to notify Om of new data. It can come from anywhere based on a variety of things, so I've just created a single channel, and onto this channel is placed a vector of args like [cursor korks v] for passing to om/transact!. When I read this channel in a go block inside an Om root component, the vector is pulled off and an (apply om/transact! [cursor korks v]) is processed for whatever was put on the vector. This allows a single entry point to the actual updating of the Om atom via the proper transact! while still letting any area of the app dump state changes onto the channel.
I'm still coding up everything, and of course one of the obvious issues is that many items may be placed on the channel before the next read (though unlikely), thus it becomes necessary in the go block to drain the entire channel and use up all its values at once so all pending updates are processed, for which I'm using a more meaningful variation of this go-loop-alt approach: https://gist.github.com/hellofunk/b32c8e0d267ada0cc396 As I'm new to both Om and core.async, I'd enjoy hearing any obvious alternatives to this approach or just a vote of confidence that it's a decent idea. On Sun, Jun 22, 2014 at 9:20 PM, 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 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.
