[Перевод] Борьба с грязными побочными эффектами в чистом функциональном JavaScript-коде07.09.2018 14:34

Если вы пробуете свои силы в функциональном программировании, то это значит, что вы довольно скоро столкнётесь с концепцией чистых функций. Продолжая занятия, вы обнаружите, что программисты, предпочитающие функциональный стиль, похоже, прямо-таки одержимы этими функциями. Они говорят о том, что чистые функции позволяют рассуждать о коде. Они говорят, что чистые функции — это сущности, которые вряд ли будут работать настолько непредсказуемо, что приведут к термоядерной войне. Ещё вы можете узнать от таких программистов, что чистые функции обеспечивают ссылочную прозрачность. И так — до бесконечности.

Кстати, функциональные программисты правы. Чистые функции — это хорошо. Но есть одна проблема…

q_uclcvzexyauvwqhrp4c84pwpi.jpeg


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

Проблема чистых функций


Чистая функция — это функция, не имеющая побочных эффектов (на самом деле, это — не полное определение чистой функции, но мы к такому определению ещё вернёмся). Однако если вы хоть что-то понимаете в программировании, то вы знаете, что самое важное здесь как раз таки и заключается в побочных эффектах. Зачем вычислять число Пи до сотого знака после запятой, если никто это число не сможет прочесть? Для того чтобы вывести что-то на экран или распечатать на принтере, или представить в каком-то другом виде, доступном для восприятия, нам нужно вызвать из программы подходящую команду. А какая польза от баз данных, если в них ничего нельзя записывать? Для обеспечения работы приложений нужно считывать данные из устройств ввода и запрашивать информацию из сетевых ресурсов. Всё это нельзя сделать без побочных эффектов. Но, несмотря на такое положение дел, функциональное программирование построено вокруг чистых функций. Как же программистам, которые пишут программы в функциональном стиле, удаётся решить этот парадокс?

Если ответить на этот вопрос в двух словах, то функциональные программисты делают то же, что и математики: они жульничают. Хотя, несмотря на это обвинение, надо сказать, что они, с технической точки зрения, просто следуют определённым правилам. Но они находят в этих правилах лазейки и расширяют их до невероятных размеров. Делают они это двумя основными способами:

  1. Они пользуются внедрением зависимостей (dependency injection). Я называю это перебрасыванием проблемы через забор.
  2. Они применяют функторы (functor), что мне кажется крайней формой прокрастинации. Тут надо отметить, что в Haskell это называется «IO functor» или «IO monad», в PureScript используется термин «Effect», который, как мне кажется, немного лучше подходит для описания сущности функторов.


Внедрение зависимостей


Внедрение зависимостей — это первый метод работы с побочными эффектами. Используя этот подход, мы берём всё, что загрязняет код, и выносим это в параметры функции. Затем мы можем рассматривать всё это как нечто, входящее в сферу ответственности какой-то другой функции. Поясню это на следующем примере: 

// logSomething :: String -> String
function logSomething(something) {
    const dt = (new Date())toISOString();
    console.log(`${dt}: ${something}`);
    return something;
}


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

У функции logSomething() есть две проблемы, не позволяющие признать её чистой: она создаёт объект Date и что-то выводит в консоль. То есть, наша функция не только выполняет операции ввода-вывода, она ещё и выдаёт, при её вызове в разное время, разные результаты.

Как сделать эту функцию чистой? С помощью техники внедрения зависимостей мы можем взять всё, что загрязняет функцию и сделать это параметрами функции. В результате, вместо того, чтобы принимать один параметр, наша функция будет принимать три параметра: 

// logSomething: Date -> Console -> String -> *
function logSomething(d, cnsl, something) {
    const dt = d.toIsoString();
    return cnsl.log(`${dt}: ${something}`);
}


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

const something = "Curiouser and curiouser!"
const d = new Date();
logSomething(d, console, something);
//  "Curiouser and curiouser!"


Тут вы можете подумать, что всё это — глупость, что мы лишь переместили проблему на один уровень вверх, а это не добавило чистоты нашему коду. И знаете, это — правильные мысли. Это — лазейка в чистом виде.

Это похоже на притворную безграмотность: «Я и не знал, что вызов метода log объекта cnsl приведёт к выполнению оператора ввода-вывода. Мне просто это кто-то передал, а я знать не знаю, откуда всё это взялось». Такое отношение к делу — это неправильно.

