Что такое функтор? Функциональное программирование

Это серия статей о функциональном программировании:

1. Парадигмы программирования
2. Композиция
3. Функторы (рассматривается в этой статье)
4. Каррирование
5. Чистые функции
6. Функции первого класса

Что такое функтор?

Функтор (functor) это:

• обертка над значением,
• предоставляет интерфейс для преобразование (map),
• подчиняется законам функтора (поговорим о них позже).

Примеры функторов

• Массив (Array),
• Промис (Promise).

Почему массив - функтор?

Вспомним определение функтора:

• обертка над списком значений,
• предоставляет интерфейс для преобразования - метод map,
• подчиняется законам функтора.

[1, 2, 3]      // обернутое значение
  .map(        // интерфейс для преобразования значения
    x => x * 2
  )

Почему промис - функтор?

Промис это:

• обертка над любым значением из JavaSctipt типов,
• предоставляет интерфейс для преобразования - метод then,
• подчиняется законам функтора.

const promise = new Promise((resolve, reject) => {
  resolve(
    { data: "value" } // обернутое значение, в данном случае объект
  )
});
 
promise
  .then(              // интерфейс для преобразования значения
    response => console.log(response)
  );

Что объединяет массив (или промис) и функтор?

Функтор - это паттерн проектирования, а Array и Promise - типы данных, которые основаны на этом паттерне.

Почему мы говорим, что массив и промис - функторы?

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

Где использовать функторы?

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

{
  products: [
    {
      name: "All about JavaScript",
      type: "book",
      price: 22,
      discount: 20
    }
  ]
}

Постановка задачи

Найти финальную цену первого товара с учетом скидки. Если по какой-либо причине будут переданы неправильные данные, вывести строку "No data".

Шаги алгоритма

1. Найти первый продукт со скидкой,
2. Применить скидку,
3. Продолжать проверку данных на валидность. Если данные не валидны - вернуть "No data".

Традиционное решение

const isProductWithDiscount = product => {
  return !isNaN(product.discount)
}
const findFirstDiscounted = products => {
  products.find(isProductWithDiscount)
}
 
const calcPriceAfterDiscount = product => {
  return product.price - product.discount
}
 
const findFinalPrice = (data, fallbackValue) => {
  if(!data || !data.products) return fallbackValue
 
  const discountedProduct = findFirstDiscounted(data.products)
  if(!discountedProduct) return fallbackValue
 
  return calcPriceAfterDiscount(discountedProduct)
}
 
findFinalPrice(data, "No data")

Комментарии к традиционному решению

Достоинства:

• Атомарные логические единицы (isProductWithDiscount, findFirstDiscounted и calcPriceAfterDiscount),
• Логику защищена от невалидных данных.

Что можно улучшить:

• Cлишком много защитных проверок. (Защитное программирование (Defensive programming) является обязательным в любом отказоустойчивом программном обеспечении. Однако, в нашем коде 50% тела функции findFinalPrice — проверка на валидность данных. Это слишком много).
• fallbackValue почти везде.

Почему нас волнуют эти улучшения?

Потому что данный код заставляет слишком в него вникать. Это негативно влияет на DX (Developer Experience) - уровень удовлетворенности разработчика от работы с кодом. Проанализируем код, чтобы прийти к лучшему решению. Части, которые мы стремимся улучшить, формируют паттерны (защита (defence) и откат (fallback)). Хорошо то, что эти части на самом деле цельные и атомарные. Мы должны иметь возможность абстрагировать этот паттерн в оболочку, которая могла бы обрабатывать эти крайние случаи вместо нас. Обертка позаботится о крайних случаях, а нам останется позаботиться только о бизнес-логике.

Функтор Maybe

Как мы обсуждали ранее, нам нужна только обертка, которая абстрагируется от обработки данных. Итак, роль функтора Maybe состоит в том, чтобы обернуть наши данные (потенциально невалидные данные) и обработать для нас крайние случаи.

