Can't delegate click on child element

[mrweiner]

I have the need to add delete buttons on each sublist element, but I cannot seem to delegate a click event on my buttons because the event is always handled by DragonDrop. The list items and delete buttons are being added dynamically. Any suggestions?

[schne324]

Are you configuring it using nested: true by chance? The reason I ask is, given nested: true I'm stopping propagation which would likely cause this problem (https://github.com/schne324/dragon-drop/blob/master/index.js#L150). If this is the case I can start thinking of a better way to avoid having to stop propagation - it's put in place to avoid the click bubbling up to a higher list / list item in the nested structure.

[mrweiner]

I am indeed using nested: true -- I guess that's what I was referring to by "each sublist element". Each sublist item (nested list item) would look like:

<li>
  <span>Text</span>
  <button class='delete'>Delete</button>
</li>

Yeah, it makes sense why you are stopping propogation in there. Do you have any ideas on how I might be able to get around it for the time-being or am I kinda stuck? Only because the alternative I have right now is to generate the buttons outside the list completely, and reposition then over their <li>, which makes it so that you cannot tab to the delete buttons until after you tab through the whole list.

[schne324]

Unfortunately, the only workaround that I can think of is to not delegate the clicks but rather target the specific elements and add individual event listeners. I know you said that these are being added dynamically so it'd probably have to be wired up where ever you are generating them in the first place.

I'm doing some initial thinking about a complete refactor to add support for several additional types of drag-and-drop, I will keep this problem in mind as I develop it.

[mrweiner]

Ah good call, event listeners on each button seems to do the trick. Thanks!

[schne324]

No problem!

[schne324]

I just thought of a quick fix for this which is to emit a custom 'handle:click' event so we can still stopPropagation but the implementer can have a hook for when the handles are clicked...

@mrweiner thoughts?

dragon.on('handle:click', handle => console.log('clicked: ', handle));

[mrweiner]

Hmmmm, @schne324 that is a good idea as a quick fix, but I'd be concerned with it as a long-term solution since it would only apply to implementations that leverage handles. We aren't using handles in our implementation so we'd still need to use the event listeners on each element even with the above in place.

If you could extend that so that you could pass any desired child element into the handler, that could be a more extensible solution in that you could do something like:

dragon.on('click', 'span.child-click-target', child => console.log('clicked: ', child));

Instead of giving wildcard control within the hook, you could also have the user instantiate the target children as a children array alongside handle and announcement. We needed to grab data attributes from the clicked elements within the event listener, which was easy enough, although I don't have an idea about how feasible that would be with the above.

[mrweiner]

Actually I just realized I may have had your intention above completely backwards, but I'll let you take a look at what I wrote and you can confirm that I misunderstood you. Haha.

[schne324]

This actually wouldn't only apply to implementations using handles, if the handles option is set to false, then the whole item is the handle (as far as events are concerned) - https://github.com/schne324/dragon-drop/blob/master/index.js#L230. This means that clicks anywhere in the entire item would trigger this event.

Now that I think about it though this wouldn't help you in your situation because the desired target of the delegated event is within the item.

I will keep your suggestion of adding support for a "delegated dragon click event" in which you can target a child via a selector in mind as I begin my refactor.

Thanks!

[mrweiner]

Right, yeah I guess that's what I meant in saying that it wouldn't apply where handle is false.

Sounds good, happy to help. Thank you!

[mrweiner]

Oh also just realized, in case it changes how you go about implementing the above, you may want/need to account for the possibility that multiple children might have the same identifier, like in the case of list items.

[schne324]

@mrweiner I am adding this known bug to the existing relevant ticket ( #11 ). I will let you know when this refactor happens and ensure that delegating clicks on children is possible.

Thanks!