Сменить шифрование

Как душе угодно будет.
Билдер имеет смысл, если у тебя разные сценарии билда, если один то лучше одним методом.

поиграюсь с этим, спасибо

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

Можно пример?

Странное заявление

Очен правильное заявление

На самом деле согласен полностью.
По "локальной областью видимости" подразумевается физически кусок экрана, который охватывается взглядом без скролла

// там же где FormulaPayload и context
updateAds = (ads) => from(ads)
    .to(FormulaPayload)
    .filter(x => x.type === FormulaType.New)
    .map(x => ({
      payload: x.rowValue(),
      id: x.id
    }))
    .map(context.update)

vs

// где-то в корне
createSomeShit({
updateAds: updateAds({  update: ... })
})

// где-то чуть ниже
updateAds = updateAds({ fromFormulaPayload: ..., onlyNew: ...,  rowValues: ... })

// где-то очень глубоко
({ updateAds, doSomethingElse}) => {
updateAds(ads);
doSomethingElse();
}

// где-то рядом с вызовом
updateAds = ({ update }) => ({ fromFormulaPayload, onlyNew,  rowValues }) => (ads) => update(rowValues(onlyNew(fromFormulaPayload())));

типизацию я естественно опустил

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

но самое не приятное то, что если где-то что-то сломалось стектрейс выглядит как 1 вызов, а все остальное надо смотреть в вложенных скоупах контекст которых скорее всего не существует на момент вызова

а сделав каррирование на месте вроде: .filter(byType(FormulaType.New)), это ок, вообще без потерь

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

toPayload = ads => ads.map(x => ({
      payload: x.rowValue(),
      id: x.id
    }))

то это x10 к сложности кода, а если

toPayload = x => ({
      payload: x.rowValue(),
      id: x.id
    })

то это иногда будет ок, но это никогда не будет лучше чем ({toPayload, x }) => toPayload(x) потому что в случае выноса функции она будет передана через контекст родителя, а не вместе с контекстом x

Зачем использовать ФП, если больно?
Мыши плакали, кололись, но продолжали грызть кактус?
Сначала надо мозг от-тьюнинговать, а потом уже ФП-код писать

ну я потюнил, в итоге код различается только тем в какой момент я добавляю поведение к данным, на классах этот момент - во время определения класса, а с магическим ФП в момент вызова кода

и все

// там же где FormulaPayload и context
updateAds = (ads) => from(ads)
    .to(FormulaPayload)
    .filter(x => x.type === FormulaType.New)
    .map(x => ({
      payload: x.rowValue(),
      id: x.id
    }))
    .map(context.update)

// где-то в корне
createSomeShit({
updateAds: updateAds({  update: ... })
})

// где-то чуть ниже
updateAds = updateAds({ fromFormulaPayload: ..., onlyNew: ...,  rowValues: ... })

// где-то очень глубоко
({ updateAds, doSomethingElse}) => {
updateAds(ads);
doSomethingElse();
}

// где-то рядом с вызовом
updateAds = ({ update }) => ({ fromFormulaPayload, onlyNew,  rowValues }) => (ads) => update(rowValues(onlyNew(fromFormulaPayload())));

а что это за язык?

ну и данные не изменяемые, что и на классах не новость