Actually in hindsight the draining wouldn't be necessary inside an infinite go loop such as a while-true inside the Om component.
On Tue, Jul 8, 2014 at 11:23 PM, Andrew Stoeckley <[email protected]> wrote: > 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.
