Discussion: placement of handles and flow of data

[spatialvlad]

I really like the great library that you guys have created. Our team is currently considering the option to start using react-beautiful-dnd instead of react-sortable-hoc we currently use.

However, it looks like there is a blocker for adopting your library for us due to inability to pass state/callback from Draggable into the onDragEnd of the DragDropContext. I hope I just missed the option in the documentation, but I did make a thorough search before opening the issue.

Your documentation recommends wrapping whole application with a DragDropContenxt. For most real-life production applications it means that DragDropContext will be multiple levels of hierarchy away form the Draggables. Even if multiple DragDropContexts are used, it is still very likely that the DragDropContext (probably with Droppable) will be not in the same file/component as the Draggables.

It is definitely not a big issue to create something like a top-level reducer inside of the onDragEnd that first filters results based on type, then applies corresponding logic, getting needed data from the Redux store. And this solution will work in some cases.

However, there are several drawbacks and even blockers with this approach:

It is extra work to get the Redux store data and process it in the corresponding onDragDrop reducer. This work was already probably conducted at the component level - Draggable or Droppable. And simply passing it would be much easier than trying to do it again.
Much bigger problem is that not all Component state lives in Redux store. This is a quite common and even recommened (e.g. reduxjs/redux#1287 ) behavior. This means that onDragEnd currently simply does not have a way to get needed state, unless substantial refactoring of existing code is done to put all needed state in a Redux store (and even then it might be not convenient).

Other libraries do not seem to have same limitation, as both offer a callback on the Draggable level to run after dragging ends.

E.g. React DnD offers endDrag for the DragSource. React-sortable-hoc has onSortEnd for the SortableComponent.

Your library looks superior to the above mentioned libraries in many aspects, but current limitation of not being able to define/pass a onDragEnd callback or at least some state from the Draggable is unfortunately greatly undermining its usability, especially if we are talking not about greenfield projects, but ones already developed and have lots of (presentational) state on the components level.

I hope I just missed some piece of the documentation and you can direct me where to have a look.

I did find something that seems related (but still does not seem to answer my question):
#120
#466

It would be really great if there actually was some way to pass a callback from Draggable. I would appreciate if you could help me find out how to do this.

Thanks.

[alexreardon]

Thank you for the thought-provoking issue. The core issue is that there is no clear recommendation for rolling up lots of lists into a single onDragEnd. It is difficult to make a recommendation as this library has no opinions about how you manage your state. Perhaps some additional hooks are a possible approach. There may even be some sort of nesting context approach that could work.

We have aimed to keep the api as light as possible. The understanding is that if we return the id of the things that have been dragging then a consumer should be able to look up whatever data they need from that id. If that data is unavailable then that is a separate issue that needs to be managed by your implementation.

A 'hack' to pass data now is to json encode your data as your id. Then you will get a json string as the id in your onDragEnd that you can parse. That is a hack, but it might be enough for you for now.

I will no open up the api to allow direct passing of data until we explore this problem more

[spatialvlad]

Thank you for your prompt reply to the issue and offering the ‘hack’.

I’ll discuss it with my team to see if they will be willing to adopt this approach, as it is still quite a bit less convenient compared what the currently library we are using is offering.

I really like that you are trying to keep the api of the library as light as possible. And it is great that as you say it “this library has no opinions about how you manage your state”.

My understanding that the core issue is that while react-beautiful-dnd does not have opinions about how state is managed, it is based on an assumption that all needed state is easily available to the onDragEnd either via a (redux) store, or via its placement in the same file as Draggable.

As I indicated above, it is often not the case, as it is common in the React/Redux world to have some state inside the components, not Redux. And big code-bases are very unlikely to have DragDropContext and Draggable in the same file.

Additional hooks/callbacks seem to be a good approach to solve the problem.

Anyway, thanks again for putting so much effort in this great library. I think that resolving the issue will help a much wider adoption of the library.

[Frozenlock]

I prefer to add functions inside the ID, rather than using json encoding.
In my case, I add source-fn and destination-fn to handle what is happening to the source droppable and destination droppable. Those functions are then extracted and called by the on-drag-end callback.

Those functions capture a reference to the state at level of the droppable component.
This means that the DragDropContext is completely independent from the droppable components.

[alexreardon]

Interesting @Frozenlock. Does that work with our current setup?

[Frozenlock]

It should work. (I'm still on version 6.)

The only caveat is that I'm using Clojurescript.
The principle should be the same however : store functions inside IDs and call those functions with the on-drag-end callback.

[alexreardon]

Very interesting. We currently say it needs to be a string, but I do not think we do any string operations on the values. As long as referential equality is maintained it could work. This gives some great food for thought. Thanks @Frozenlock !

[alexreardon]

I need to work through whether that would enable people to get done what they want to. Using a function is a brilliant idea

[Frozenlock]

Playing a bit around (with multiple droppables this time), here's what seems to work inside the droppable ID:

• String (obviously)
• Array
• Functions

Maps do not work.

Maps will be passed to the on-drag-end callback as expected, but things break when multiple droppables exist. (The equality test must break with maps...)

Here's a cool hack however :
An array with identifiers AND a map.
The identifiers will insure multiple droppables are not considered the same, and all sorts of goodies can be stored into the map to extract in the on-drag-end.

[alexreardon]

Thanks for looking into this @Frozenlock. Glad to hear there is an option for people to use today. I think it would be a good idea to formalise this and provide a better first class api - as simple as an extra prop on a draggable that is passed on all the hooks which could contain anything - data or a function.

For now it looks like users can hack the id to achieve this. Keep in mind though that this might have unexpected bugs as we assume the id is a string. Also, the id needs to be a unique identifier for the item so you will need to ensure that referential equality is never the same for multiple draggables

[alexreardon]

Adding a prop with a name like:

• data (clash with DOM data-*)
• meta
• params
• associated
• extra
  ...? Suggestions!?

to pass around to the hooks seems like a good idea.

Not sure what to name the prop though

[Frozenlock]

extra or params convey the intention pretty well I think.

This field would be available at the top level (with the draggableId), and also inside the source and destination fields, allowing the user 3 different entry points for extra data. Is that it?

[alexreardon]

Details to be confirmed, but something like that.

[Frozenlock]

Upgraded to 7.x.x, doesn't work anymore. 😢

Warning: Failed child context type: Invalid child context private-react-beautiful-dnd-key-do-not-use-droppable-id of type array supplied to Droppable, expected string.

Hopefully the new field will make its way in the next version.

[davps]

Thank you guys for the ideas you shared on this subject. Based on it, I decided to pass stringified objects. The onDragEnd function arguments structure the information by draggable and droppables for source and destination, so, I followed the same pattern. The example below shows how I am using it:

The droppableId property of my <Droppable> source looks like this:

droppableId={JSON.stringify({
	id:'droppable_people', 
	table: 'people'
})}

The droppableId property of one of my <Droppable> destination looks like this:

droppableId={JSON.stringify({
	id:team.id, 
	table: 'team'
})}

Passing the objects (stringified in this case) is useful to manage my hierarchies since I have different kinds of draggables, for example, the draggableId of my <Draggable> looks like this:

draggableId={JSON.stringify({
  id:people.id, 
  table: 'people'
})}

or like this:

draggableId={JSON.stringify({
  id:task.id, 
  table: 'task'
})}

so on my onDragEnd function handler of my <DragDropContext> I parse the objects:

const params = {
  droppable: {
    source: JSON.parse(source.droppableId),
    destination: JSON.parse(destination.droppableId) 
  },
  draggable: JSON.parse(result.draggableId)
};

and use it as needed, for example, on those conditions:

if(params.droppable.source.id === 'droppable_people' && 
	params.droppable.destination.table === 'team' )

and

if(params.droppable.source.table === params.droppable.destination.table)