Your approach is very similar to what I'm currently doing. I have an invisible root component that manages pushing external changes to the state. I also use tx-listen to do the opposite: push om-initiated changes to the server (similar to om-sync). On 8 Jul 2014 19:28, "Andrew Stoeckley" <[email protected]> wrote:
> 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. > -- 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.
