バグを説明する
useDropのドキュメントによると、仕様オブジェクトのメンバーaccept
は、「文字列、ES6シンボル、いずれかの配列、またはコンポーネントの小道具を指定してこれらのいずれかを返す関数」です。
ただし、コードでは、 accept
はTargetType
として定義されています。これは、 string | symbol
またはそれらの配列です。
予想される行動
accept
は、 TargetType
を返す関数が可能なタイプである必要があります。
追加のコンテキスト
accept
を動的に更新したい。 accept
のuseDrop
$の値を変更することでこれが可能になると思いましたが、これは機能しません。 私は現在、これを他の方法で行う方法がわかりません。また、ドキュメントに記載されている動作を見つけることができません。
これが理想的な解決策ではないことはわかっていkey
が、これが解決され、ターゲットの型生成関数を使用できるようになるまで、回避策は、ターゲットをドロップします。 これにより、許容可能なタイプを変更すると、確実に再マウントされます。 今日、私はこの正確な問題に遭遇しました。
私もこれに気づきましたが、 canDrop
を使用して回避しました。
これが理想的な解決策ではないことはわかってい
key
が、これが解決され、ターゲットの型生成関数を使用できるようになるまで、回避策は、ターゲットをドロップします。 これにより、許容可能なタイプを変更すると、確実に再マウントされます。 今日、私はこの正確な問題に遭遇しました。
このコメントをエコーするだけです。ブール値に基づいて同じコンポーネントの2つのバージョンをレンダリングしているターナリがある状況がありました。 賢い反応は、それらが同じコンポーネントであるが、異なる小道具を持っていることに気づきました。 このターナリを使用して、ブール値に基づいてマウント/アンマウントする独立したノードとしてレンダリングしようとしましたが、実際には再マウントではなく再レンダリングされていました。 したがって、 accept
は新しい小道具ではなく元の小道具に基づいており、 useDrop
はその小道具の変更に基づいて更新されません。
最も参考になるコメント
これが理想的な解決策ではないことはわかってい
key
が、これが解決され、ターゲットの型生成関数を使用できるようになるまで、回避策は、ターゲットをドロップします。 これにより、許容可能なタイプを変更すると、確実に再マウントされます。 今日、私はこの正確な問題に遭遇しました。