This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-10
Channels
- # announcements (14)
- # bangalore-clj (1)
- # beginners (89)
- # calva (166)
- # cider (33)
- # clara (12)
- # clj-kondo (1)
- # cljdoc (8)
- # clojure (101)
- # clojure-austin (1)
- # clojure-colombia (7)
- # clojure-dev (14)
- # clojure-europe (5)
- # clojure-hamburg (10)
- # clojure-italy (9)
- # clojure-nl (31)
- # clojure-spec (4)
- # clojure-uk (39)
- # clojurescript (17)
- # clojutre (3)
- # code-reviews (16)
- # cursive (72)
- # data-science (1)
- # datomic (81)
- # duct (8)
- # emacs (4)
- # figwheel-main (1)
- # graalvm (2)
- # jobs (9)
- # kaocha (21)
- # lambdaisland (2)
- # luminus (4)
- # off-topic (35)
- # re-frame (1)
- # reagent (101)
- # reitit (4)
- # ring-swagger (5)
- # shadow-cljs (17)
- # sql (40)
- # tools-deps (4)
- # vim (28)
I've just deployed 0.9.0-rc1 version to Clojars: https://clojars.org/reagent/versions/0.9.0-rc1 and I'd like to hear if this works in existing projects or if someone will notice regressions: https://github.com/reagent-project/reagent/issues/449

