Possible API refactoring

[a-teammate]

As mentioned in slack, I just took some notes for myself reading through the code (where I also learnt a lot!) and afterwards thought I could share them here :)

• It would be nice to have a mix of the lower-level API used internally (e.g. The Msg type) also exposed, so that the same dnd system can be used for both. E.g. when I drag an item onto the headline of the list, it might be included at the end of the list.

  • Another example is that I want to include a certain action when the drop is executed (transferring an item between two different groups): The action is to sync back the dnd list (which is flat) to the actual datastore (which isnt flat), so I imagine that is a pretty common operation.
  • Possible solution: pass in the low-level dnd config to the higher level dndList one, so people could customize that one? Could also serve as sophisticated replacement for the beforeUpdate hook.
  • Alternative solution: ir4y/elm-dnd like basic functionality, but helpers for lists added on top.

• config for groups might deserve a more tailored structure?

  • it confused me why operation is in there twice.
  • maybe Config { insideGroup = { }, acrossGroups = { } } would mark that difference in structure?
  • "comparator" and "setter" are terms common in other languages (mostly OOP ones). Still I think in this place a distinct name could make it a bit easier to grasp? Like "isSameGroup" or "changeGroupOp"? Might also be dissolved by clearer docs.