Re: subtle om + core.async problems

2014-07-28 Thread Dylan Butman
That looks great Dan! here's a slightly different version that takes a supplied channel and kills the go on either component unmount or the supplied channel being closed (defmixin go-block-aware (init-state [] {:chans {:mounted (async/chan)}}) (will-unmount [owner]

Re: subtle om + core.async problems

2014-07-25 Thread Daniel Kersten
but easy to avoid the problem. > > > From: Daniel Kersten > Reply: clojure@googlegroups.com > > > Date: July 25, 2014 at 5:26:56 AM > To: clojure@googlegroups.com > > > Subject: Re: subtle om + core.async problems > > You could simplify your fix code a s

Re: subtle om + core.async problems

2014-07-25 Thread Alexander K. Hudek
ate: July 25, 2014 at 5:26:56 AM To: clojure@googlegroups.com > Subject:  Re: subtle om + core.async problems You could simplify your fix code a small bit by using go-loop and when, like this: (go-loop []   (let [[v ch] (alts! [dump-chan (om/get-state owner :exit-chan)])]     (when (= ch dum

Re: subtle om + core.async problems

2014-07-25 Thread Daniel Kersten
You could simplify your fix code a small bit by using go-loop and when, like this: (go-loop [] (let [[v ch] (alts! [dump-chan (om/get-state owner :exit-chan)])] (when (= ch dump-chan) (.log js/console "dumping state:") (.log js/console (pr-str (om/get-state owner))) (recur)

Re: subtle om + core.async problems

2014-07-23 Thread Sean Corfield
You'll want to read this thread: https://groups.google.com/forum/#!topic/clojurescript/DHJvcGey8Sc In particular: "So if you have code that's like this, those components will want to clean up after themselves in IWillUnmount." That should address your first problem? I'm not sure what to sugge