Skip to content

Instantly share code, notes, and snippets.

@Itsthatotherguy
Last active April 8, 2022 13:38
Show Gist options
  • Select an option

  • Save Itsthatotherguy/8504b80985b342c36faeab39ed0f20f8 to your computer and use it in GitHub Desktop.

Select an option

Save Itsthatotherguy/8504b80985b342c36faeab39ed0f20f8 to your computer and use it in GitHub Desktop.
beautiful-dnd bug
This is a transcript of the messages I sent on the Slack channel.
Regarding the custom unit problem - The problem stems from a bug in the beautiful-dnd library. I can account for it but it's only a matter of time before they fix it, which will then break the functionality again. What do you reckon the right move is here?
The Draggable component has a prop - disableInteractiveElementBlocking. However, if you follow the code, you eventually arrive at this code block in their library:
export function PublicDraggable(props: PublicOwnProps) {
// default values for props
const isEnabled: boolean =
typeof props.isDragDisabled === 'boolean' ? !props.isDragDisabled : true;
const canDragInteractiveElements: boolean = Boolean(
props.disableInteractiveElementBlocking,
);
const shouldRespectForcePress: boolean = Boolean(
props.shouldRespectForcePress,
);
return (
<PrivateDraggable
{...props}
isClone={false}
isEnabled={isEnabled}
canDragInteractiveElements={canDragInteractiveElements}
shouldRespectForcePress={shouldRespectForcePress}
/>
);
}
What seems to be blocking input elements is this canDragInteractiveElements. Do you agree that if we have the prop disableInteractiveElementBlocking={true}, that is going to set canDragInteractiveElements to true as well? This essentially does an event.preventDefault() on input elements so that they can be dragged.
So if I set the prop on our side to false, then it works as expected - but how long before they correct their mistake and lead us down the same road again.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment