Как сделать несколько событий?

Question

[offsiderst]

сейчас работает только по отдельности
https://jsfiddle.net/1r9dkvmg/

Answer 1

[Николай Ланец]

Нельзя так перечислить несколько событий. Смотрите доку: https://developer.mozilla.org/ru/docs/Web/API/Even...

type
Чувствительная к регистру строка, представляющая тип прослушиваемого события.

То есть только один тип события.
Но можно несложный цикл организовать. Так работает.

['click', 'mouseover']. map(type => document.querySelector('.o').addEventListener(type, (event)=> {
  console.log(event.type, document.querySelector('.o').textContent);
}))

Comments

[WbICHA]

Только не мап, а форыч, и не document.querySelector('.o'), а имя переменной, в которой ссылка на ноду.

[Николай Ланец]

А чем мап не нравится? Аргументируйте, плиз.

и не document.querySelector('.o'), а имя переменной, в которой ссылка на ноду.

Это да, но я хотел максимально оставить исходный код автора.

[WbICHA]

Николай Ланец, а нам нужен результирующий массив?

[Николай Ланец]

Вопросом на вопрос? Так себе аргумент...
В общем, получается из серии "Доколупаться до пунктуации". Забываем заповедь "Работает - не лезь".
Со своей же стороны отмечу, что привык использовать map по двум причинам:
1. Короче (имеется ввиду map короче, чем forEach).
2. Замыкания и безопасность исходного массива (чтобы внутри цикла не изменить случайно элементы массива, если это массив не просто скаляров, а объектов).
Так что в данном случае утверждение "Надо использовать forEach вместо map" выглядит очень необоснованным и лишним.

[Дмитрий Беляев]

WbICHA, я бы еще добавил, что создание функции нужно выносить за цикл, а не плодить миллион однотипных
Николай Ланец, вот Вам так удобнее/короче наговнокодить, а потом у людей web/electron тормозят и имеют дурную славу...

1. Короче (имеется ввиду map короче, чем forEach).

а заодно выполняет гораздо больше действий под капотом, среди которых создание нового массива исходного размера, а значит дополнительные аллокации/резервирования памяти и приближение такта сборки мусора.

2. Замыкания и безопасность исходного массива (чтобы внутри цикла не изменить случайно элементы массива, если это массив не просто скаляров, а объектов).

Вообще бред. forEach не мутирует исходный массив и замыкание точно такое же делает. В чем безопасность то выше у map?

[Николай Ланец]

Дмитрий Беляев, Дмитрий, на личности не хорошо переходить. Но раз уж пошла такая пляска...
Разжевывать особо не буду. Я могу не так выразиться или ошибиться. Но личные практики были, что в итоге окончательно перешел на map.
Но вот небольшое гугление дало: https://senior.ua/articles/4-osnovnyh-razlichiya-m...

3. Изменчивость
map() возвращает совершенно новый массив с преобразованными элементами и тем же количеством данных. В случае forEach(), даже если он вернется undefined, он изменит исходный массив с помощью callback.

Поэтому что map() опирается на неизменность и forEach() является мутатором.

И ежели уж говорить про быдлокодинг, то, к сожалению, ваш уровень оценить не могу, ибо "бородатый программист" видимо сильно занят "менторством начинающий программистов" и не может сделать себе сайт https://d-belyaev.ru/

Посетите мой быдлопроект https://freecode.academy/ и прикиньте сами, как быстро сможете сделать такое и лучше. Вам даже исходники в помощь: https://github.com/freecode-academy/freecode.academy

А так, вы явно забыли про принципы "Преждевременной оптимизации". У меня не было задачи дать наилучший вариант. Я всего лишь подсказал направление. Но набежали супероптимизаторы... Лишнее все это.

[Дмитрий Беляев]

Николай Ланец, на личности никто не переходил, это Ваши влажные фантазии, как и назвать некий проект своим, сделав одноименный репо на гитхабе, который к тому же "forked from prisma-cms/nextjs" и самый старый коммит в котором датируется 11 октября 2020... Ну и вообще странное суждение у Вас о профессионализме, по тому что на личном домене висит заглушка...

Кстати, натыканный наугад "урок": https://freecode.academy/learn/exercises/587d7b7b3...
И у меня уже сочувствие, к тем кто по этому так сказать материалу будет учится...

А можно воспроизводимый пример, как forEach мутирует массив, а не статью ноунейма с ресурса где любой студент может писать статьи для зачета?

[Николай Ланец]

Вы, видимо, совсем не понимаете что значит "переходить на личности", но объяснять не буду. Если в таком возрасте не поняли, то уже и не поймете.

как и назвать некий проект своим, сделав одноименный репо на гитхабе, который к тому же "forked from prisma-cms/nextjs" и самый старый коммит в котором датируется 11 октября 2020...

