Fork me on GitHub
#reagent
<
2016-09-19
>
reefersleep08:09:01

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.

yury.solovyov08:09:58

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

reefersleep08:09:07

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

reefersleep08:09:52

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.

reefersleep08:09:06

So I'm always working towards it.

yury.solovyov08:09:05

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

yury.solovyov08:09:07

It is better than noun anyway

reefersleep08:09:50

Argument noted 🙂

mikethompson08:09:19

@reefersleep Yeah, I think you are right.

mikethompson08:09:39

Should be a verb (of some tense)

mikethompson08:09:06

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

mikethompson08:09:29

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

mikethompson08:09:33

But this is a heads up in the meantime

mikethompson08:09:10

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

grav09:09:42

Do something like async reactions exist?

grav09:09:18

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

grav09:09:14

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.

reefersleep10:09:50

a REST call, even 🙂

reefersleep11:09:40

@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?

grav12:09:03

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))))

reefersleep13:09:31

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?

eyelidlessness15:09:07

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

gamecubate19:09:34

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.

gamecubate19:09:20

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.

gamecubate19:09:33

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!

johanatan23:09:08

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?