In the case of application state being modified "externally", would you recommend having an invisible Om component listen for those changes and apply them through transact! itself? Or is the approach of just swapping in a delta considered fully supported and "recommended"?
(given the discussions I've been having with you on IRC and from my only playing with Om, I'd lean toward the former, but the latter is certainly "simpler") Sean On Apr 3, 2014, at 9:51 AM, David Nolen <[email protected]> wrote: > On Thu, Apr 3, 2014 at 12:17 PM, Don Jackson <[email protected]> wrote: > Which I take to mean that when you change application state outside of Om as > described above, then you will not obtain the benefit of some > current/upcoming Om features, again, is this the correct interpretation? > > Yes. > > If so, is there any potential way that might enable “outside of Om > application state changes” to make themselves compatible with (or become) > "inside of Om app state changes"? > > For example, might it be possible to provide an input queue/channel (to Om) > of app-state change requests that could be transact!/update! -ed at some > point in the Om lifecycle/flow? > > I honestly don't see the point of swapping the app-state directly over using > the Om API. If instead your root component transacts! on the root cursor you > get all the the advantages of swap! and none of the disadvantages. > > David
signature.asc
Description: Message signed with OpenPGP using GPGMail
