Fork me on GitHub

Regarding @yury.solovyov's confusion, isn't it good advice in general to name your events with some kind of verb? :change-color, :timer-clicked and so on. That's my practice - currently I'm trying to figure out whether to name things strictly in present or past tense, and whether the name should refer to the source of the event, eg timer-button-clicked or the desired effect, eg start-timer. I prefer strict practices - they're easier on my brain 🙂 Figuring them out upfront is also cognitively costly, but I view it as an investment.


Though I'm not sure there's a silver bullet here


@mikethompson (just @mentioning you since this isn't #re-frame)


Is there ever? 🙂 Even if I'd have to deviate from my practice some times, I would at least like to establish a baseline to deviate from.


So I'm always working towards it.


Well I'd stick to past tense, since callbacks are usually about what already happened


It is better than noun anyway


Argument noted 🙂


@reefersleep Yeah, I think you are right.


Should be a verb (of some tense)


We think we've found a bug with Reagent 0.6.0 .... means that checkboxes are not getting correctly rerendered in some circumstances


We'll report the bug tomorrow (late here) with a repo which shows the problem


But this is a heads up in the meantime


Just before release of v0.6.0 I think Dan did some work on <input>s ... my guess is that broke something


Do something like async reactions exist?


I want to do a rest call and then expose the result as a reaction


Currently, I can do it by creating an intermediate reaction that does the rest-stuff, and an r-atom that contains the result. And I need to refer to both. Would be nice if I could wrap this in some way.


a REST call, even 🙂


@grav: I overheard your problem description on the way to lunch, but found it a bit confusing. Maybe a minimal code example of your predicament would illuminate things?


Ok. here goes. Scenario is, I need to asynchronously do a computation on a backend. Let’s say that there exists a new api, reaction-notify that abstract the asynchronicity away by giving me a callback function that notifies watchers. I could then do this:

(def input (r/atom 42))

(def squareroot-of-input (reaction-notify [notify] (-> (js/fetch (str "" @input))
                                                      (.then notify))))

(def result (reaction (* 2 @squareroot-of-input)))

(defn view []
   [:p (str "The double square-root of " @input " is " @result)])

Since reaction-notify is more general than reaction, as far as I see, I could express regular reactions like using it: (def result' (reaction-notify [notify] (notify (* 2 @squareroot-of-input))))


I'm just hoping someone here will take the bait, @grav 🙂 I can't get you any further, unfortunately. Maybe someone here has more insight into reagent's reaction implementation?


does anyone maintain a codebase/library for both 0.5.1 and 0.6.0? any gotchas?


On a large project plagued by a high (10s of times per second) reagent redraw problem. Components are redrawn even if their ratom data has not changed. I tracked it down to 3 overlapping divs. hidden, w. position fixed (full screen), representing different help views that are tucked away until needed. Even with different z-indices, their presence seems to trigger an avalanche of reagent renders. If I disable all but one, problem goes away.


I can work around this of course (e.g., single lightbox whose contents are data-driven) but that does not make me feel safe. Is this behavior known or documented anywhere I wonder.


Hm. Somehow unable to reproduce the problem outside of our UAT system, which is loaded with other stuff. May not be a problem with reagent after all. If anyone has seen this though, please let me know. Thx!


Hi, I have a layout change (i.e., new DOM elements inserted shifting existing ones down) triggered by some atom's data changing (suppose a new section added to a page). I also have mouseenter and mouseleave event handlers setup on individual elements. If said layout change results in a change to which element is underlying the current mouse pointer, then my effects in the mouse handlers (which do typical "highlight color" stuff) do not run for the new element under the cursor (or for the old element under the previous relative cursor position for that matter). (edited) Anyone encountered similar problems or have any ideas for solutions?