@lexwin I’ve been interested in using the lifecycle functions, too, but so far only managed to figure out how to animate with css (in reagent).

I wonder if it’s “just” a question of wrapping a seq of children in a transition-group, and using reagent.core/create-class on each of the children, supplying all of those transition-group-specific lifecycle methods (`:component-will-appear`, component-did-leave and so on) to each of the children

But then, I remember having React warn me (via reagent) that create-class was going to be deprecated

@reefersleep I actually got something to workish yesterday.

neat!

I’d love to see a gist or project 🙂

Yes, I did using create-class and read through code and used alot of debugging tools and it seemed like it should have worked but did not. Then like a last thing before I gave up i tried setting properties instead and that seemed to work.

hm, ok

I don’t know what you mean when you refer to properties.

Ye, I will get some code for you.

nice :thumbsup:

(def tg (reagent/adapt-react-class
         js/ReactTransitionGroup.TransitionGroup))

(defn hello []
  (doto (reagent/current-component)
    (aset "componentWillAppear" (fn [cb] (log "appear") (cb)))
    (aset "componentWillEnter" (fn [cb] (log "enter") (cb))))
  [:div "Hello world"])

(defn app []
  [tg
   [hello]])

Have not investigated this deeply but atleast it prints something and that's infinetely more far than I've got before.

😄

what does current-component refer to? hello or tg ?

(I guess only hello would be the sensible answer)

Should be hello, since it's refered to with [

But if I in app would use ( then I guess it would be tg?

That’s interesting in and of itself 😄

I haven’t used current-component before

but

here’s my suggestion to do it in a more reagent-ish way:

(def tg (reagent/adapt-react-class
         js/ReactTransitionGroup.TransitionGroup))

(defn hello []
  (reagent.core/create-class 
    {:reagent-render [:div "Hello world"]
     :component-will-appear (fn [cb] (log "appear") (cb))
     :component-will-enter (fn [cb] (log "enter") (cb))
    }
  )
)
(defn app []
  [tg
   [hello]])

(trailing parens because I’m editing in slack 😄 )

does that make sense?

Yes, that's the first thing I tried but did not work.

that sucks

And I don't know why, when I read the source it seems like it should.

maybe create-class prunes off those extra lifecycle functions?

I did not see anything suspicious in reagent source, only here: https://github.com/reactjs/react-transition-group/blob/v1.1.3/src/TransitionGroup.js#L226

yeah… I can’t make sense of that, though. In the documentation I read, it said that the high-level API assigns those lifecycles to the children, so I don’t understand why they are removed

but I’m not used to reading js, and definitely not react code.

I wonder if any of the re-frame guys have maybe worked with react-transition-group? Can’t remember if I’ve asked in #re-frame already

I'm gonna investigate if I can use this to acheive what I want (that is chained transitions) and if so I might revisit the code again to see if would be possible to reagentify.

Godspeed, good sir 🙂

I'll come back here if I make some significant discovery 🙂

Hm... so with reactions. If I have a list of components which can either be in view or edit mode.

they all deref a subscription to find out whether they should be edited.

when I just had view they all just received an id and rerendered when the data associated with the id changed

but now they all depend on knowing which id is being edited

so when the id that is being edited changes, they all update

I suppose I'm asking if there's a way to make this more fine grained

to more explicitly decide when to rerender based on current and previous value of reaction

so only rerender if id of row is the same as the edit id

Beginning to think that I would prefer a system where only the mutation of the state decides what needs to be rerendered

I wonder how you can desire to avoid re-rendering when depended data changes, though? I’m guessing you have something like :on-change handlers which close over the id, and if they aren’t updated when the id changes, well, you’d call the handler with the wrong argument whenever the id has changed, yeah?

I feel like I’m missing some part of your puzzle @urbank , probably because I’m having a hard time visualizing your code context.

@reefersleep Yeah, spitballing a bit 😛 . Also discussing this on #keechma (neat framework on top of reagent by the way. NOT my creation). Well sometimes the data is dependent but its change almost never results in the component actually rendering differently. So let's say you have ~100 components where they each subscribe with a different id. However they also have a joint subscription to just ONE changing id (`edit-id`). Whenever edit-id changes it will result in max 2 actual row changes (the one that is no longer being edited and the one which is the newly edited one), but in fact they will all rerender because they all subscribe to the edit-id which has changed. Optimally a row would only rerender if edit-id is the same as its id or was previously equal to edit-id but is no longer. I hope this is somewhat clear. I see though that this could also be achieved by refactoring the id subscription so that it would return the entity data AND that it is being edited only if it is being edited.

can’t you make a subscription like :is-being-edited? that takes an id, and then handle the check in its fn? that way, each of your components are all dependent on that subscription, but the dereffed subscription data only changes for those two components.

oh wait, I’m thinking in terms of re-frame

but the design still applies

I think. 😄

... hm. Haha, you're right of course 😄

wow, ok

I hope it holds!

That solves the problem exactly, actually! Thanks! Guess I was stuck in the mindset that the subscriptions returns the edited id.

Damn, seems so clearly like the most elegant solution now. I was optimizing by doing almost exclusively get-in in subscriptions but in this case the computation is actually much better

Awesome 😄

I think this is one of those moments where I will remember solution when I run into a similar problem and it will help me solve that one. Snapped me out of the no computation in sub is always more optimal. This will cascade further. So yes, much obliged!

That’s great 😄 When I first heard about reactions (and subscriptions in re-frame) and about how you could put any amount of computation in there, I imagined long complex, but really, I’ve been using them for relatively simple stuff.

Or maybe it seems simple now that I’ve become accustomed to throwing pure core functions around.

In any case, I think I underestimated that power to begin with as well 🙂

And that must be because there are a lot of “simple” gets and get-ins in subscriptions - this has especially been the case for me in the first phases of building my apps 🙂