React-beautiful-dnd: Conditionally dropping

[h182032]

I have two task lists. The one on the left has all the tasks in the beginning and the right one is empty. In the right list i only want to be able to drop maximum 3 tasks. How can I disable the drop when i have three items (max) in the right list? How do i check if it is 3 items in the right list?

I'm not sure how i can use the isDropDisabled prop

[alexreardon]

This should be what you are after: https://egghead.io/lessons/react-conditionally-allow-movement-using-react-beautiful-dnd-draggable-and-droppable-props

[StreetStrider]

@alexreardon,

I've faced more complicated version of this issue, where isDropDisabled is not enough.

I got multiple Droppable areas with requirement to have max items per Droppable of N.

My first solution was to set up isDropDisabled per Droppable depending on limit of items in that area. This prevents additions of items but it has drawback: it becomes impossible to rearrange items in such area, since isDropDisabled = true.

So, I move on to the second solution. I set up a distinct type for Droppable where limit is reached. Consider, each Droppable got type = default and areas with limit reached got type = isolated_id where id is DroppableId. This prevents additions and allows rearrangement, but another drawback occur: it is not possible to move elements out of such isolated Droppable.

Right now I am forced to move my logic to onDragEnd phase, where I can manually cancel drops to limited Droppables before setState without having strong drawbacks. However, with this method user will still see visual effects like dragging is possible, in cases where it is not.

Best solution from my point of view is to make:
isDropDisabled?: boolean | (destination, source) => boolean,
allow predicate function for isDropDisabled depending on destination and source (identical to such for onDragEnd).
Not only it will solve my case, but it will solve many other possible cases, since it is the most generic solution. This would allow developers to create their own type logic (#1761, #847) of any complexity and solve any other complex relationships between Droppables on their side.

[StreetStrider]

1239 reveals the same idea.