Я пытаюсь реализовать универсальный c модуль Drag-and-Drop, который я могу или не могу выпустить на NPM.
Я вдохновился уже существующим модулем DnD, который состоял из по существу, два основных компонента: Draggables и DropZones.
Компоненты Draggable позволят перетаскивать любой вложенный контент, а DropZones - это компоненты, которые будут реагировать, когда * Компонент 1009 * был перетащен в / из них и / или сброшен на них.
Функциональность модуля была слишком базовой c для того, что мне было нужно, поэтому я решил создать свой собственный.
Все шло хорошо, за исключением одного аспекта: измерения абсолютного положения большого числа компонентов, чтобы найти их соответствующие ограничивающие формы для обнаружения столкновения.
В настоящее время я ' Однако мы использовали метод View's measure для измерения абсолютного положения и размера моих компонентов, однако, если вы вызываете этот метод слишком много раз в течение короткого периода времени мне, React Native выдаст эту ошибку: Warning: Please report: Excessive number of pending callbacks: 501. Some pending callbacks that might have leaked by never being called from native code, и он перечислит метод, вызывающий сбой, как {"module":"UIManager","method":"measure"}.
Если я сделаю базис c for l oop, который неоднократно вызывает measure метод, я могу получить до 500 итераций до того, как React Native пожалуется (это число может зависеть от аппаратного обеспечения; Я не уверен).
Кроме того, такая же проблема возникает при использовании View's других методов измерения (например, measureInWindow, measureLayout).
Еще хуже то, что до сих пор я вызывал measure метод в View's onLayout обратном вызове, однако недавно я обнаружил, что onLayout не не вызывается при изменении стиля, который не влияет непосредственно на данный View (например, когда изменяется поле родительского компонента).
Это означает, что данные компоненты могут быть перемещены (относительно экрана) без их ведома об этом.
Из-за этого мне придется использовать другие способы уведомления моих компонентов о том, что они должны себя заново измерить.
Я подумал об использовании некоторых методов жизненного цикла, которые относятся к к обновлениям компонентов, но это, скорее всего, будет еще хуже, потому что большинство из них вызывается каждый раз, когда происходит обновление компонентов, которое происходит гораздо чаще, чем макет.
Редактировать: Один другой Проблема с использованием методов жизненного цикла, относящихся к обновлениям компонентов, заключается в том, что родительский компонент препятствует обновлению дочерних компонентов (например, через shouldComponentUpdate).