И, на самом деле, происходящее — это не такая уж, как может показаться на первый взгляд, глупость. Приглядитесь к особенностям функции logSomething(). Если вы хотите сделать нечто нечистым, то вы должны сделать это самостоятельно. Скажем, этой функции можно передавать различные параметры: 

const d = {toISOString: () => '1865-11-26T16:00:00.000Z'};
const cnsl = {
    log: () => {
        // не делать ничего
    },
};
logSomething(d, cnsl, "Off with their heads!");
//   "Off with their heads!"


Теперь наша функция не делает ничего (она лишь возвращает параметр something). Но она — совершенно чистая. Если вы вызовете её с этими же параметрами несколько раз, она всякий раз будет возвращать одно и то же. И всё дело именно в этом. Для того чтобы сделать эту функцию нечистой, нам нужно преднамеренно выполнить определённые действия. Или, если сказать иначе, всё, от чего зависит функция, находится в её сигнатуре. Она не обращается ни к каким глобальным объектам вроде console или Date. Это всё формализует.

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

// getUserNameFromDOM :: () -> String
function getUserNameFromDOM() {
    return document.querySelector('#username').value;
}

const username = getUserNameFromDOM();
username;
//   "mhatter"


В данном случае мы пытаемся загрузить какую-то информацию из DOM. Чистые функции так не поступают, так как document — это глобальный объект, который может в любой момент измениться. Один из способов сделать подобную функцию чистой заключается в передаче ей глобального объекта document в качестве параметра. Однако ей ещё можно передать функцию querySelector(). Выглядит это так: 

// getUserNameFromDOM :: (String -> Element) -> String
function getUserNameFromDOM($) {
    return $('#username').value;
}

// qs :: String -> Element
const qs = document.querySelector.bind(document);

const username = getUserNameFromDOM(qs);
username;
//   "mhatter"


Тут, снова, вам может прийти мысль о том, что это глупо. Ведь тут мы просто убрали из функции getUsernameFromDOM() то, что не позволяет называть её чистой. Однако от этого мы не избавились, лишь перенеся обращение к DOM в другую функцию, qs(). Может показаться, что единственным заметным результатом подобного шага стало то, что новый код оказался длиннее старого. Вместо одной нечистой функции у нас теперь две функции, одна из которых всё ещё является нечистой.

Подождите немного. Представьте, что нам надо написать тест для функции getUserNameFromDOM(). Теперь, сравнивая два варианта этой функции, подумайте о том, с каким из них будет легче работать? Для того чтобы нечистая версия функции вообще заработала, нам нужен глобальный объект документа. Более того, в этом документе должен быть элемент с идентификатором username. Если понадобится протестировать подобную функцию за пределами браузера, тогда нужно будет воспользоваться чем-то вроде JSDOM или браузером без пользовательского интерфейса. Обратите внимание на то, что всё это нужно лишь для того, чтобы протестировать маленькую функцию длиной в несколько строк. А для того, чтобы протестировать второй, чистый, вариант этой функции, достаточно сделать следующее: 

const qsStub = () => ({value: 'mhatter'});
const username = getUserNameFromDOM(qsStub);
assert.strictEqual('mhatter', username, `Expected username to be ${username}`);


Это, конечно, не значит, что для испытания подобных функций не нужны интеграционные тесты, выполняемые в реальном браузере (или, как минимум, с использованием чего-то вроде JSDOM). Но этот пример демонстрирует очень важную вещь, которая заключается в том, что теперь функция getUserNameFromDOM() стала полностью предсказуемой. Если мы передадим ей функцию qsStub(), она всегда возвратит mhatter. «Непредсказуемость» мы переместили в маленькую функцию qs().

Если надо, мы можем выносить непредсказуемые механизмы на уровни, ещё более отдалённые от основной функции. В итоге мы можем вынести их, условно говоря, в «пограничные области» кода. Это приведёт к тому, что у нас будет тонкая оболочка из нечистого кода, которая окружает хорошо протестированное и предсказуемое ядро. Предсказуемость кода оказывается крайне ценным его свойством тогда, когда размеры проектов, создаваемых программистами, растут.

▍Недостатки механизма внедрения зависимостей


Используя внедрение зависимостей можно написать большое и сложное приложение. Я это знаю, так как сам написал такое приложение. При таком подходе упрощается тестирование, становятся чётко видны зависимости функций. Но внедрение зависимостей не лишено недостатков. Главный из них заключается в том, что при его применении могут получаться очень длинные сигнатуры функций: 

