Как стать автором
Обновить

Комментарии 10

Все бы хорошо, но, кажется, про делегирование в реакте никто и не забывал...

НЛО прилетело и опубликовало эту надпись здесь
Перед тем как писать статью гуглил и толком нечего не нашёл. А по поводу оптимизации из коробки — когда проверял (в случае с мапом) регистрация обработчика все же происходит.
регистрация обработчика все же происходит

Регистрация обработчиков. У вас там на каждую кнопку создаётся новая функция, которую ничего не связывает с другими кнопками и их обработчиками. Плохая практика, кстати, т.к. часто приводит к ненужным перерисовкам.

Зачем в 2019 все эти пляски с attachEvent?


Как было сказано выше — про делегирование никто не забывал, просто зачастую разработчику при обработке события чаще нужны ассоциированные с элементом данные, а не сам элемент. Что предлагаете делать, если нужно увеличить счётчик на указанное на кнопке значение?


[ 10, 200, 3000].map(
  value => <button>+{ value }</button>
)

Добавлять к элементу атрибут с значением и читать его в обработчике из DOM? По ид элемента определять значение используя некий map/array? Читать из innerHTML? Это все плохие практики. Нечто подобное гораздо проще и эффективнее:


[ 10, 200, 3000].map(
  value => <button on lick={ () => increment(value); }>+{ value }</button>
)
Добавлять к элементу атрибут с значением и читать его в обработчике из DOM?

Вообще data-атрибуты для этого и были придуманы.
Нечто подобное гораздо проще и эффективнее:

Откуда такая уверенность? Могу предположить, что эффективность как минимум зависит от числа кнопок. Ну и на ненативных элементах часто врубают react/jsx-no-bind.
Вообще data-атрибуты для этого и были придуманы.

Да, только это было придумано до React'а. Последний исповедует декларативный подход и предполагает минимум манипуляций с DOM и уж точно не с целью передавать через него данные.


Откуда такая уверенность?

Речь шла именно о приложении, разработанном с применением React.

Речь шла именно о приложении, разработанном с применением React.

Так вы проверяли что такой способ эффективнее? Просто у меня вот был неудачный опыт с тормозами в списках и решения вроде байндинга в конструкторе создаваемого компонента или кастомного shoulComponentUpdate мне не показался элегантнее.

Если речь о эффективности с точки зрения производительности, то нет, конкретных замеров я не проводил. Тем не менее, хранение значений состояния в DOM как минимум приводит к усложнению управления им и эффекту, который я бы назвал "раскрытием деталей", когда нечто внутреннее (состояние) берется извне — внешние компоненты могут взаимодействовать с состоянием (а следовательно и поведением) наших компонентов. Например, что если между рендером и вызовом callback'а по некоторой причине значения data- атрибутов изменятся?


Я не очен понял, при чем тут shouldComponentUpdate(), мы ведь вроде говорим о подписке на события. Возможно, Ваш неудачный опыт был связан с неправильным использованием key атрибутов или отсутствием мемоизации. Трудно говорить без конкретных примеров.

Пример, который требовал оптимизации
pastebin.com/JBj7cHHs
пример оптимизации через data-id
pastebin.com/xXEm2jiK
другие примеры оптимизации, которые ИМХО не сильно лучше
pastebin.com/KzDfd7E8
pastebin.com/JxdPd1kw

Рендерить нужно было проводник с файлами.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории