Comments 7
const filterReducer (predicate) => (result, input) => {
return predicate(input) ? result.concat(input) : result;
};
Пропущено "=" после filterReducer.
И игру слов потеряли (там, где «хаха»).
Если производительность критична — проще использовать обычный процедурный подход. В противном случае привычную функциональщину filter/map/etc.
Безотносительно трансдьюсеров, мне очень сильно по глазам бьёт когда я вижу, что-то вроде:
const mapReducer = (mapper) => (result, input) => {
return result.concat(mapper(input));
};
Нужно понимать, что .concat
создаёт новый array. Каждый раз. Т.е. вообще всегда. И чем больше array.length
, тем дольше эта операция длится. У нас не haskell
. Такие операции ооочень дорогие. Наверняка это учтено в rambda и там используется мутабельный подход (не уверен, не проверял). Но в ваших примерах как раз идеалистический иммутабельный подход.
Дык какой смысл рассуждать о преимуществах таких вот трандьюсеров на коленках, если на реальных больших массивах, они будут в сотни тысяч раз медленнее императивного for-of
цикла? У вас же аллокационный ад по перекладыванию всего массива в каждом звене-reducer-е. Зачем тогда рассуждать о какой-то производительности при этом, если вы своими же руками её просто уничтожили?
P.S. лечится это тем, что reducer просто использует .push
вместо .concat
и возвращает тот же массив, что и получил.
P.S.S. ничего против редьюсеров и трансдьюсеров не имею, просто нельзя их так идеалистично готовить, они при этом теряют всякий смысл и превращаются в пародию.
Эффективное преобразование данных с использованием трансдьюсеров