function app(doc, con, ftch, store, config, ga, d, random) {
    // Тут находится код приложения
 }

app(document, console, fetch, store, config, ga, (new Date()), Math.random);


На самом деле, это не так уж и плохо. Минусы таких конструкций проявляются в том случае, если некоторые из параметров нужно передавать неким функциям, которые очень глубоко вложены в другие функции. Выглядит это как необходимость передавать параметры через много уровней вызовов функций. Когда число таких уровней растёт, это начинает раздражать. Например, может возникнуть необходимость в передаче объекта, представляющего дату, через 5 промежуточных функций, при том, что ни одна из промежуточных функций этим объектом не пользуется. Хотя, конечно, нельзя сказать, что подобная ситуация — это нечто вроде вселенской катастрофы. К тому же, это даёт возможность чётко видеть зависимости функций. Правда, как бы там ни было, это всё равно не так уж и приятно. Поэтому рассмотрим следующий механизм.

▍Ленивые функции


Взглянем на вторую лазейку, которую используют приверженцы функционального программирования. Она заключается в следующей идее: побочный эффект — это не побочный эффект до тех пор, пока он не произойдёт на самом деле. Знаю, звучит это таинственно. Для того чтобы в этом разобраться, рассмотрим следующий пример: 

// fZero :: () -> Number
function fZero() {
    console.log('Launching nuclear missiles');
    // Тут будет код для запуска ядерных ракет
    return 0;
}


Пример это, пожалуй, дурацкий, я это знаю. Если нам понадобится число 0, то для того, чтобы оно у нас появилось, достаточно вписать его в нужном месте кода. А ещё я знаю, что вы не станете писать на JavaScript код для управления ядерным оружием. Но этот код нам нужен для того, чтобы проиллюстрировать рассматриваемую технологию.

Итак, перед нами пример нечистой функции. Она выводит данные в консоль и ещё является причиной ядерной войны. Однако вообразите, что нам нужен тот ноль, который эта функция возвращает. Представьте себе сценарий, в соответствии с которым нам надо что-то посчитать после запуска ракеты. Скажем, нам может понадобиться запустить таймер обратного отсчёта или что-то в этом роде. В данном случае совершенно естественным будет заранее подумать о выполнении вычислений. И мы должны позаботиться о том, чтобы ракета запустилась именно тогда, когда нужно. Нам не надо выполнять вычисления таким образом, чтобы они могли бы случайно привести к запуску этой ракеты. Поэтому подумаем над тем, что произойдёт, если мы обернём функцию fZero() в другую функцию, которая просто её возвращает. Скажем, это будет нечто вроде обёртки для обеспечения безопасности: 

// fZero :: () -> Number
function fZero() {
    console.log('Launching nuclear missiles');
    // Тут будет код для запуска ядерных ракет
    return 0;
}

// returnZeroFunc :: () -> (() -> Number)
function returnZeroFunc() {
    return fZero;
}


Можно, сколько угодно раз, вызывать функцию returnZeroFunc(). При этом, до тех пор, пока не осуществляется выполнение того, что она возвращает, мы (теоретически), в безопасности. В нашем случае это означает, что выполнение следующего кода не приведёт к началу ядерной войны: 

const zeroFunc1 = returnZeroFunc();
const zeroFunc2 = returnZeroFunc();
const zeroFunc3 = returnZeroFunc();
// Никаких ракет запущено не было.


Теперь немного строже, чем прежде, подойдём к определению термина «чистая функция». Это позволит нам более детально исследовать функцию returnZeroFunc(). Итак, функция является чистой при соблюдении следующих условий:

  • Отсутствие наблюдаемых побочных эффектов.
  • Ссылочная прозрачность. То есть, вызов такой функции с одними и теми же входными значениями всегда приводит к одним и тем же результатам.


Проанализируем функцию returnZeroFunc().

Есть ли у неё побочные эффекты? Мы только что выяснили, что вызов returnZeroFunc() не приводит к запуску ракет. Если не вызывать то, что возвращает эта функция, ничего не произойдёт. Поэтому мы можем заключить, что у этой функции нет побочных эффектов.

Является ли эта функция ссылочно прозрачной? То есть, всегда ли она возвращает одно и то же при передаче ей одних и тех же входных данных? Проверим это, воспользовавшись тем, что в вышеприведённом фрагменте кода мы вызывали эту функцию несколько раз: 

