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

could not be the correct lead - it’s just the closest I found

guess it’d be asking David Nolen at this point, probably on #cljs-dev to dig it out

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?

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

Any thoughts on fixing this?

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.

my head hurts 😄

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.

(and drop)

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.

here goes nothin'

😞 same issue

this is killing me, man

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

Hover works, but not after the first drag and drop. It gets locked onto the target of the drop.

I'd like to give you a demo of it, but redacting everything would be a royal pain.

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?

yes, its :id

you may notice that :id and :key are set

both to be the value of :id

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

oooo, you know, i think i tried this, but here goes

err no, i did it on the [rule-component r db] bit inside the when

If it’s what I think it is, you have to have it on the :li

you got me really excited, but still no dice. hmmmm

:thinking_face:

ohhh, hmm, let me try a different palce

place

perhaps the available-list [rule-component r db] bit

that did it!

YESSSSSSSSSSSSS

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

So, I thought that [:li {:key (:id rule) ...}] would do it for me.

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

it didn't work to tag the :li in the rule-component* fn itself

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 😉

😄 man, i owe you a beer or whatever your preferred beverage of choice is

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:

(Meh, needs some work)

lol

No but seriously, can you explain this?

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.

https://reactjs.org/docs/lists-and-keys.html#keys

The main reason is the reconcilation in react