alexreardon
commented
3 weeks ago Hi @IanBellomy, this was a fun issue to read 😆. Right now it is a design decision to help with consistency.
For Pragmatic drag and drop events:
- events follow bubble ordering
- events flow from draggable → drop target(s) [dom bubble order] → monitor(s) [registration order]
- events cannot be stopped. Generally speaking, Event stopping is dangerous (link from egghead course). This is often the main reason folks need to leverage capture / bubbling - to stop other listeners from being hit.
For simplicity we have gone with only bubble ordering for now, as there is a way to achieve the same outcomes. Usually capture event ordering is important, you can 'pull up' the inner event listener (I know that was something you were hoping to avoid)
So, let's take a look at how we could achieve your desired outcomes:
- You could listen to events on the child using a
monitor(which will come after drop targets) and the parent using drop target events. That way you could make the child events come second. - You could pull the logic out of the worker (something you were not keen to do) and put it at a higher level
- You could capture all the events and replay them in capture order using your own mechanism if you want to
- All events share the same
eventobject - so you could add additional information to it as it passes through the system to let other event listeners know that particular outcomes have already occurred.
I am open to adding a capture phase, it just introduces another concept that I think the vast majority of folks won't need to know about 🤔 .
Closing this issue for now, but please feel free to open a discussion if you want to continue chatting about this
Running into a case where handling drop events in the capture phase seems ideal, but though this is possible with native DnD API, it's not covered in PDnD.
Is that by design or just the current state of the library?
Example 1 --
Consider a board showing todos, workers and teams. Workers belong to teams. Todos must belong to teams and may belong to a worker on that team — perhaps for 'reasons' a todo assignment to a worker must be prefaced (however immediately) by assignment to that worker's team.
An admin drags a todo from the Worker 1 on the Team 1 panel to Worker 1 on Team 2.
It seems preferable if the parent team-element's handler was narrowly and solely responsible for triggering team assignment during capture phase and, afterwards, the child worker element's drop handler was narrowly and solely responsible for worker assignment.
Handling the events in bubbling order means mixing team and worker assignment somewhere at some point or making under the hood changes to assignment logic, which smells funny.
Example 2 --
Consider a Risk-like board game with dudes on a map but with a deep nesting of countries, provinces, cities etc, and where moving dudes from one country's province's city to another country's province's city would require handling higher level boundary changes before the lower ones as they might interrupt the move. If the game is set in stone a master handler is probably fine, but if its life involves more churn ('interplanetary travel dlc incoming!'), more narrowly scoped top-down handling could be useful.