Имплементация функтора Maybe

function Maybe(value) {
  const isNothing = () => {
    return value === null || value === undefined
  }
  
  const map = (fn) => {
    return isNothing() ? Maybe() : Maybe(fn(value))
  }
 
  const getValueOrFallback = {
    return (fallbackValue) => isNothing() ? fallbackValue : value;
  }
 
  return {
    map,
    getValueOrFallback,
  };
}

Пояснения к имплементации

• isNothing проверяет валидно ли обернутое в функтор Maybe значение
• map - интерфейс для преобразования обернутого значения, с помощью которого мы применяем функции с бизнес логикой к обернутому значению. map возвращает новое значение в другом экземпляре Maybe. Таким образом, мы можем сделать цепочку вызовов map - .map().map().map....
• getValueOrFallback возвращает обернутое значение или запасное значение fallbackValue.

Как использовать функтор Maybe?

С валидными данными:

Maybe('Hello')
  .map(x => x.substring(1))
  .getValueOrFallback('fallback') // 'ello'

С невалидными данными:

Maybe(null)
  .map(x => x.substring(1))       // функция не будет запущена
  .getValueOrFallback('fallback') // 'fallback'

Функтор Maybe обработал крайние случаи вместо нас и не запустил функцию с невалидными данными. Нам нужно лишь позаботиться о бизнес логике. Таким образом, мы внедрили улучшение, о котором говорили в традиционном решении. Внедрим это решение в задачу.

Решение задачи с функтором Maybe

const isProductWithDiscount = product => {
  return !isNaN(product.discount)
}
const findFirstDiscounted = products => {
  return products.find(isProductWithDiscount)
}
const calcPriceAfterDiscount = product => {
  return product.price - product.discount
}
 
Maybe(data)
 .map((x) => x.products)
 .map(findFirstDiscounted)
 .map(calcPriceAfterDiscount)
 .getValueOrFallback("No data")

Комментарии к решению с функтором Maybe

Мы смогли улучшить традиционное решение при помощи функтора Maybe:

• мы не защищаем код сами, вместо нас это делает функтор Maybe,
• мы указали fallbackValue только один раз.

Как функтор Maybe соответствует определению функтора? Функтор Maybe это:

1. обертка над любым значением из JavaScript типов,
2. предоставляет интерфейс для преобразования - метод map,
3. подчиняется законам функтора.

Законы функторов

Закон идентичности (Identity law)

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

const m1 = Maybe(value)
const m2 = Maybe(value).map(v => v)
// m1 и m2 эквивалентны

Закон композиции (Composition law)

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

const m1 = Maybe(value).map(v => f(g(v)))
const m2 = Maybe(value).map(v => g(v)).map(v => f(v))
// m1 и m2 эквивалентны

Зачем использовать функторы?

• Абстракция над применением функции,
• Усиление композиции функций,
• Уменьшение количества защитного кода (как в функторе Maybe),
• Более чистая структура кода,
• Переменные более явно указывают на то, что мы ожидаем (что Maybe моделирует значение, которое может присутствовать, а может и не присутствовать).

Что означает Абстракция над применением функции?

То, что мы передаем функцию (т.е. x => x.products) в интерфейс преобразования (т.е. map) обертки (т.е. Maybe), и она знает, как позаботиться о себе (посредством своей внутренней реализации). Нас не интересуют детали реализации оболочки, которые она содержит (детали реализации скрыты), и тем не менее мы знаем, как использовать обертку (Array или Promise), используя их интерфейсы преобразования (map). И это на самом деле крайне важно в мире программирования. Это снижает планку того, как много мы, как программисты, должны понимать, чтобы иметь возможность что-то сделать. Функторы могут быть реализованы на любом языке, поддерживающем функции высшего порядка (а таких в наши дни большинство).

Почему функторы не используются повсеместно?

