On the topic of dndkit's tight-knit, non-bubbling architecture.

[growthwp]

Disclaimer: I am a sponsor of dnd-kit, please don't let this affect the outcome of this topic in any way. I plan on fully sponsoring this project once our product is out, but I want a productive, constructive talk between developers and after thorough research, I wanted to share my findings. I tried to be as unbiased as possible.

Please also refer to #280 (comment) for a code overview of what this "free bubbling" architecturing would do".

For the past 30 days or so, I've been personally involved with looking for a DnD library that could help us build our "page/site builder": have sections, sections have containers with components, components can move freely within containers, you get the gist of it. This decision is crucial. I really tried to find something that would let us create complex DnD interactions. Unfortunately, everywhere I checked (although testing is still undergoing), a very painful constant appeared:

The libraries follow a lockdown approach where a droppable and a draggable are uniquely connected and they don't really talk to the outside world. When designing a library, I always think about how I can make everything as unopinionated as possible and I think this is a trait of a good programmer, in the case of dndkit, Clauderic strikes me as extremely smart, friendly and easy to work with, which makes the question "is it me that's wrong?" a very valid one and by no means I'm trying to influence anything, but just genuinely curious.

I simply don't understand why a drag'n'drop event can't be just that. If a DOM node is a droppable, then it should be able to see all draggables flying above it BUT it shouldn't react to all of them.

In a way, we should only have a super high-level DndContext that manages all interactions and the draggables/droppables determining how they wanna play with each other.

I fail to see how this architecture isn't far superior, if performance is an issue (not sure how it could be), DnD events tend to happen very infrequently and so, having an architecture that allows you to build both simple and complex things far outweighs the downsides.

dndkit is amazing for simple dnd tasks. It's cleaner, nicer and has the Sortable functionality which is crazy cool. But, once again...what past that?

I'm looking to engage in meaningful discussion on this topic because, as it stands, there's no React dnd library out there that is (1) maintained, (2) feature-rich and (3) easy to use.

[growthwp]

I wanted to add a bit more to the discussion as I have explored multiple options, both from react-dnd and react-beautiful-dnd. This feature of nested or as I call it "free flow drag & drop" is very requested.

But the request of this feature is a symptom of an architecture that is built with constraints that don't really make sense to be there in the first place.

I managed to find a CSB that manages to make react-beautiful-dnd work with nested DnD. Again, its code looks so complicated that I can't begin to figure out what its doing.

At its core, this is a problem of bubbling. A DndContext catches a drop event and doesn't pass it on, it handles it, but a way to make any interaction, no matter how complex work is to have the event fire and then contexts that care about it handle it.

While I get this is not in the short-term goals of the library, it should be something to think about. Assume I had this structure:

//someFarAwayFile.js
<Draggable type={'custom'}/>

//someDeepContext.js
<Droppable id={1}>
  <Droppable id={2}>
   <Droppable id={3} accepts={'custom'}>
   </Droppable/>
  </Droppable/>
</Droppable/>

Then dnd-kit should not stop the drop event on the droppable with id: 1 and propagate it until it finds a handler. As it currently stands, that's what it does and is making nested, as well as complex use-cases damn-near impossible.

Some things that this easily allows you to do, off the top of my head:

• Assume you had multiple droppables, every time you dragged a draggable over each one of the types, it could look at something else - maybe even have a "acceptable/not acceptable" icon.
• Assume you had multiple draggables, if you moved another draggable over, you could have some visual effect.
• Stackable droppables
• I'll update as soon as more examples come to mind

[olee]

I know this is an old topic, but I gotta say I totally agree with @growthwp and not having the option to "bubble" drag/drop events in any way by dnd-kit itself can be quite bothersome.
In my case, I am working on a small context op top of dnd-kit which should make this possible, but creating this really complicated and having it integrated into dnd-kit would probably be much more efficient.

[growthwp]

#280 (reply in thread)

Consider sharing your implementation in that post or, even better, in a post of your own. Even though we solved our issues, I'd still appreciate some extra reading. Just to see how people solve these issues.

[adagar]

Another year, another wish for event bubbling as an option; I'd like for different contexts to react to events in different ways, without blocking upstream events

[growthwp]

Solved here, in a non-hackish way, but there are some limitations. It's a long read, but it basically implies you're gonna be using just one context.

Reality is, dnd-kit will never be rewritten with this concept in mind. It's too mature now to go back to rewriting its core, and we're assuming that it even needs it. It probably doesn't, but unless Clauderic comes and definitely says that the current approach is much, much better in terms of performance (most of all) and other metrics, there's no reason not to have it as I suggested.

Regardless. Amazing library.

[adagar]

@growthwp I quite like this solution, and I think it'll be potentially helpful for our needs! I've already been leaning on the data object for draggables & droppables so that onDropOver can handle things differently depending on where/from things are going (working on a component library). The issue I was getting worried about was onDropOver becoming just absurdly bloated, but by having different components register their actions I think we could make it work.

And agreed, it really is an amazing library!