А
Плохой метод
Size: a a a
2020 July 29
Б
Плохой метод
а по другому никак
Д
Кто работал с MutationObserver, подскажите как избавиться от зацикливания. Допустим я смотрю за количеством дочерних елементов, и когда оно изменяется удаляю последний. Но это удаление опять триггерит этот обзервер.
А
а по другому никак
Практически всё можно метриками заменить.
Б
Практически всё можно метриками заменить.
это как?
А
Кто работал с MutationObserver, подскажите как избавиться от зацикливания. Допустим я смотрю за количеством дочерних елементов, и когда оно изменяется удаляю последний. Но это удаление опять триггерит этот обзервер.
Условие?
А
В
Кто работал с MutationObserver, подскажите как избавиться от зацикливания. Допустим я смотрю за количеством дочерних елементов, и когда оно изменяется удаляю последний. Но это удаление опять триггерит этот обзервер.
В mdn пишут про прерывание методом disconnect() и перезапуск методом observe()
Д
Метод обсерв не перезапускает, а создает новый
Д
Как и дисконект, не отключает, а удаляет.
В
Хм, а это не подойдет?
Д
Вы и сами должны понимать, что это далеко не елегантное решение.
В
Да понимаю...
А
Вы и сами должны понимать, что это далеко не елегантное решение.
Если возникает необходимость фиксить рекурсию - это значит, что и так что-то пошло уже "не елегантно"
Б
да, но через метрики не получить transition-duration который задается с класса
Д
Условие?
В голову приходит условие на двойной триггер, который будет разрывать зацикленность. Но опять же, далеко от "нормального"
Д
Дык я про это и спрашиваю, наверное должен быть какой-то нативный или общепринятый способ.
Б
Не, нифига. У stream.pipeline последним аргументом коллбек должен быть.
сенкс, точно провтыкал колбек для ошибок )))
V
Кто работал с MutationObserver, подскажите как избавиться от зацикливания. Допустим я смотрю за количеством дочерних елементов, и когда оно изменяется удаляю последний. Но это удаление опять триггерит этот обзервер.
не запускать там то, что меняет дом
V
это то же самое что в рендере менять стейт