React-dnd: El tipo de aceptación useDrop DropTargetHookSpec debe incluir un tipo de función

Creado en 20 ago. 2020 · 3Comentarios · Fuente: react-dnd/react-dnd

Describa el error
Su documentación de useDrop dice que el miembro del objeto de especificación accept es "Una cadena, un símbolo ES6, una matriz de cualquiera, o una función que devuelve cualquiera de esos accesorios del componente dado".
Pero en el código , accept se define como TargetType , que es string | symbol o una matriz de esos.

Comportamiento esperado
accept debe ser un tipo en el que sea posible una función que devuelva TargetType .

Contexto adicional
Quiero actualizar accept dinámicamente. Pensé que esto sería posible cambiando el accept de useDrop pero esto no funciona. Actualmente no veo cómo hacer esto de otra manera y no puedo encontrar el comportamiento que describe la documentación.

Fuente

TheBolliwood

👍2

Comentario más útil

Sé que esta no es una solución ideal, pero hasta que se resuelva y podamos tener funciones de producción de tipo de destino, una solución alternativa sería usar una propiedad key igual a sus tipos aceptados en el componente que contiene su soltar objetivo. Esto aseguraría que se vuelva a montar una vez que cambie los tipos aceptables. Acabo de encontrarme con este mismo problema hoy mismo.

johanneslumpe en 20 ago. 2020

👍2

Todos 3 comentarios

johanneslumpe en 20 ago. 2020

👍2

También noté esto, pero lo solucioné usando canDrop .

dhulme en 6 oct. 2020

👍1

Sé que esta no es una solución ideal, pero hasta que se resuelva y podamos tener funciones de producción de tipo de destino, una solución alternativa sería usar una propiedad key igual a sus tipos aceptados en el componente que contiene su soltar objetivo. Esto aseguraría que se vuelva a montar una vez que cambie los tipos aceptables. Acabo de encontrarme con este mismo problema hoy mismo.

Solo para repetir este comentario: tuve una situación en la que tenía un ternario que estaba representando dos versiones del mismo componente basado en un booleano. Clever reaccionar se dio cuenta de que son el mismo componente pero con diferentes accesorios. Aunque traté de usar este ternario para representarlos como nodos independientes que se montan/desmontan según el valor booleano, en realidad se estaba volviendo a representar en lugar de volver a montar. Por lo tanto, el accept se basó en los accesorios originales, no en los nuevos, y useDrop no se actualiza en función del cambio de ese accesorio.