Is this still an issue in Reagent? https://clojurescript.org/reference/compiler-options#fn-invoke-direct
@roman01la I canāt even find a relevant issue anywhere out there for reagent
(or a discussion) explaining what is/was wrong. Can you?
Couldnāt find it as well
https://github.com/clojure/clojurescript-site/commit/7d66be04cfd77c5124d2dd0bf346964aecabbda3
I give up I guess for now, but https://clojure.atlassian.net/browse/CLJS-3002 was as close as I got to some enlightenment
Hm, how's this issue related to the above problem in reagent?
@roman01la Itās hard to say for sure. Iām guessing it has to do with the apparent inability to determine that the arity is supported
Maybe https://clojure.atlassian.net/browse/CLJS-2133 and https://github.com/reagent-project/reagent/commit/3cf045dc8264373d93d9c3a7607dc2a349194681 ? Though not sure if this problem was related to fn-invoke-direct option.
Huh, the caution about Reagent in clojurescript-site is from july, but I don't have any idea what it is about.
guess itād be asking David Nolen at this point, probably on #cljs-dev to dig it out
I'm probably going to struggle to come up with a way to describe the problem I'm having, but here goes:
NOTE: I am new to reagent and react.
I have a mostly working drag and drop implementation. There is a sidebar of li
elements. When I drag element at index 3 and drop it elsewhere, the item is removed, and elements from the new index 3-N are then broken and no longer draggable. However, the elements 0-2 are.
I could make a wild guess: you render your list, and then attach handlers to each li
element for the drag-n-drop support. Then you drag an element, and React says, āAha, this list has changed, I need to rerender everything after the Nth element,ā so it re-renders them, but since itās React doing it, it only renders the elements, it doesnāt apply your handlers.
Possible?
There's context missing here, and it's a bit of a mess at the moment, but please take a look and let me know if anything looks amiss. https://gist.github.com/devn/6b6254013728fe2b952d71f83ed782ce
Other notes: I know the sorted-set looks a little suspect, but I've tried the same thing as a vector, and it's the same issue.
@U06CM8C3V You may well be right, but I'm not sure how to fix what I have if that is the case. Wanna take a peek and let me know what you think?
Yeah, Iām looking at it now ā Iām a re-frame person more than a reagent person, but let me dig in a bit more
One thing you might try as a debugging step is add a println
or js/console.log
between (fn rule-component* [rule db]
and [:li
, and print out the name of the rule or something. If React is re-rendering everything after the dragged-rule, youāll see a bunch of debug statements spam out when you drag/drop.
And if not then thereās some other problem.
@U06CM8C3V yeah, that's what's happening alright
Itās a little odd, you have the li
elements rendering with handlers in-line, so it shouldnāt be a question of React rendering them without the handlers
Itās possible that React is rendering a whole new rule-component
(the top-level defn
), but re-using the individual li
elements for the sake of efficiency.
Or, hereās a guess: React re-renders the main rule-component
and the first 0-N li
elements, but re-uses the N-last li
elements. So since the rule-component
defines atoms for everything, a new rule-component
would have all new atoms, but some of the li
elements would still be pointing back at the atoms in the original rule-component
, so theyād break.
Or possibly some variation on that idea, which you could test by putting a println or something right after (defn rule-component [rule db]
ā¦
Mine too! š
@U06CM8C3V hmmm, I don't see anything interesting by dropping a println
there. I see the full list of items on initial render, but nothing after drag.
Anyway, my first approach to trying to fix it would be to make the ul
element an entirely separate component from the li
element.
Hmm, so maybe itās not calling rule-component multiple times :thinking_face:
I havenāt tried implementing drag and drop, but it does seem like the state management here is head-achy. Then again, re-frame keeps everything in one big atom, so maybe Iām just letting my re-frame bias creep in.
@U06CM8C3V if it's not too much trouble, would you mind providing ane example of what you mean? How would you wrap the ul
bit in a separate component?
Iām trying to figure that out right now, may take me a bit š
thanks so much for your help. i've been beating my head against this for nearly 2 days and I could use some help
Looking at this more closely, Iām starting to doubt that it will actually help to make the ul
tag separate ā I was thinking there was more state in the parent, but it looks like itās all local to each li
element.
Have you tried putting all your handler functions above the (fn rulecomponent* [rule db]
line? Move āem up to the let
statement and have your li
components use like :on-drag-start drag-start-handler, :on-drag-end drag-end-handler
etc?
Your current code is re-creating those handlers every time React re-renders one of them, maybe it would help if the handlers were just defined once.
hmmm, you're saying define {:class ...}
in the block, and then just reference it as {:class stuff}
?
no, just the :on-drag-foo
bits
So like after the let
definition for disabled?
, youād have
drag-start-handler (on-this-target
(fn [e]
(let [[effect rule] (rule/drag-effect-and-rule rule)]
...
so the let block would look like [on-drag-start (...)]
, and then I'd do {:class [] :on-drag-start on-drag-start}
Yeah, thatās it
The static stuff like :class, :id, :key, etc, stays down below, and all :on-whatever handler functions move up.
What specifically happens when you try the second drag-n-drop?
And also, does your āhoverā functionality work, or is that also broken?
On the first one, I get logging that tells me which rule I've selected, what I'm hovering over, etc. I see the account of available items decrease by 1, and the item is removed from the available items list. The available item directly after that item is given a class "dragged" which does not go away. For our purposes, this item now, and every item after it are treated as the previous dragged rule. So for instance, if the list were:
1. A
2. B
3. C
and we initially dragged A, B's class would be set to dragged
(among other things), and if we try to drag B, the logging shows the name of B is actually the previous rule we dragged (A).Hover works, but not after the first drag and drop. It gets locked onto the target of the drop.
Yeah, no, I may not need it, Iām having an āOMG not this againā momentā¦
I think I know what this may be
Is there some unique piece of information in rule
thatās different for every li
element?
Awesome, try this: inside rule-component*
, just before the [:li
, put ^{:key (str 'rule-comp-" (:id rule)}
<li title="Drag onto a rule grouping on the left." draggable="true" id="d9212b48-3751-46d9-8776-51aa769593cd" class="card"><span>Foo</span></li>
(Hoping this works the same in reagent as in re-frame š¤ )
If itās what I think it is, you have to have it on the :li
:thinking_face:
This is amazing. Every time Iāve come across a weird, unsolvable React/Reagent/re-frame issue itās this same fix.
I should just start answering every question in #reagent with āDid you put a unique key on the element thatās giving you trouble?ā
and then while reading the reagent docs I came across the use of the ^{:key ...}
metadata, and tried it, but in the wrong place.
Yeah, I donāt know if itās supposed to work inside the component, but putting it in the meta has always worked for me.
it needed to be very specifically, on the calling component that generates the underlying li
oh, one more question: is there a reason for the prefix? Is that so React knows they're all friends and need to be taken care of together?
Ok, Iāve seen similar stuff, didnāt think it would work in this case, but fortunately you thought to try it.
I just use a prefix as a ābest practiceā in case I need to use the same key in 2 diff components
Itās probably overkill in most cases, but maybe someday itāll save me a really weird bug.
gotcha, and actually, in this case, that may wind up being an issue. the target of the drop is also a rule-component
there you go then š
Np, glad I could help, youāve expanded my repertoire of React stories that all have the same punch line.
You hear the one about React? I know you haven't, because the key to it needs to be different every time. :drum_with_drumsticks:
I mean, you've done enough already, and I'm looking at our 81 (now 82) message conversation, but I would like to understand the underlying need for this change.
Iām not 100% clear on it myself, but my rough guess is that React wants to minimize the number of DOM elements that have to be re-rendered, and they use the keys to track which elements have already been rendered. For whatever reason, it sometimes holds on to already-rendered DOM elements when it shouldnāt, and thus elements fail to change as expected. Manually specifying the key forces React to keep components straight when it would otherwise confuse them.
I am completely flummoxed as to how to debug what's causing the problem. Any help would be greatly appreciated.
Maybe https://clojure.atlassian.net/browse/CLJS-2133 and https://github.com/reagent-project/reagent/commit/3cf045dc8264373d93d9c3a7607dc2a349194681 ? Though not sure if this problem was related to fn-invoke-direct option.
Huh, the caution about Reagent in clojurescript-site is from july, but I don't have any idea what it is about.
There's context missing here, and it's a bit of a mess at the moment, but please take a look and let me know if anything looks amiss. https://gist.github.com/devn/6b6254013728fe2b952d71f83ed782ce