zeroFunc1 === zeroFunc2; // true
zeroFunc2 === zeroFunc3; // true


Выглядит всё это хорошо, но функция returnZeroFunc() пока не вполне чиста. Она ссылается на переменную, находящуюся за пределами её собственной области видимости. Для того чтобы эту проблему решить, перепишем функцию: 

// returnZeroFunc :: () -> (() -> Number)
function returnZeroFunc() {
    function fZero() {
        console.log('Launching nuclear missiles');
        // Тут будет код для запуска ядерных ракет

        return 0;
    }
    return fZero;
}


Теперь функцию можно признать чистой. Однако в данной ситуации правила JavaScript играют против нас. А именно, мы больше не можем использовать оператор === для проверки ссылочной прозрачности функции. Происходит это из-за того, что returnZeroFunc() всегда будет возвращать новую ссылку на функцию. Правда, ссылочную прозрачность можно проверить, изучив код самостоятельно. Такой анализ покажет, что при каждом вызове функции она возвращает ссылку на одну и ту же функцию.

Перед нами — маленькая аккуратная лазейка. Но можно ли использовать её в реальных проектах? Ответ на этот вопрос положителен. Однако прежде чем поговорить о том, как пользоваться этим на практике, немного разовьём нашу идею. А именно, вернёмся к опасной функции fZero(): 

// fZero :: () -> Number
function fZero() {
    console.log('Launching nuclear missiles');
    // Тут будет код для запуска ядерных ракет
    return 0;
}


Попытаемся воспользоваться тем нулём, который возвращает эта функция, но сделаем это так, чтобы (пока) ядерную войну не начинать. Для этого создадим функцию, которая берёт тот ноль, который возвращает функция fZero() и добавляет к нему единицу: 

// fIncrement :: (() -> Number) -> Number
function fIncrement(f) {
    return f() + 1;
}

fIncrement(fZero);
//   Запуск ядерных ракет
//   1


Вот незадача… Мы случайно начали ядерную войну. Попробуем снова, но в этот раз не будем возвращать число. Вместо этого вернём функцию, которая, когда-нибудь, возвратит число: 

// fIncrement :: (() -> Number) -> (() -> Number)
function fIncrement(f) {
    return () => f() + 1;
}

fIncrement(zero);
//   [Function]


Теперь можно вздохнуть спокойно. Катастрофа предотвращена. Продолжим исследования. Благодаря этим двум функциям мы можем создать целую кучу «возможных чисел»: 

const fOne   = fIncrement(zero);
const fTwo   = fIncrement(one);
const fThree = fIncrement(two);
// И так далее…


Кроме того, мы можем создать множество функций, имена которых будут начинаться с f (назовём их f*()-функции), предназначенных для работы с «возможными числами»: 

// fMultiply :: (() -> Number) -> (() -> Number) -> (() -> Number)
function fMultiply(a, b) {
    return () => a() * b();
}

// fPow :: (() -> Number) -> (() -> Number) -> (() -> Number)
function fPow(a, b) {
    return () => Math.pow(a(), b());
}

// fSqrt :: (() -> Number) -> (() -> Number)
function fSqrt(x) {
    return () => Math.sqrt(x());
}

const fFour = fPow(fTwo, fTwo);
const fEight = fMultiply(fFour, fTwo);
const fTwentySeven = fPow(fThree, fThree);
const fNine = fSqrt(fTwentySeven);
// Никакого вывода в консоль, никакой ядерной войны. Красота!


Видите, что мы тут сделали? С «возможными числами» можно делать то же самое, что и с обычными числами. Математики называют это изоморфизмом. Обычное число всегда можно превратить в «возможное число», поместив его в функцию. Получить «возможное число» можно, вызвав функцию. Другими словами, у нас имеется маппинг между обычными числами и «возможными числами». Это, на самом деле, гораздо интереснее, чем может показаться. Скоро мы вернёмся к данной идее.

Вышеописанный приём с использованием функции-обёртки — это допустимая стратегия. Мы можем скрываться за функциями столько, сколько нужно. И, так как мы пока не вызывали ни одной из этих функций, все они, теоретически, являются чистыми. И войну никто не начинает. В обычном коде (не связанном с ракетами) нам, на самом деле, в итоге нужны побочные эффекты. Оборачивание всего, что нужно, в функции, позволяет нам с точностью контролировать эти эффекты. Мы сами выбираем время появления этих эффектов.