Просто потому, что мы к ним не привыкли. До .map (и .then) мы мутировали массивы или перебирали их значения вручную. Но как только мы обнаружили .map, мы начали адаптировать его в качестве нового инструмента преобразования. Я надеюсь, что, поняв ценность функторов, мы начнем чаще внедрять их в наши ежедневные задачи как привычный инструмент. Функтор Maybe - лишь пример функтора. Существует множество функторов, которые выполняет различные задачи. В этой статье мы рассмотрели самый простой из них, чтобы понять саму идею функторов.

Итоги

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

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

Что такое побочные эффекты?

Побочным эффектом (сайд эффект, side effect) в контексте модуля ECMAScript является код, который выполняет некоторое внешне видимое поведение (то есть поведение, видимое вне модуля) при загрузке модуля. Вот пример:

import { registerThing } from 'thing-registry';
const store = registerThing( THING_KEY, { /* ... */ } );

registerStore вызывается на верхнем уровне, что означает, что он будет запущен, как только модуль будет впервые импортирован. Эти изменения видны внешне, так как вещи модифицируются во внешнем хранилище, которое находится в другом модуле (thing-registry). Другие примеры побочных эффектов включают установку глобальных значений в window или добавление поведения браузера с помощью полифиллов (polyfills).

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

import { registerThing } from 'thing-registry';
 
export function init() {
  const store = registerThing( THING_KEY, { /* ... */ } );
}
 
// `init` не вызывается на верхнем уровне модуля,
// и таким образом импорт этого модуля не вызывает сайд эффектов.

Объявление переменной или выполнение каких-либо изменений на верхнем уровне, которые влияют только на текущий модуль, также не является побочным эффектом, поскольку они содержатся в модуле:

import list from './list';
 
// не сайд эффект
let localVariable = [];
 
// тоже не сайд эффект
for ( const entry of list ) {
  localVariable.push( processListEntry( entry ) );
}

Влияние побочных эффектов на сборку

Большинство современных сборщиков реализуют tree shaking, при котором неиспользуемый код удаляется из финальных бандлов, так как в этом нет необходимости. Это становится важным в библиотеках, которые предлагают множество различных функций, поскольку потребители этой библиотеки могут использовать только небольшую ее часть и не хотят, чтобы их бандлы были больше, чем необходимо. Таким образом, пакеты и библиотеки должны предпринять шаги для обеспечения того, чтобы их действительно можно было правильно встряхнуть. Это возвращает нас к побочным эффектам. Как мы видели, побочные эффекты — это код, который запускается просто в силу импорта модуля и оказывает какое-то внешнее влияние. Это означает, что код не может быть вытряхнут деревом; Он должен работать, потому что он изменяет вещи за пределами модуля, которые могут понадобиться в другом месте. К сожалению, побочные эффекты трудно определить автоматически, и некоторые сборщики (например, webpack) ошибаются в сторону осторожности, предполагая, что каждый модуль потенциально имеет побочные эффекты. Это становится проблемой для index модулей, которые повторно экспортируют (ре-экспортируют) вещи из других модулей, поскольку это фактически означает, что все, что там есть, теперь должно быть объединено вместе:

// index.js
 
export { a, b } from './module1';
export { c, d, e } from './module2';
export { f } from './module3';
 
// Tree shaking не может быть применен, т.к. сборщик не знает
// имеют ли эти ре-экспортируемые модули сайд эффекты.

Рассказываем сборщикам о побочных эффектах

Поскольку сборщики не могут сами разобраться в побочных эффектах, нам нужно явно заявить о них. Это делается в package.json пакетов. Это означает, что объявление побочных эффектов является обязанностью пакета, и для пакетов, которые этого не делают, webpack, скорее всего, не сможет ничего стереть. Пользователи такого пакета могут в конечном итоге вытащить все это в свою сборку, даже если они используют только небольшую часть пакета, часто без простого способа обойти его. Так как же заявить о побочных эффектах? Лучший способ сделать это зависит от того, насколько вы их используете и где они находятся в вашем коде. Очень часто ваш пакет вообще не будет использовать никаких побочных эффектов. В этой ситуации вы можете просто установить sideEffects значение false:

