Comments 9
Потрясающая либа, использую её и кайфую. Но мои собратья по клавиатуре в свое большинстве не понимают её, хотя и Lodash и underscore редко пользуются.
Может и потрясающая, но я считаю что такого надо всячески избегать, если не доказана обоснованность применения. Серьезный рост производительности, например. Этот Rambda тестился в этом плане?
Код должен быть прост, никому не охота разбирать очередные шарады и %randomname% библиотеки.
Да и в случае с lodash, я не вижу что
И тащить лишние 70кб дополнительной библиотеки для этого совершенно не за чем. Тут надо каждый раз смотреть, нужно оно реально или нет.
Код должен быть прост, никому не охота разбирать очередные шарады и %randomname% библиотеки.
Да и в случае с lodash, я не вижу что
const incompleteTasks = tasks.filter(task => !task.complete);const incompleteTasks = _.filter(tasks, {complete: false});И тащить лишние 70кб дополнительной библиотеки для этого совершенно не за чем. Тут надо каждый раз смотреть, нужно оно реально или нет.
Отличная библиотека, линзы сильно упрощают работу с большими формами в приложении.
Интересно узнать от автора его опыт по дебагингу и поддержки таких приложений.
Еще насколько я понимаю растет стэк вызовов, как это влияет на производительность.
Еще насколько я понимаю растет стэк вызовов, как это влияет на производительность.
С ramda я познакомился пол года назад и по началу было тяжело писать в стиле ФП. Но со временем стало намного проще.
Особых сложностей при дебаге я не испытывал. Достаточно писать маленькие функции и не передавать большое количество функций в compose, pipe, тогда и отлаживать будет проще.
Есть еще такой инструмент для дебага рамды (https://github.com/sebinsua/ramda-debug), но я им правда ни разу не пользовался :))
Да стэк вызовов растёт если большая композиция, но особо сильно это не волновало. Вопрос производительности не вставал, блага все скрипты написанные с использованием ramda этого пока не требуют :) (если что, пишу я под nodejs)
Про поддержку, опять же если не злоупотреблять сложными конструкциями, а писать маленькие функции с осмысленным названием, то читать и поддерживать такой код намного проще.
Особых сложностей при дебаге я не испытывал. Достаточно писать маленькие функции и не передавать большое количество функций в compose, pipe, тогда и отлаживать будет проще.
Есть еще такой инструмент для дебага рамды (https://github.com/sebinsua/ramda-debug), но я им правда ни разу не пользовался :))
Да стэк вызовов растёт если большая композиция, но особо сильно это не волновало. Вопрос производительности не вставал, блага все скрипты написанные с использованием ramda этого пока не требуют :) (если что, пишу я под nodejs)
Про поддержку, опять же если не злоупотреблять сложными конструкциями, а писать маленькие функции с осмысленным названием, то читать и поддерживать такой код намного проще.
UFO just landed and posted this here
Важная особенность рамды то, что она не мутирующая. Простой пример, array.sort() изменит массив. R.sort(comparator, array) создаст копию исходного массива и отсортирует его. Метод R.set так же создает копию объекта и изменяет значение по ключу. Плюсы и минусы понятны. Постоянное клонирование сказывается на производительности, но если вы видите вызов рамды, можете быть уверены, что исходные данные не будут испорчены побочным эффектом от мутирования.
Why иногда точнее переводить «для чего».
Sign up to leave a comment.
Почему Ramda?