React-dnd: Le type d'acceptation useDrop DropTargetHookSpec doit inclure un type de fonction

Créé le 20 août 2020 · 3Commentaires · Source: react-dnd/react-dnd

Décrivez le bogue
Votre documentation de useDrop indique que le membre d'objet de spécification accept est "Une chaîne, un symbole ES6, un tableau de l'un ou l'autre, ou une fonction qui renvoie l'un ou l'autre, étant donné les accessoires du composant.".
Mais dans le code , accept est défini comme TargetType , qui est string | symbol ou un tableau de ceux-ci.

Comportement prévisible
accept devrait être un type où une fonction qui retourne TargetType est possible.

Contexte supplémentaire
Je veux mettre à jour accept dynamiquement. Je pensais que cela serait possible en modifiant la accept de useDrop mais cela ne fonctionne pas. Je ne vois actuellement pas comment faire autrement et je ne trouve pas le comportement décrit dans la documentation.

Source

TheBolliwood

👍2

Commentaire le plus utile

Je sais que ce n'est pas une solution idéale, mais jusqu'à ce que cela soit résolu et que nous puissions avoir des fonctions de production de type cible, une solution de contournement consisterait à utiliser une propriété key égale à vos types acceptés sur le composant qui contient votre cible de chute. Cela garantirait qu'il se remontait une fois que vous avez modifié le ou les types acceptables. Je viens de rencontrer ce problème exact moi-même aujourd'hui.

johanneslumpe le 20 août 2020

👍2

Tous les 3 commentaires

johanneslumpe le 20 août 2020

👍2

J'ai remarqué cela aussi, mais je l'ai contourné en utilisant canDrop .

dhulme le 6 oct. 2020

👍1

Je sais que ce n'est pas une solution idéale, mais jusqu'à ce que cela soit résolu et que nous puissions avoir des fonctions de production de type cible, une solution de contournement consisterait à utiliser une propriété key égale à vos types acceptés sur le composant qui contient votre cible de chute. Cela garantirait qu'il se remontait une fois que vous avez modifié le ou les types acceptables. Je viens de rencontrer ce problème exact moi-même aujourd'hui.

Juste pour faire écho à ce commentaire : j'ai eu une situation où j'avais un ternaire qui rendait deux versions du même composant basé sur un booléen. Clever react s'est rendu compte qu'il s'agissait du même composant mais avec des accessoires différents. Bien que j'aie essayé d'utiliser ce ternaire pour les rendre sous forme de nœuds indépendants qui montent/démontent en fonction du booléen, il s'agissait en fait d'un nouveau rendu au lieu d'un remontage. Ainsi, le accept était basé sur les accessoires d'origine, pas sur les nouveaux, et useDrop ne se met pas à jour en fonction du changement d'accessoire.