Надо отметить, что не очень-то удобно всюду использовать однообразные конструкции с кучами скобок для объявления функций. И создавать новые версии каждой функции — тоже занятие не из приятных. В JavaScript есть замечательные встроенные функции, вроде Math.sqrt(). Было бы очень здорово, если бы существовал способ использования этих вот обычных функций с нашими «отложенными значениями». Собственно, об этом мы сейчас и поговорим.

Функтор Effect


Тут мы будем говорить о функторах, представленных объектами, содержащими наши «отложенные функции». Для представления функтора мы будем пользоваться объектом Effect. В такой объект мы поместим нашу функцию fZero(). Но, прежде чем так поступить, сделаем эту функцию немного безопаснее: 

// zero :: () -> Number
function fZero() {
    console.log('Starting with nothing');
    // Тут мы, определённо, не будем запускать никаких ракет.
    // Но чистой эта функция пока не является.
    return 0;
}


Теперь опишем функцию-конструктор для создания объектов типа Effect: 

// Effect :: Function -> Effect
function Effect(f) {
    return {};
}


Тут пока нет ничего особенно интересного, поэтому поработаем над данной функцией. Итак, нам хочется использовать обычную функцию fZero() с объектом Effect. Для обеспечения такого сценария работы напишем метод, который принимает обычную функцию, и когда-нибудь применяет её к нашему «отложенному значению». И мы сделаем это, не вызывая функцию Effect. Мы называем такую функцию map(). Такое название она имеет из-за то, что она создаёт маппинг между обычной функцией и функцией Effect. Выглядеть это может так: 

// Effect :: Function -> Effect
function Effect(f) {
    return {
        map(g) {
            return Effect(x => g(f(x)));
        }
    }
}


Теперь, если вы внимательно следите за происходящим, у вас могут появиться вопросы к функции map(). Выглядит происходящее подозрительно похожим на композицию. Мы вернёмся к этому вопросу позже, а пока опробуем в деле то, что у нас имеется в данный момент: 

const zero = Effect(fZero);
const increment = x => x + 1; // Самая обыкновенная функция.
const one = zero.map(increment);


Так… Сейчас у нас нет возможности наблюдать за тем, что тут произошло. Поэтому давайте модифицируем Effect для того, чтобы, так сказать, получить возможность «спускать курок»: 

// Effect :: Function -> Effect
function Effect(f) {
    return {
        map(g) {
            return Effect(x => g(f(x)));
        },
        runEffects(x) {
            return f(x);
        }
    }
}

const zero = Effect(fZero);
const increment = x => x + 1; // Обычная функция.
const one = zero.map(increment);

one.runEffects();
//   Начинаем с пустого места
//   1


Если будет нужно, мы можем продолжать вызывать функцию map(): 

const double = x => x * 2;
const cube = x => Math.pow(x, 3);
const eight = Effect(fZero)
    .map(increment)
    .map(double)
    .map(cube);

eight.runEffects();
//   Начинаем с пустого места
//   8


Вот здесь происходящее уже начинает становиться интереснее. Мы называем это «функтором». Всё это означает, что у объекта Effect есть функция map() и он подчиняется некоторым правилам. Однако это не такие правила, которые что-либо запрещают. Эти правила посвящены тому, что можно делать. Они больше похожи на привилегии. Так как объект Effect — это функтор, он подчиняется этим правилам. В частности это — так называемое «правило композиции».

Выглядит оно так:

Если имеется объект Effect с именем e, и две функции, f и g, тогда e.map(g).map(f) эквивалентно e.map(x => f(g(x))).

Другими словами, два выполненных подряд метода map() эквивалентны композиции двух функций. Это означает, что объект типа Effect может выполнять действия, подобные следующему (вспомните один из вышеприведённых примеров): 

const incDoubleCube = x => cube(double(increment(x)));
// Если бы мы пользовались библиотеками вроде Ramda или lodash/fp мы могли бы переписать это так:
// const incDoubleCube = compose(cube, double, increment);
const eight = Effect(fZero).map(incDoubleCube);


Когда мы делаем то, что тут показано, мы, гарантированно, получим тот же самый результат, который получили бы, воспользовавшись вариантом этого кода с тройным обращением к map(). Мы можем это использовать при рефакторинге кода, и можем быть уверены в том, что код будет работать правильно. В некоторых случаях, меняя один подход на другой, можно даже добиться повышения производительности.

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

▍Метод of ()