Мои проекты, сколько хочу, столько и форкаю. prisma-cms - тоже мой проект. Про него писал здесь: https://habr.com/ru/post/448982/
Почему prisma-cms.com переименовался, написал здесь: https://freecode.academy/topics/prisma-cms.com-per...
Можете все это не читать, просто пруфы приложил.

Кстати, натыканный наугад "урок": https://freecode.academy/learn/exercises/587d7b7b3...
И у меня уже сочувствие, к тем кто по этому так сказать материалу будет учится...

Вообще-то это уроки с https://github.com/freeCodeCamp/freeCodeCamp, у которого почти 320 000 звезд.
Если вам не нравится, можете сделать лучше. А вот судя по звездам, много кому нравится там учитЬся.
Хотя сам считаю, что материал довольно сильно отстает от современных реалий.

А можно воспроизводимый пример, как forEach мутирует массив, а не статью ноунейма с ресурса где любой студент может писать статьи для зачета?

К примеру, так:

arr = [1,2,3]
arr.forEach((val, index, scope) => {
scope[index] = val * 2;
})
console.log(arr);
// 2,4,6

Вероятнее всего имелось ввиду, что если вы захотите как-то повлиять намассив, то вы обязательно измените исходный. А если не хотите его менять, то надо сначала объявить новый результирующий массив, чтобы его передать как параметр, и в него уже пушить новые элементы. Как по мне, так все это не удобно. А юзать два разных подхода для схожих задач, просто потому что вроде как чуть-чуть быстрее - ИМХО оверхед.

На том откланяюсь. Сходите еще с кем-нибудь поспорьте.

[eRKa]

Дмитрий Беляев,

["1", "2", "3"].forEach((el, i, arr) => {const a=arr.splice(0, 1); console.log(a,arr);})

Вообще странный спор. В данном случае нет разницы что использовать. Map обычно используется, когда КАЖДЫЙ элемент массива надо преобразовать во что-то другое и вернуть его как новый массив, в примере ответа имя события преобразуется в объект слушателя этого события.

Т.к. нам не нужен результат преобразования в виде массива, то можно использовать и forEach.

Если бы внутри нужно было эти преобразования делать по условию, например, решать на какой тип в каком случае добавлять слушателя, а в каком нет, то map не подошел бы, т.к. он он обязательно должен вернуть на каждый параметр, какой-то новый.

[offsiderst]

Николай Ланец, спасибо. а так - тоже можно? или нежелательно?

elem.addEventListener('mouseover', event=> {
  func();
})

elem.addEventListener('click', event=> {
 func();
})

[Николай Ланец]

offsiderst, Не за что!
Так можно, но просто повторение кода получается. К тому же события часто еще и снимать надо, то есть использовать node.removeEventListener(type, func), и если использовать единый массив названий типов, используя его так же в цикле можно и снять все события.

[WbICHA]

WbICHA, я бы еще добавил, что создание функции нужно выносить за цикл, а не плодить миллион однотипных

Дмитрий Беляев, разве движок это не оптимизирует?

map() возвращает совершенно новый массив с преобразованными элементами и тем же количеством данных. В случае forEach(), даже если он вернется undefined, он изменит исходный массив с помощью callback.

Поэтому что map() опирается на неизменность и forEach() является мутатором.

Николай Ланец, полный бред, противоречащий официальной документации. И реальности.
Серьёзно, ссылаться на какую-то левую статью, когда есть официальная документация и консоль в браузере ─ это сильно.

Вероятнее всего имелось ввиду, что если вы захотите как-то повлиять намассив, то вы обязательно измените исходный. А если не хотите его менять, то надо сначала объявить новый результирующий массив, чтобы его передать как параметр, и в него уже пушить новые элементы.

Это троллинг такой или что? Заменить forEach на map секундное дело, раз доступ к офф документации у вас закрыт. Внутри каллбека 3ий аргумент ─ это итерируемый массив, а не новый.
Иными словами, вы своим примером сами себе яму и выкопали.

В данном случае нет разницы что использовать.

eRKa, действительно. Просто пройтись по массиву или создать новый массив и пройтись по всему массиву. Всего-то в 10 раз медленнее.

[eRKa]

WbICHA, Объект, это ссылочный тип и, по сути, map вернет массив ссылок на объекты, которые и так будут созданы при добавлении слушателя. Просядке по профиту Вы не почувствуете даже на 1000 элементах. Я специально уточнил, что

В ДАННОМ случае нет разницы

Если бы, при проходе по массиву с помощью map предполагалось, что это будет список на 100к+ элементов и при этом еще и создавались новые объекты, которые бы не создавались при проходе с помощью forEach, то вариант с forEach, конечно же, был бы предпочтительнее.

Нет смысла заниматься оптимизацией прохода списка из 2-3 элементов, причем этот список в таком виде будет проходится один раз при инициализации.

[WbICHA]

Объект, это ссылочный тип

eRKa, спасибо за просвещение, только в примерах выше нет объектов. Конечно, если вы не имеете ввиду массив, что, конечно, тоже верно, но всё же под объектом подразумевается именно объект.