{
  "name": "package",
  "sideEffects": false
}

Если в нем есть несколько файлов с побочными эффектами, вы можете перечислить их:

{
  "name": "package",
  "sideEffects": [ "dist/store.js", "dist/polyfill.js" ]
}

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

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

{
  "name": "package",
  "sideEffects": [
    "!(dist/(components|utils)/**)"
  ]
}

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

function noSideEffects() {
  // Do something.
}
 
noSideEffects();

Сборщик не может определить, содержит ли вызов верхнего уровня noSideEffects какие-либо побочные эффекты. Одним из решений было бы включение модуля в поле package.json sideEffects, как мы видели выше. Однако мы также можем обрабатывать его в коде с помощью подсказки PURE:

function noSideEffects() {
  // Do something.
}
 
/*#__PURE__*/ noSideEffects();

Потеря побочных эффектов у потребителя

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

// index.js
 
import 'side-effectful-module';
 
export { a, b } from './impl';

// impl.js
 
function a() {
  // что-то делает
}
 
function b() {
  // делает что-то, что зависит от произошедших сайд эффектов
}

В index.js мы видим то, что часто называют “голым импортом” (naked import). Этот синтаксис означает, что мы не используем ни один из экспортов модуля, и нас фактически интересуют только его побочные эффекты. Голый импорт сам по себе не является побочным эффектом, но он является очень сильным сигналом о том, что побочные эффекты присутствуют во всем, что вы импортируете. index.js не делает ничего, кроме импорта side-effectful-module, просто ре-экспортируя функции из impl.js. Ключевым моментом здесь является то, что функции в impl.js на самом деле зависят от побочного эффекта, который происходит в index.js. Если встряхивание деревьев отключено, например, в режиме разработки, все будет работать правильно. Однако, если встряхивание дерева включено, модуль index.js может быть удален из дерева, оставив только фактические функции из impl.js. Если это произойдет, побочный эффект будет потерян, и b потерпит неудачу. То же самое может произойти, если импорт выполняется в дочернем модуле:

// index.js
 
import { unused } from './util';
 
function b() {
  // делает что-то, что зависит от произошедших сайд эффектов
}
 
// Этот модуль не использует функцию `unused`.

// util.js
 
import "side-effectful-module";
 
export function unused() {
  // делает что-то, что зависит от произошедших сайд эффектов
}

Поскольку unused не используется в index.js, он будет вытряхнут деревом. Это означает, что ничего из impl.js больше не нужно, поэтому ничего из этого не будет загружено. В очередной раз мы теряем побочный эффект, хотя он необходим.

Предотвращение побочных эффектов при встряхивании деревьев

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

// index.js
 
import "side-effectful-module";
import { unused } from './util';
 
function b() {
  // делает что-то, что зависит от произошедших сайд эффектов
}
 
// этот модуль все еще не использует `unused`.

Это гарантирует, что side-effectful-module будет выполняться перед любым кодом в index.js и не будет вытряхиваться из дерева. Обратите внимание, что теперь мы импортируем побочный эффект в оба модуля, но это нормально! Модули ES запускаются только один раз, а это означает, что их побочные эффекты также будут запускаться только один раз, независимо от того, сколько файлов они импортированы.

Подведем итоги

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

• Если ваша библиотека не содержит побочных эффектов, установите sideEffects: false в package.json.
• Если ваша библиотека содержит побочные эффекты, вы все равно можете включить встряхивания деревьев насколько это возможно. Перечислите файлы с побочными эффектами в явном виде или используйте обратные условия, чтобы перечислить пути, которые не имеют побочных эффектов.
• Если вы полагаетесь на побочные эффекты от внешнего модуля, обязательно импортируйте этот модуль везде, где вы их используете.