Конструктор объекта Effect принимает, в качестве аргумента, функцию. Это удобно, так как большинство побочных эффектов, выполнение которых мы хотим отложить, являются функциями. Например, это Math.random() и console.log(). Однако иногда нужно поместить в объект Effect некое значение, функцией не являющееся. Например, предположим, что мы прикрепили к глобальному объекту window в браузере некий объект с конфигурационными данными. Нам понадобятся данные из этого объекта, но такая операция недопустима в чистых функциях. Для того чтобы упростить выполнение подобных операций, мы можем написать небольшой вспомогательный метод (в разных языках этот метод называется по-разному, например, не знаю почему, в Haskell он называется pure): 

// of :: a -> Effect a
Effect.of = function of(val) {
    return Effect(() => val);
}


Для того чтобы продемонстрировать ситуацию, в которой может пригодиться подобный метод, представим, что мы работаем над веб-приложением. У этого приложения есть некие стандартные возможности, скажем, оно может выводить список статей и сведения о пользователе. Однако расположение этих элементов в HTML-коде у разных пользователей нашего приложения различается. Так как мы привыкли принимать продуманные решения, мы решили хранить сведения о расположении элементов в глобальном конфигурационном объекте. Благодаря этому мы всегда сможем к ним обратиться. Например: 

window.myAppConf = {
    selectors: {
        'user-bio':     '.userbio',
        'article-list': '#articles',
        'user-name':    '.userfullname',
    },
    templates: {
        'greet':  'Pleased to meet you, {name}',
        'notify': 'You have {n} alerts',
    }
};


Теперь, благодаря вспомогательному методу Effect.of(), мы можем легко поместить нужное нам значение в обёртку Effect: 

const win = Effect.of(window);
userBioLocator = win.map(x => x.myAppConf.selectors['user-bio']);
//   Effect('.userbio')


▍Создание структур из вложенных объектов Effect и раскрытие вложенных структур


Маппинг функций с побочными эффектами может завести нас довольно далеко. Но иногда мы занимаемся маппингом функций, возвращающих объекты Effect. Скажем, это функция getElementLocator(), которая возвращает объект Effect, содержащий строку. Если нам нужно найти элемент DOM, тогда надо вызвать document.querySelector() — ещё одну функцию, которая не отличается чистотой. Очистить её можно так: 

// $ :: String -> Effect DOMElement
function $(selector) {
    return Effect.of(document.querySelector(s));
}


Теперь, если нам нужно всё это объединить, мы можем воспользоваться функцией map(): 

const userBio = userBioLocator.map($);
//   Effect(Effect(
))


С тем, что у нас тут получилось, работать немного неудобно. Если нам нужно получить доступ к соответствующему элементу div, то приходится вызывать map() с функцией, которая тоже выполняет маппинг, что в итоге даёт нужный результат. Например, если нам понадобится innerHTML, то код будет выглядеть так: 

const innerHTML = userBio.map(eff => eff.map(domEl => domEl.innerHTML));
//   Effect(Effect('
User Biography
'))


Попробуем разобрать на части то, что у нас получилось. Начнём с userBio, а отсюда пойдём дальше. Разбирать это будет скучновато, но нам это нужно для того, чтобы как следует разобраться с тем, что здесь происходит. Тут, в ходе описаний, мы будем пользоваться конструкциями вида Effect('user-bio'). Для того чтобы в них не запутаться, надо учитывать, что если записывать подобные конструкции в виде кода, они будут выглядеть примерно так: 

Effect(() => '.userbio');


Хотя и это — тоже не вполне корректно. Скорее это будет выглядеть так: 

Effect(() => window.myAppConf.selectors['user-bio']);


Теперь, когда мы применяем функцию map(), это оказывается аналогичным композиции внутренней функции и другой функции (мы уже видели это выше). В результате, например, когда мы выполняем маппинг с функцией $, выглядит это примерно так: 

Effect(() => $(window.myAppConf.selectors['user-bio']));


Если раскрыть это выражение, то получится следующее: 

Effect(
    () => Effect.of(document.querySelector(window.myAppConf.selectors['user-bio'])))
);


А если теперь раскрыть Effect.of, то перед нами откроется более ясная картина происходящего: 

Effect(
    () => Effect(
        () => document.querySelector(window.myAppConf.selectors['user-bio'])
    )
);


Обратите внимание на то, что весь код, который выполняет реальные действия, находится в самой глубоко вложенной функции. Во внешний объект Effect он не попадает.

