Сразу лайк за развёрнутый и конструктивный ответ> forEach / map / flatMap в Scala используется и в хвост и в гриву, и на
> производительность никто не жаловался.
Не путайте функциональные языки с JS =) К API претензий нет, но есть разница, что под капотом. В ФП-языках оптимизация хвостовой рекурсии гарантируется, в то время как в императивных не всегда допустима
> Во-вторых, это заблуждение. На современных движках эти forEach / map / flatMap
> по производительности отстают от for of в 2 раза, грубо говоря.
> Это вообще ничто учитывая производительность, если не ворочать миллионами объектов.
Когда элементов мало -- разницы действительно нет
> Трансформация данных гораздо удобнее и понятнее, есть явный separation concern чем лапша
> в цикле.
Вопросов нет. Действительно, когда элементов мало, а их преобразование/обработка сложны и многоэтапны -- forEach/map/etc не просто незаменимы, они best practice
Хозяйке на заметку. Методы map/filter есть только у массивов, но отсутствуют в Set и итераторах. Это зашквар. Для сравнения, в python можно скормить map/filter любой итерируемый объект, получив на выходе генератор. В JS мы умеем только в массивы
> Все доп. библиотеки обработки данных типа rambda заточены под ФП и переиспользование
> кода офигенно.
Я не знаком с rambda, поэтому поверю вам на слово
> Также накладывает ограничения React, который во-первых пересоздаёт замыкания и отбрасывает
> их на каждом рендере
Следовательно, чтобы не пересоздавать замыкания, коллбэки надо выносить из render()
> А во-вторых использовать его с кастомными типами практически невозможно
Не увидел ни единого препятствия. Что я только ни пихал ни в props, ни в redux state. Держи себе в голове ссылочную прозрачность -- и всё.
> И React это "чистый" ФП... функции... функции функций и т.д.
React.PureComponent? Возвращайтесь из мира розовых единорогов :)
> Да, я лучше список пробегу фильтруя, чем буду тр...ся с Set. По-сути
> нужно создавать новый Set из старого.
"Нас устраивало O(N^2), пока N не начал расти" (с) Хабр
Всегда держим в уме cardinality. На малых объёмах массивы могут оказаться незначительно быстрее Set. А чтобы получить линейную алгоритмическую сложность, стоит применить Set
> Можно, конечно извратиться используя useRef ссылки, но оно того в 99.99% не
> стоит.
Я не про рефы. Рефы вообще о другом. Кстати, особенно в случае class based компонентов рефы действительно рулят. Особенно когда мы генерим хитрую структуру из того, что накликал/навводит пользователь. Чем гнать тонну данных вверх/вниз, есть смысл на каждом уровне определить метод генерации части этой структуры. Вообще говоря, я пересказываю суть HMVC
> Те это не моё нежелание, а невозможность / ограничение фреймворка (думаю у
> других не лучше).
"Не верю!" (с) Станиславский.
> И вообще если вы работаете с миллионными списками вы что-то делаете очень
> неправильно. А со списком в 100 элементов из БД...его хоть как
> медленно обрабатывай это миллисекунды.
На самом деле при использовании for ... of разница между 100 элементами и 5000 оказалась не столь существенной. Бэк насиловал БД намного дольше, но fulltext в MySQL -- это пока грустная история
> Наверняка в Node.js другая ситуация, но там гораздо больше ООП, сам API
> этому способствует.
Пфф, на бэке есть альтернативы. На фронте пока нет
