Décrivez le bogue
J'ai une cible de dépôt connectée qui est supprimée du DOM, une fois que quelque chose y est déposé.
Maintenant, depuis la mise à niveau vers v7.1.0
, je reçois
Uncaught TypeError: Cannot read property '0' of undefined
dans l'appel monitor.isOver()
à l'intérieur de la fonction collect
.
D'une manière ou d'une autre, il voit que la fonction collect est toujours appelée une fois de plus, après la suppression de la cible de dépôt ( targetId
n'est pas défini).
Intéressant
6.0.0
résolu le problème.setTimeout
autour de mon rappel qui a supprimé la cible de dépôt, a résolu le problème.Une idée de ce qui pourrait causer ça ?
Reproduire
Étapes pour reproduire le comportement :
monitor.isOver()
en collect
drop(...)
qui supprime la cible de dépôtComportement prévisible
Il n'y a pas de problème de synchronisation avec isOver
et les cibles de dépôt peuvent être immédiatement supprimées.
Captures d'écran
Bureau (veuillez compléter les informations suivantes) :
7.1.0
Même problème
J'ai essayé d'annuler ce changement https://github.com/react-dnd/react-dnd/commit/0feb250b7ee90483e31f3bc159ebf946980d53a7#diff -ac418ba19283aec1fb0b70e6570c5613 et résolu .. .
Même problème.
En attente de correction.
Retour à la v7.0.2
Confirmé que nous recevons le même problème - Le retour à 7.0.2 résout le problème
Cela est dû au fait que le changement à 0feb250b7ee90483e31f3bc159ebf946980d53a7 permet à l'ID cible d'être undefined
mais personne n'a vérifié le PR avec ce changement pour isOverTarget
Actuellement, son prototype est :
public isOverTarget(targetId: string, options = { shallow: false })
contrairement aux autres fonctions qui ont changé dans ce pr qui déplacent targetId
/ sourceId
vers
targetId: string | undefined
sourceId: string | undefined
et vérifie:
if (!targetId) {
return false;
}
Un correctif pour ce problème sera de vérifier que targetId
est undefined
ici : https://github.com/mattkrick/react-dnd/blob/aafcf7d67f8b3a2035b561e97b7874e1064447e4/packages/dnd-core/src /DragDropMonitorImpl.ts#L128
Cela devrait être corrigé par le PR de cfrank dans une version aujourd'hui
Incroyable, les gars, merci @cfrank
Commentaire le plus utile
Cela devrait être corrigé par le PR de cfrank dans une version aujourd'hui