К
И мае нифига не гарантирует что данные будет консистентны
Size: a a a
2021 May 16
AF
С одной стороны тут есть вызов делегата, с другой стороны тут нет вызова .push и дополнительного обращения в .dataset (то есть, в дом лезть не надо)
К
Не решается, так как объект с таким датасетом не обязательно лайк, его все равно надо искать.
AF
Таким образом, неопытный разработчик, используя подобные методы, на самом деле напишет более эффективный код. Его можно было бы написать ещё эффективнее без них, но 1) требует знаний, которых у этого разработчика нет 2) в принципе не нужно, потому что это не является бутылочным горлышком
К
А теперь давай все мне в 1 массив разверни
К
Без for
AF
Бутылочное горлышко тут сходить что-то найти в DOM, это такая же разница, как между поиском чего-то у себя на столе и поиском в ашане на другом конце города
К
:) @Prontiol где тот тест про dom?
К
Где сравнивали селекторы
AF
Так DOM и надо оптимизировать так, чтобы его можно было прочитать как можно быстрее. А это делается выбором возможного представления данных в HTML
К
Для начала мы даже таску не знаем.
Я предположил что у него дерево непостоянное, и между 2 мя перебирающими методами возможен диф
Я предположил что у него дерево непостоянное, и между 2 мя перебирающими методами возможен диф
К
Они одинаковые, просто дерево меняется снаружи.
К
Тогда твой "раз посчитал" будет каждый раз
AF
а я предложил получать дерево снаружи, а в функции просто обрабатывать полученное дерево, абстрагируясь от того, что это за дерево такое
AF
в худшем случае вызывать получение дерева непосредственно перед вызовом функции, лучше — с какими-то оптимизациями, кэшированием дерева, если оно не изменилось
AF
Ещё лучше — любым способом элиминировать из кода .querySelector и .querySelectorAll, потому что именно они и будут тормозить, а не .map
G
Усложнили задачу но щас все будет сделано =)
К
Код хукать нельзя
К
А то я на его обфускатор натравлю
К
И вообще на WASM напишу