Fork me on GitHub

@johanatan you could use webpack or something similiar to generate a bundle with all the deps except react i guess


@edannenberg ya, i thought about that but it seems like a major pain. webpack can take weeks to configure properly lol (which is why people are using ClojureScript to begin with).


I've decided for now to just use ReactCSSTransitionGroup


@johanatan might be worth a look, may or may not a bit overkill. but pretty slick once you wrap your head around it


Ya, react-swipeable-views actually uses motion under the hood


@johanatan That's what I usually do (and tried for this problem) when I can't derive the :key from the element itself, but in this case interpose describes exactly what I wanted to do and led to much nicer code (while theoretically not quite as performant)


is there a difference between passing a component multiple arguments versus a map of properties?

[mycontrol show? some-data]
[mycontrol {:show? true :some-data [1 2 3]}]


@joshkh no, think it is just preference. I tend to lean on a map if i have more than two arguments, bc it means the arguments no longer have to be ordered, and will be self-documenting (bc of the keywords)


@curlyfry I wasn't suggesting to get rid of the interpose: merely to change the map you already have to a map-indexed


thanks @mccraigmccraig I think that providing an always unique key is forcing a full rerender


@johanatan What difference would that make? The interposed [:i] elements would still lack keys, and the others already have unique keys


@curlyfry oh, sorry. You're right. Why not remove the inner :key from the :i elements and wrap the whole thing in a map-indexed: (map-indexed #(do ^{:key %1} %2) (interpose [] (map ...))) ?


@johanatan Yes, that works, but still pretty verbose which is what I wanted to avoid 🙂 I'm quite happy with the solution using into. We are talking about something like 3-4 elements so performance isn't really an issue


But really appreciate you taking the time 🙂 Thanks!


Okay, so I’ve got native React components working in a Reagent context. But with a couple of caveats. Maybe you can help me eliminate some of those?


1) In index.html, I’m including victory.js from a CDN. But it needs be done after including the compiled cljs, since victory.js depends on React being available (ie, the global React javascript variable) 2) Because of this, I cannot use reagent.core/adapt-react-class in a def, since Victory is not available when the compiled cljs is evaluated.


@grav There seems to be a version, why not use that?


Ooh … didn’t think of that. That might simplify things


@curlyfry Yes, that seems to work much better!