▍Метод join ()


Зачем мы со всем этим разбираемся? Делаем мы это для того, чтобы развернуть все эти вложенные объекты Effect. Если мы собираемся это сделать, то мы должны удостовериться в том, что мы не вносим в этот процесс нежелательных побочных эффектов.

Способ избавления от вложенных конструкций при работе с объектами Effect заключается в вызове .runEffect() для внешней функции. Однако это может показаться непонятным. Мы уже прошли через многое, из-за того, что нам нужно было обеспечить такое поведение системы, при котором код, содержащий побочные эффекты, не выполняется. Теперь мы создадим ещё одну функцию, решающую ту же задачу. Назовём её join(). Её будем использовать для разворачивания вложенных структур из объектов Effect, а функцию runEffect() будем использовать тогда, когда нам нужно запустить код с побочными эффектами. Это проясняет наше намерение даже в случае, когда запускаемый нами код остаётся тем же самым.

// Effect :: Function -> Effect
function Effect(f) {
    return {
        map(g) {
            return Effect(x => g(f(x)));
        },
        runEffects(x) {
            return f(x);
        }
        join(x) {
            return f(x);
        }
    }
}


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

const userBioHTML = Effect.of(window)
    .map(x => x.myAppConf.selectors['user-bio'])
    .map($)
    .join()
    .map(x => x.innerHTML);
//   Effect('
User Biography
')


▍Метод chain ()


Вышерассмотренный паттерн, в котором используется вызов метода .map(), за которым следует вызов метода .join(), встречается довольно часто. На самом деле, так часто, что для его реализации было бы удобно создать отдельный вспомогательный метод. В результате мы сможем использовать этот метод всякий раз, когда у нас будет функция, возвращающая объект Effect. Благодаря его использованию нам не придётся постоянно использовать конструкцию, состоящую из последовательности методов .map() и .join(). Вот как, с добавлением этой функции, будет выглядеть конструктор объектов типа Effect: 

// Effect :: Function -> Effect
function Effect(f) {
    return {
        map(g) {
            return Effect(x => g(f(x)));
        },
        runEffects(x) {
            return f(x);
        }
        join(x) {
            return f(x);
        }
        chain(g) {
            return Effect(f).map(g).join();
        }
    }
}


Мы назвали эту новую функцию chain() из-за того, что она позволяет объединять операции, выполняемые над объектами Effect (на самом деле, мы так назвали её ещё и потому что стандарт предписывает называть подобную функцию именно так). Теперь наш код для получения внутреннего HTML-кода блока со сведениями о пользователе будет выглядеть так: 

const userBioHTML = Effect.of(window)
    .map(x => x.myAppConf.selectors['user-bio'])
    .chain($)
    .map(x => x.innerHTML);
//   Effect('
User Biography
')


К несчастью в других языках программирования подобные функции именуются по-другому. Подобное разнообразие имён может запутать при чтении документации. Например, иногда используется имя flatMap. Подобное имя обладает глубоким смыслом, так как тут сначала выполняется обычный маппинг, а потом — раскрытие того, что получилось, с помощью join(). В Haskell, однако, тот же самый механизм имеет сбивающее с толку имя bind. Поэтому, если вы читаете какие-то материалы о функциональном программировании на разных языках, учитывайте, что chain, flatMap и bind — это варианты именования похожих механизмов.

▍Комбинация объектов Effect


Вот ещё один сценарий работы с объектами Effect, реализация которого может оказаться несколько неудобной. Он заключается в комбинировании двух или большего количества таких объектов с использованием одной функции. Например, что если нам понадобилось бы получить имя пользователя из DOM, а затем вставить его в шаблон, предоставленный конфигурационным объектом приложения? Для этого, например, у нас могла бы быть функция для работы с шаблонами, подобная следующей. Обратите внимание на то, что мы создаём каррированную версию функции. Если раньше вы не встречались с каррированием — взгляните на этот материал.

