Ответ на пост «Современное програмирование»⁠⁠3

Лицензия замечательная и в тему событий! Случайно не расшифровывается как "What The Fuck? Public License"?

Была ещё библиотека is-promise, которая состояла всего из двух строк (!) кода js. И вот эту библиотеку использовали более чем в 2.5 миллионах (!!!) проектов. Новая версия оказалась несовместима со стандартами ES-модуля. Пострадали такие известные фреймворки и библиотеки как React, Angular, Nuxt и другие

https://habr.com/ru/company/itsumma/news/t/499218/

А с тайпскриптом - справляется и с каррингом и композицией.

т.е. тот же vscode корректно мне подскажет, что вот тут я поиспользовал карринг из хрен пойми какой библиотеки? или надо плагины подключать, чтобы при использовании lodash или ramba среда давала мне подсказки, что вот тут я сделал карринг и аргументы вот такие надо?

Кодстайл на фронтенде - никаких классов. Даже в реакте компоненты-функции.

ну это и понятно, с современными mvvm фреймворками с их компонентами ООП не нужен почти никогда. некоторые функциональные подходы (те же map/filter/reduce, иммутабельность, стремление к "чистоте") мы у себя практикуем испокон веков, но ничего более серьезного.. а что вы из более серьезного ФП используете в реакте на фронте, и чем оно реально помогает?

Лишние функции обертки это антипаттерн. Это много раз повторяется в книге, что я советовал.

книга занятная, начал читать, наткнулся на недопонимание или косяк автора, он пишет в главе 3, что

const decrementHP = p => p.set('hp', p.get('hp') - 1);

это чистая функция.. но тут же у нас мутация передаваемого в аргументе объекта, какая ж это чистая функция???

моветон? спорное заявление.

явное лучше неявного. задавая аргументы явно, вы даете статическому анализатору / компилятору информацию, как используется метод, среда разработки дает разработчикам подсказки, как использовать метод..

используя карринг там, где он не нужен, вы вычеркиваете все перечисленное..

ооп в js боль только для тех, кто не умеет в ооп. сейчас в js и конструкторы, и наследование, скоро приватные поля приедут. нужны более сложные вещи - typescript.

Функциональный подход для меня выглядит красивее. Почти всегда короче и понятнее, если привыкнуть

самое важное тут - "для вас" и "если привыкнуть".. небольшие проекты и команды - ок.. но я говорю про энтерпрайз код, сейчас код разрабатываете вы, а через неделю будет дорабатывать вася-джуниор.. разбираться в хорошо структурированном явном коде легче, чем в композициях и каррингах, особенно когда еще и среда разработки не может подсказать (см. предыдущий абзац).

Чистые функции легче тестировать.

это бесспорно, и никто не запрещает писать чистые функции так, как я приводил примеры выше, только без магии карринга и композиций.

p.s.: вмеcто array.map скорее всего вы хотели array.forEach

1. Вариант с логированием. Тут карринг не нужен как таковой. На чистом js выглядит даже проще:

const log = (f, c, level, data) => { ... };

const warn = (data) => log(fetch, config, 'warn', data);

А с использованием ООП так еще более опрятно и гибко:

class Logger {

  constructor(fetch, config) {  ...  }

  log(level, data) {  ...  }

  warn(data) {

    this.log('warn', data);

  }

}

2. Функция добавления конкретного класса - чистая фикция, как сказал бы Мартин Фаулер. Не плодите сущности, иначе словите себя на том, что у вас 100500 функций и 99% используется всего 1 раз.

3. Композиция функций для валидации телефона это пиздец какой-то. Понятно, что вы в своей команде вовсю используете трюки ФП и для вас это привычно. Но для меня (как обычного разработчика с 15 лет стажа)))) это выглядит непонятным и неочевидным. В простом императивном подходе куда очевидней:

const phoneValidator = (value) => { ... };
const eventHandler = (target, klass, validator) => {
  if (validator(target.value)) {
    validator.classList.remove(klass);
  } else {

    validator.classList.add(klass);

  }
}
phoneInput.addEventListener('keyup', (e) => eventHandler(e.target, 'GB', phoneValidator));

хотя, если честно, в обоих случаях говнище)))

Ну и другой момент, манипуляции dom'ом и свое связывание модели / представления в наше время выглядит уже странно: react, vue, angular наше все.

P.S.: по ФП почитаю, спасибо ))

в дополнение к своему комменту, я тут понял, что композиция функций в последнем примере для валидации поля ввода дает ложное ощущение "универсализма", потому что по факту:

1. для поле ввода input / textarea / select (не multiple)  текущим элементом (getTarget) всегда будет event.target, а значением поля (getValue) всегда будет target.value

2. для select multiple  getValue будет отличаться, да.. но спросите себя, используете ли вы этот атавизм 00-х?

3. для radio / checkbox весь этот код не будет работать, т.к. надо пробегаться по всему множеству значений.. да и к тому же нет смысла менять class на чекбоксах )))

в итоге реально рабочим получается вариант 1.

не обязательно прямо большой кусок, можно только важную часть или набросок, где было бы понятно, зачем вы используете карринг в вебе. можно комментом или на pastebin, если не затруднит ;-)

где в проекте вы это используете? вот прямо кусок кода скопируйте )))

а средства языка разве сложнее?

function f(a, b) {}

c = (b) => f(a, b);

тут вы хотя бы в явном виде задаете сигнатуру, а не используете магию под капотом. к тому же, что это за проект, где вы часто используете карринг? вот серьезно?

Как всегда когда не-программисты пишут о программировании получается говно и легенды.

Никакая половина веб-приложений никуда не попадала. Все установленные приложения работали в штатном режиме. Заблокировалось только разворачивание НОВЫХ приложений что и решили за пару дней.

yarn add же ))

приведите пример из жизни, где вам понадобился lodash? лет 10 назад, когда в js не было поддержки filter/map/reduce либы типа underscore / lodash были полезными, но сейчас?