D
Просто я сейчас только познаю жс и все эти методы пишу так сказать «в ручную» и пока что вижу только как удобство
Удобство, и оно по сравнению с голым for/if огромное
Size: a a a
2021 February 04
D
От копирования массива до чейнинга
AS
имхо, лучше ичем пройтись, зачем два объекта создавать и память забирать, да и forEach у NodeList оптимизирован под прохождения по дереву
затем что может потребоваться исходный массив
R
фильтр можно чейнить, он возвращает новый массив с заданными параметрами
Я понял, спасибо за объяснение
IN
затем что может потребоваться исходный массив
конкретно в данном случае нет такой задачи :/
D
имхо, лучше ичем пройтись, зачем два объекта создавать и память забирать, да и forEach у NodeList оптимизирован под прохождения по дереву
Память при отсутствии ссылок подчищается, а удобства - неоспоримы
D
Не мутировать вещи - вообще неплохая идея в целом
D
Ну это уже не говоря о том, что дать функции массив и получить вместо нового массива мутацию старого - это очень нездоровый DX
D
Который приводит лишь к проблемам
IN
Ну это уже не говоря о том, что дать функции массив и получить вместо нового массива мутацию старого - это очень нездоровый DX
зачем если тебе не надо получать этот массив?
D
Ну не возвращай. Но мутировать то что тебе дали - ОЧЕНЬ плохая идея
D
Это не тестируется, не отслеживается, приводит к неотлавливаемым багам
AS
зачем если тебе не надо получать этот массив?
вот тебе пример: мне нужно исходя из выбранных чекбоксов фильтровать список. если изменять исходный массив, то при снятии всех галок у тебя останется измененный
D
Если это какая-то OOP-система ещё куда ни шло, через методы работать с даными тебе инстансами
v
Опять же, если мы в цикле for при фильтрации - пушим в новый массив - то тоже самое выходит идеологически. А если фильтруем исходный (всееще про for), то опятьже нужно держать в голове сдвиг элементов, как и то, что это очень затратная операция O(n**2) (если не сложнее) если слева направо против O(1) у фильтра. Одна головная боль в общем
AS
va1
Опять же, если мы в цикле for при фильтрации - пушим в новый массив - то тоже самое выходит идеологически. А если фильтруем исходный (всееще про for), то опятьже нужно держать в голове сдвиг элементов, как и то, что это очень затратная операция O(n**2) (если не сложнее) если слева направо против O(1) у фильтра. Одна головная боль в общем
т.е. по-твоему встроенная оптимизированная функция будет затратнее перебора через for, проверкой на условие и прокидыванием в массив?
IN
Если это какая-то OOP-система ещё куда ни шло, через методы работать с даными тебе инстансами
не понимаю вообще причем здесь все ваши "аргументы". Ты в обеих случаях дом дерево мутируешь. Только твой вариант по производительности хуже
v
т.е. по-твоему встроенная оптимизированная функция будет затратнее перебора через for, проверкой на условие и прокидыванием в массив?
я не это сказал тащемта
AS
va1
я не это сказал тащемта
комментарий был изменен)
IN
все потому что forEach у NodeList оптимизирован для работы с дом деревом и это одно действие. А ты делаешь следующее - раскладыаешь NodeList на массив из Node и используешь итератор для массива