Комментарии 16
console.log(normalizeNames(names)); // ['alice', 'bob']
А как тут bob то появился ?
console.log(normalizeNames(names)); // ['alice', 'bob']
А как тут bob то появился ?
Мало того, что результат normalizeNames некорректный, но и сама функция ужасна.
Она не пройдёт ни одно ревью в более или менее нормальной компании. Какая сложность этого алгоритма? Считаю этот пример вообще очень плохой.
Согласен. Циклы for отменили? Начинает так казаться. Зачем постоянно чэйнить несколько map/filter, когда можно сделать всё за один проход? Плохие примеры какие-то
Я сейчас отхвачу минусов из обоих лагерей, но, по-моему, ванильный экма и лодаш лучше всего, и for'ов, и этой Рямды.
С циклами понятно. То же самое, что предложить циклы вместо SQL'я. Я хочу видеть декларативную схему преобразования, а не набор инструкций для ЦП. На больших наборах данных это, возможно, начнёт тормозить, но а зачем вы тащите большие наборы данных в экму? Я на ней пишу вещи типа UI, и если по коллекции из 30 элементов придётся пробежать три раза, а не один, то сильно не расстроюсь. А вот если будет нечитаемая куча for'ов, это меня расстроит.
А зачем эта Рямда, я просто не понимаю. Функции делали гражданами первого класса, чтобы их не замечать, чтобы декларативность стала возможной, а не для того, чтобы функция функцией погоняла из функции. Какая-то максимально нечитаемая запись.
Сложность - O(n).
Есть идеи, как сделать лучше?
import * as R from 'ramda';
const add = R.add(10); // Создаём функцию, которая прибавляет 10
console.log(add(5)); // 15Круто, тащим всю библиотеку ради одной функции.
В целом статья из разряда "как сложить числа с помощью jquery", когда джуны тянут в код что то не потому что надо, а потому что могут.
Давно уже пора отказаться от подобных библиотек, стандартное апи очень даже неплохое, и только в редких случаях, например когда нужен map объекта или глубокое сравнение, можно что то подтянуть (и то имеет смысл просто копирнуть пару таких функций в свой проект).
Не сказал бы что API прям хорошее, большого числа мелочей не хватает, по крайней мере мне и, получается, моим коллегам. В начале проекта 5-10 простых функций (noop, arity, partial, identity или id, и т.д.), скоро уже 20. Потом появляется compose или flow, На всё это нужны тесты. Следишь за непротиворечивостью композиций этого всего.
А можно сразу библиотеку затянуть и использовать Tree Shaking. За ramda не скажу, но с lodash так делал.
Круто, тащим всю библиотеку ради одной функции.
Если вы про скомпилированный код, то вы не правы. Запись как в примере кода задействует tree shaking, то есть в скомпилированный код пойдёт только функция add.
Если вы про подключение библиотеки к исходному коду ради одной функции, то вы утрируете. Этот пример — простейшая иллюстрация принципа, заложенного в основу библиотеки. Никто не призывает подключать целую библиотеку ради сложения чисел.
Во второй задаче код значительно потерял в компактности и читаемости, а это как бы суть библиотеки...
Как по мне то ванильный жс выглядит более читабельным
Для группировки чем Object.groupBy() не угодил?
У рамды кривые типы. Если уж и тащить, то remeda, которая изначально на тс-е
Читаемость хуже, теперь надо больше усилий чтобы прочитать и понять, что там происходит.
Кода меньше не стало
Лучше использовать ramBda. Причины:
TS типы включены в пакет, не нужно подгружать отдельные
@types/ramdaЛучше производительность у большинства операторов (в том числе и по сравнению с
lodash)Исходники проще прочитать (субъективно, но лично для меня так)
Меньше весит: ±18KB у ramda против ±5KB у ramBda (это minified + gzipped, проверил на bundlephobia)
Ramda.js — библиотека, которая избавит вас от reduce и map-каши