Hey,
the problem is not that closure munges the window.ga function, it is that
closure creates a var named ga which can be anything but is not the analytics
ga. At least it was in my case.
My solution was to use the renaming feature of the analytics snippet to use a
name closure won't
I am using core.async with Om and a websocket. I use channels to communicate
changes to a parent go block in IWillMount for om/update! and om/transact! and
I also use a channel to handle incoming responses from a websocket.
I get quite a bit of data pushed onto these channels, sometimes a
om/update! is working on the cursor's view/entry-point into the app state atom,
not directly with the entire atom you've declared to hold your app state.
On Jul 16, 2014, at 8:31 PM, Andrew Stoeckley andrew...@gmail.com wrote:
On Saturday, January 25, 2014 11:38:14 PM UTC+8, David Nolen
I have this same problem. I thought multimethods would be great way to render
different views in simple page app, so I wrote something like this:
(def app-state {:view :login})
(defmulti render-view (fn [app owner] (:view app)))
(defmethod render-view :login [app owner]
(om/component
Most likely you are hitting this limitation:
https://github.com/swannodette/om/issues/178
Om uses the function to decide if it needs to unmount/mount components.
Since the multimethod is always the same function (regardless of where it
then dispatches to), Om does not know that the component has
Not an Om user here but sounds like you are receiving messages faster than you
can handle them.
A slow consumer is a common problem in a messaging situation and core.async
has 2 built-in ways to deal with that. You can either use (async/chan
(async/slliding-buffer n)) or (async/dropping-buffer
Could you post the repo or the code where the channels are being used?
It looks like you might be putting things on a channel within the IRender
lifecycle hook which will happen once each time there is a state change.
Will
--
Note that posts from new members are moderated - please be patient
This might help, not too sure though:
https://github.com/hackerschool/community/blob/master/client/src/community/core.cljs#L19-L24
On Thursday, July 17, 2014 12:02:54 PM UTC-4, Jarppe Länsiö wrote:
I have this same problem. I thought multimethods would be great way to render
different views
Hi William, the takes off the channel are happening in IWillMount
(posted in my original message), however, the puts onto the channel
are not happening in the React lifecycle. They are happening
separately as a result of websocket messages incoming. My puts look
like this:
(defn
Faris -- I just tried the code you mentioned and it prints 0 1 2 3 4
... as anyone would expect. I can't imagine why you are seeing 0 3 7
10 as there is surely more going on there on your side, because that
is not what should be happening.
On Fri, Jul 18, 2014 at 10:16 AM, Faris Nasution
Yep that was a mistake on my part, actually the code isn't exactly like
that. I wrap the (chan) inside a function and then in go-loop I invoke that
function.
On 18 July 2014 10:37, Andrew Stoeckley andrew...@gmail.com wrote:
Faris -- I just tried the code you mentioned and it prints 0 1 2 3 4
This is a limitiation from React.
Authors said We're investigating ways to return more than one node but we
don't have a solution yet. 2013/12
In my use cases, I rarely have to add a dummy wrapping div or span. It always
end up with a css class or click handler
On Friday, July 18, 2014
12 matches
Mail list logo