// tpl :: String -> Object -> String
const tpl = curry(function tpl(pattern, data) {
    return Object.keys(data).reduce(
        (str, key) => str.replace(new RegExp(`{${key}}`, data[key]),
        pattern
    );
});


Пока всё выглядит нормально. Теперь давайте получим нужные данные: 

const win = Effect.of(window);
const name = win.map(w => w.myAppConfig.selectors['user-name'])
    .chain($)
    .map(el => el.innerHTML)
    .map(str => ({name: str});
//   Effect({name: 'Mr. Hatter'});

const pattern = win.map(w => w.myAppConfig.templates('greeting'));
//   Effect('Pleased to meet you, {name}');


Итак, у нас есть функция для работы с шаблонами. Она принимает строку и объект и возвращает строку. Однако строка и объект (name и pattern) обёрнуты в объект Effect. Нам нужно вывести функцию tpl() на более высокий уровень, сделав так, чтобы она работала с объектами Effect.
Начнём с анализа того, что происходит при вызове метода map() объекта Effect с передачей этому методу функции tpl(): 

pattern.map(tpl);
//   Effect([Function])


Происходящее станет понятнее, если взглянуть на типы. Сигнатура типа для метода map() выглядит примерно так: 

map :: Effect a ~> (a -> b) -> Effect b


Вот сигнатура функции для работы с шаблонами: 

tpl :: String -> Object -> String


Получается, что когда мы вызываем метод map() объекта pattern, мы получаем частично применённую функцию (вспомните о том, что мы каррировали функцию tpl()) внутри объекта Effect.

Effect (Object -> String)


Теперь мы хотим передать значение из объекта pattern типа Effect. Однако у нас пока нет нужного для выполнения этого действия механизма. Поэтому мы создадим новый метод объекта Effect, который позволит это сделать. Назовём его ap(): 

// Effect :: Function -> Effect
function Effect(f) {
    return {
        map(g) {
            return Effect(x => g(f(x)));
        },
        runEffects(x) {
            return f(x);
        }
        join(x) {
            return f(x);
        }
        chain(g) {
            return Effect(f).map(g).join();
        }
        ap(eff) {
             // Если кто-то вызывает ap, мы исходим из предположения, что в eff имеется функция (а не значение).
            // Мы будем использовать map для того, чтобы войти в eff и получить доступ к этой функции (назовём её 'g')
            // После получения g, мы организуем работу с f() 
            return eff.map(g => g(f()));
        }
    }
}


Теперь можно вызвать .ap() для работы с шаблоном и получения итогового результата: 

const win = Effect.of(window);
const name = win.map(w => w.myAppConfig.selectors['user-name'])
    .chain($)
    .map(el => el.innerHTML)
    .map(str => ({name: str}));

const pattern = win.map(w => w.myAppConfig.templates('greeting'));

const greeting = name.ap(pattern.map(tpl));
//   Effect('Pleased to meet you, Mr Hatter')


Мы достигли цели, но мне надо кое в чём признаться… Дело в том, что я обнаружил, что метод .ap() иногда является источником путаницы. А именно, сложно запомнить, что сначала надо воспользоваться методом map(), а затем вызывать ap(). Далее, можно забыть о том, в каком порядке применяются параметры.

Однако с этими неприятностями можно справиться. Дело в том, что обычно при использовании подобной конструкции я пытаюсь поднять обычные функции до уровня аппликативов. Другими словами, у меня есть обычные функции, и мне нужно, чтобы они умели работать с объектами Effect, у которых есть метод ap(). Мы можем написать функцию, которая всё это автоматизирует: 

// liftA2 :: (a -> b -> c) -> (Applicative a -> Applicative b -> Applicative c)
const liftA2 = curry(function liftA2(f, x, y) {
    return y.ap(x.map(f));
    // Ещё можно было бы написать так:
    //  return x.map(f).chain(g => y.map(g));
});


Эта функция названа liftA2(), так как она работает с функцией, которая принимает два аргумента. Похожим образом можно написать и функцию liftA3(): 

// liftA3 :: (a -> b -> c -> d) -> (Applicative a -> Applicative b -> Applicative c -> Applicative d)
const liftA3 = curry(function liftA3(f, a, b, c) {
    return c.ap(b.ap(a.map(f)));
});


Обратите внимание на то, что в функциях liftA2() и liftA3() объект типа Effect даже не упоминается. В теории, они могут работать с любыми объектами, имеющими совместимый метод ap().

Вышеприведённый пример с использованием функции liftA2() можно переписать так: 

const win = Effect.of(window);
const user = win.map(w => w.myAppConfig.selectors['user-name'])
    .chain($)
    .map(el => el.innerHTML)
    .map(str => ({name: str});

const pattern = win.map(w => w.myAppConfig.templates['greeting']);

const greeting = liftA2(tpl)(pattern, user);
//   Effect('Pleased to meet you, Mr Hatter')


Зачем это всё?


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

© Habrahabr.ru