Нет смысла заниматься оптимизацией прохода списка из 2-3 элементов

Это дело привычки. Если ты привыкаешь использовать мап тогда, когда это уместно, то хоть в массиве будет 2, хоть 2 000 000 элементов, ты будешь применять те методы, которые актуальны.
Или вы действительно думаете, что человек, который не обращает на подобное в малом коде, будет действительно обращать на это в большом? Разве что при рефакторинге, но это дополнительное время и силы.

[Дмитрий Беляев]

разве движок это не оптимизирует?

WbICHA, к сожалению нет, по просту не может, иначе бы removeEventListener работал некорректно. Там что то вроде Set<EventListener> под капотом, поэтому

for(let i = 0; i < 10; i++) {
  node.addEventListener('event', () => {});
}

сожрет в 10 раз больше памяти, чем

const f = () => {};
for(let i = 0; i < 10; i++) {
  node.addEventListener('event', f);
}

Не говоря уж о том, что каждая из этих функций компилируется и оптимизируется по отдельности.
По крайней мере в v8 так, другие движки я не раскапывал.

[Дмитрий Беляев]

К примеру, так:

arr = [1,2,3]
arr.forEach((val, index, scope) => {
scope[index] = val * 2;
})
console.log(arr);
// 2,4,6

Николай Ланец, и чем map меня защитит от такого быдлокода?

const arr = [1,2,3]
arr.map((val, index, scope) => {
  scope[index] = val * 2;
});
console.log(arr); // 2,4,6

[WbICHA]

Дмитрий Беляев, интересно, спасибо за информацию.
То есть с точки зрения оптимизации имеет больше смысла делать так:

const f = (a, b, e) => { ... };
// loop
  .addEventListener('click', f.bind(null, 1, 2));

нежели так?

const f = (a, b) => (e) => { ... };
// loop
  .addEventListener('click', f(1, 2));

Хотя я не уверен пройдёт ли оптимизация через бинд.
Или в обоих случаях будет оптимизация? Чёт я совсем запутался. :/

[Дмитрий Беляев]

WbICHA, bind так же под капотом создает функцию, так что в обоих случаях количество хранимых в памяти функций будет линейно зависеть от количества итераций.
Но вот затраты ресурсов будут разные.
По памяти v8 для каждой функции хранит 2 js объекта (OrderedHashMap) для замыкания и для самой функции как объекта, GC smart pointer (пол машинного слова и остается валидным после memory move через механизмы GC) на AST ноду, статистику использования (при создании функции пустая коллекция) и машинный код (при создании нет, первая компиляция происходит после 2-3 запуска через интерпретатор и сбора статистики). Так вот, размер статистики и машинного кода напрямую корелирует с размером AST поддерева для функции. То есть для оптимизации по памяти лучше чтоб в цикле создавались простые функции, а сложная была в единственном экземпляре.
По производительности думаю и так понятно, повторяющиеся действия лучше вынести как за цикл так и за функцию. Особенно это критично с регулярками, которые компилируются отдельным движком не очень то дружащим с оптимизациями turbofan.

Это все теория, на практике все сильно зависит от того, что скрыто под { ... } и сложнее ли оно, чем внутренности bind, с которым вообще не просто это посчитать, так как в последних версиях v8 все встроенные функции переписаны с js на torque (свой яп v8, помесь js и плюсов и компилируемый в плюсы).

Вообщем, я бы предложил такой вариант для сложных функций:

const f = (e, a, b) => { ... };
// loop
  .addEventListener('click', e => f(e, 1, 2));

Так наплодим функций из единственного call expression, а все остальное вынесем в единственную f.
А если f и сама состоит из единственного выражения, то вообще ничего не выносить и плодить ее в цикле.
Но лучшим вариантом конечно останется, когда внешняя f как есть передается в addEventListener, а данные она получит через объект Event

[WbICHA]

Дмитрий Беляев, спасибо большое, было познавательно, обязательно учту.

[Николай Ланец]

Дмитрий Беляев, я понял природу своей привязанности к map(). Потому что я плотно сижу на реакте. Там мне очень часто приходится работать с массивами и выводить результаты на основе их данных. Соответственно, чаще всего для этого используется .map() или .reduce(). Попробовал .forEach() и получил ожидаемый результат - ничего не вывелось. Потому что .forEach() не возвращает никакого результата, даже если внутри цикла писать return. Получается, что даже если данные исходного массива не надо редактировать (и типа использовать forEach), приходится заводить новую переменную и в нее набивать данные внутри цикла. Не думаю, что тут какой-то великий прирост в производительности будет. А если еще и писать в тайпскрипте, то новую переменную надо объявлять с заданием типа (в то время, как при использовании .map() тип нового массива формируется автоматически.).
Так что такая программерская граммар-наци - жуткое натягивание совы на глобус и дичайший оверхед ИМХО.