Как функци-анальщик (велик и могуч русский язык) не соглашусь.Во-первых, я перешёл с функциональной Scala и JavaScript больше ФП, чем ООП в современном виде. forEach / map / flatMap в Scala используется и в хвост и в гриву, и на производительность никто не жаловался.
Во-вторых, это заблуждение. На современных движках эти forEach / map / flatMap по производительности отстают от for of в 2 раза, грубо говоря. Это вообще ничто учитывая производительность, если не ворочать миллионами объектов.
Трансформация данных гораздо удобнее и понятнее, есть явный separation concern чем лапша в цикле.
Конечно можно и одним проходом делать с reduce и аккумулятором с ранним выходом (упс, нельзя).
И только если нужна максимальная производительность имеет смысл использовать обычные циклы.
Все доп. библиотеки обработки данных типа rambda заточены под ФП и переиспользование кода офигенно.
Также накладывает ограничения React, который во-первых пересоздаёт замыкания и отбрасывает их на каждом рендере. А во-вторых использовать его с кастомными типами практически невозможно.
И React это "чистый" ФП... функции... функции функций и т.д.
Да, я лучше список пробегу фильтруя, чем буду тр...ся с Set. По-сути нужно создавать новый Set из старого.
Можно, конечно извратиться используя useRef ссылки, но оно того в 99.99% не стоит.
Те это не моё нежелание, а невозможность / ограничение фреймворка (думаю у других не лучше).
И вообще если вы работаете с миллионными списками вы что-то делаете очень неправильно. А со списком в 100 элементов из БД...его хоть как медленно обрабатывай это миллисекунды.
Наверняка в Node.js другая ситуация, но там гораздо больше ООП, сам API этому способствует.
