В этом первом посте мы обсудим несколько функциональных основных концепций с практическим подходом, останавливаясь на теоретической части, только если это строго необходимо. Во втором мы поговорим о функциональных потоках, а в третьем и четвертом эпизодах мы реализуем с нуля нашу версию RxJS .
Введение
Функциональное программирование моделирует программное обеспечение как набор чистых функций, избегая общего изменяемого состояния. Пока достаточно знать, что чистая функция — это функция, которая не изменяет среду, и ее возвращаемое значение одинаково для тех же аргументов . Между тем, основная проблема с общим состоянием заключается в том, что оно снижает предсказуемость и усложняет отслеживание логического потока.
Чтобы было ясно: разные проблемы требуют разных инструментов, идеальной и универсальной парадигмы не существует, но существует множество ситуаций, когда FP может принести преимущества. Вот резюме:
- сосредоточиться на том, чего вы хотите достичь (декларативно), а не как (обязательно)
- более читаемый код, который скрывает бесполезные детали реализации
- чистый логический поток , состояние менее рассредоточено и неявно изменено
- функции / модули стали легко тестируемыми , многоразовыми и обслуживаемыми
- «Безопасный» код без побочных эффектов
Почему мы заботимся об императивных и декларативных подходах? Давайте обсудим разницу с примером, который выполняет одну и ту же операцию в обоих направлениях: отфильтровывать нечетные числа из списка, увеличивая до пяти меньших.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
const numbers = [1,2,3,4,5,6,7,8,9,10] // IMPERATIVE approach let result = [] for (let i = 0; i < numbers.length; i++) { if (numbers[i] % 2 === 0) { if (numbers[i] < 5) { result.push(5) continue } result.push(numbers[i]) } } // DECLARATIVE approach numbers .filter(n => n % 2 === 0) .map(n => n < 5 ? 5 : n) |
То же вычисление, тот же результат. Но, как вы можете видеть, императивный код является многословным и не сразу понятным. С другой стороны, декларативный подход читабелен и явен , потому что он фокусируется на том, что мы хотим получить. Представьте себе, что можно распространить ту же разницу на большие части ваших приложений и вернуться к тому же коду через несколько месяцев. Ваше будущее я (и ваши коллеги тоже) оценят этот декларативный стиль!
Опять же, нет «лучшей парадигмы», как кто-то может утверждать, только подходящий инструмент для конкретного случая, действительно, я также большой поклонник ООП, когда реализуется с использованием композиции («путь» Go). В любом случае, функциональное программирование может найти несколько мест в ваших приложениях для улучшения читабельности и предсказуемости.
Давайте начнем исследовать некоторые основные концепции FP. Посмотрим, как каждый из них принесет некоторые из преимуществ, перечисленных выше.
Чистые функции
Функция является чистой, когда:
- у него нет видимых побочных эффектов , таких как ввод-вывод, мутация внешних переменных, изменения файловой системы, изменения DOM, HTTP-вызовы и многое другое,
- имеет ссылочную прозрачность : функция может быть заменена результатом ее выполнения без изменения результата общего вычисления.
Давайте уточним определение с некоторыми основными примерами.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
// impure, modifies external state let counter = 0 const incrementCounter = (n) => { counter = counter + n return counter } // impure, I/O const addAndSend = (x1, x2) => { const sum = x1 + x2 return fetch(`SOME_API?sum=${sum}`) } // both pure, no side effects const add = (x1, x2) => { return x1 + x2 } const formatUsers = users => { if (!(users instanceof Array)) { return [] } return users.map(user => ` Name: ${user.first} ${user.last}, Age: ${user.age} `) } |
Чистые функции «безопасны», потому что они никогда не изменяют неявно любую переменную, от которой другие части вашего кода могут зависеть сейчас или позже.
Может показаться неудобным кодировать с этими ограничениями, но подумайте об этом: чистые функции являются детерминированными , « абстрагируемыми », предсказуемыми и компонуемыми .
Функции как значения
В языках, которые поддерживают FP, функции являются значениями , поэтому вы можете передавать и возвращать их в и из других функций и сохранять их в переменных.
В JS мы уже привыкли к этому шаблону (возможно, не сознательно), например, когда мы предоставляем обратный вызов для прослушивателя событий DOM или когда мы используем методы массива, такие как map, reduceили filter.
Давайте снова посмотрим на предыдущий пример:
|
1 2 3 4 5 6 7 8 9 |
const formatUsers = users => { if (!(users instanceof Array)) { return [] } return users.map(user => ` Name: ${user.first} ${user.last}, Age: ${user.age} `) } |
Здесь mapаргумент представляет собой встроенную анонимную функцию (или лямбду ). Мы можем переписать приведенный выше фрагмент, чтобы более четко продемонстрировать идею «функция как значение», в которой функция userFявно передана map.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
const userF = user => { return ` Name: ${user.first} ${user.last}, Age: ${user.age} ` } const formatUsers = users => { if (!(users instanceof Array)) { return [] } return users.map(userF) } |
Тот факт, что функции в JS являются значениями, позволяет использовать функции высшего порядка (HOF): функции, которые получают другие функции в качестве аргументов и / или возвращают новые функции , часто полученные из функций , полученных в качестве входных данных. HOFs используются для различных целей, таких как специализация и состав функций.
Давайте посмотрим на getHOF. Эта утилита позволяет безопасно и без ошибок получать значения внутренних узлов объектов / массивов (совет: синтаксис ...propsопределен как REST, он используется для сбора списка аргументов в виде массива, сохраненного в параметре с именем props).
|
1 2 3 4 5 6 7 8 |
const get = (...props) => obj => { return props.reduce( (objNode, prop) => objNode && objNode[prop] ? objNode[prop] : null, obj ) } |
Get получает список ключей, используемых для поиска нужного значения, и возвращает (специализированную) функцию, которая ожидает, что объект будет копаться.
Вот реалистичный пример. Мы хотим извлечь descriptionузел из первого элемента в массиве monumentsиз не всегда полного объекта (возможно, полученного из ненадежного API). Мы можем создать безопасный метод получения, чтобы сделать это.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
const Milan = { country: 'Italy', coords: { lang: 45, lat: 9 }, monuments: [ { name: 'Duomo di Milano', rank: 23473, infos: { description: 'Beautiful gothic church build at the end of…', type: 'Church' } }, { /* ... */ }, { /* ... */ }, { /* ... */ } ] } |
Не нужно многократных (скучных) проверок:
|
1 2 3 4 5 6 7 |
const getBestMonumentDescription = get('monuments', 0, 'infos', 'description') getBestMonumentDescription(Milan) // 'Beautiful gothic church…' getBestMonumentDescription({}) // null (and no errors) getBestMonumentDescription(undefined) // null (same for null, NaN, etc..) getBestMonumentDescription() // null |
Композиция функций
Чистая функция может быть составлена вместе, чтобы создать безопасную и более сложную логику из-за отсутствия побочных эффектов . Под «безопасным» я подразумеваю, что мы не собираемся изменять среду или внешние переменные (функции), на которые могли бы положиться другие части нашего кода.
Конечно, использование чистых функций для создания новых не гарантирует чистоту последних, если мы не будем тщательно избегать побочных эффектов в каждой из его частей. Давайте возьмем пример. мы хотим суммировать деньги всех пользователей, которые удовлетворяют заданному условию.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
const users = [ {id: 1, name: "Mark", registered: true, money: 46}, {id: 2, name: "Bill", registered: false, money: 22}, {id: 3, name: "Steve", registered: true, money: 71} ] // simple pure functions const isArray = v => v instanceof Array const getUserMoney = get('money') const add = (x1, x2) => x1 + x2 const isValidPayer = user => get('registered')(user) && get('money')(user) > 40 // desired logic export const sumMoneyOfRegUsers = users => { if ( !isArray(users) ) { return 0 } return users .filter( isValidPayer ) .map( getUserMoney ) .reduce( add, 0 ) } sumMoneyOfRegUsers(users) // 117 |
Мы filterпользовательский массив, мы генерируем второй с денежными суммами ( map) и, наконец, мы суммируем ( reduce) все значения. Мы составили логику нашей работы в четкой, декларативной и удобочитаемой форме. В то же время мы избегали побочных эффектов, поэтому состояние / среда до и после вызова функции одинаковы.
|
1 2 3 |
// application state const money = sumMoneyFromRegisteredUsers(users) // same application state |
Помимо ручной композиции, есть утилиты, которые помогают нам составлять функции. Два из них особенно полезны: pipeи compose. Идея проста: мы собираемся объединить n функций, вызывая каждую из них с выводом предыдущей.
|
1 2 3 4 5 6 7 8 9 10 |
// function composition with pipe // pipe(f,g,h)(val) === h(g(f(val))) const pipe = (...funcs) => { return (firstVal) => { return funcs.reduce((partial, func) => func(partial), firstVal) } } // or more concisely const pipe = (...fns) => x0 => fns.reduce((x, f) => f(x), x0) |
Pipeэто HOF, который ожидает список функций. Затем возвращаемая функция нуждается в начальном значении, которое пройдет через все предыдущие предоставленные функции в цепочке ввода-вывода. Composeочень похоже, но работает справа налево:
|
1 2 |
// compose(f,g,h)(val) === f(g(h(val))) const compose = (...fns) => x0 => fns.reduceRight((x, f) => f(x), x0) |
Давайте проясним идею на простом примере:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
// simple functions const arrify = x => x instanceof Array ? x : [x] const getUserMoney = get('money') const getUserReg = get('registered') const filterValidPayers = users => users.filter( user => getUserReg(user) && getUserMoney(user) > 40 ) const getUsersMoney = users => users.map(getUserMoney) const sumUsersMoney = moneyArray => moneyArray.reduce((x, y) => x + y, 0) // desired logic export const sumMoneyOfRegUsers = pipe( arrify, filterValidPayers, getUsersMoney, sumUsersMoney ) // get result sumMoneyOfRegUsers(users) // 117 |
Мы также можем проверить каждый промежуточный результат с помощью tapутилиты.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
// debug-only const tap = thing => { console.log(thing) return thing } export const sumMoneyOfRegUsers = pipe( arrify, filterValidPayers, tap, getUsersMoney, tap, sumUsersMoney ) // get result sumMoneyOfRegUsers(users) // [{...}, {...}] first tap // [46, 71] second tap // 117 final result |
Неизменность и неизменность подхода
Неизменность является основной концепцией в FP. Структуры данных следует считать неизменными, чтобы избежать побочных эффектов и повысить предсказуемость . Эта концепция приносит другие преимущества: отслеживание мутаций и производительность (в определенных ситуациях).
Чтобы достичь неизменности в JS, мы должны принять неизменный подход по соглашению, то есть копировать объекты и массивы вместо мутаций «на месте». Другими словами, мы всегда хотим сохранить исходные данные, создавая новые копии .
Объекты и массивы передаются по ссылке в JS, то есть, если на них ссылаются другие переменные или они передаются в качестве аргументов, изменения последних влияют также на оригиналы. Иногда копирование объекта поверхностным способом (глубиной в один уровень) недостаточно, поскольку могут быть внутренние объекты, которые в свою очередь передаются по ссылке.
Если мы хотим разорвать все связи с оригиналом, мы должны клонировать, как мы говорим, глубоко . Кажется сложным? Возможно, но потерпите меня несколько минут! ?
Наиболее полезные языковые инструменты для клонирования и обновления структур данных:
- объект и оператор распространения массива (синтаксис «…»),
- методы массивов, как отображение, фильтрация и уменьшение. Они оба возвращают мелкую копию.
Вот некоторые операции редактирования, выполняемые с неизменным подходом:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// OBJECT SPREAD OPERATOR const user = { id: 1, name: 'Mark', money: 73, registered: true } const updatedUser = { ...user, registered: false } // ARRAY SPREAD OPERATOR const cities = [ 'Rome', 'Milan', 'New York' ] const newCities = [ ...cities, 'London' ] |
В обоих примерах отдельные элементы массива и отдельные свойства объекта копируются в новый массив и новый объект соответственно, которые не зависят от исходных.
Чтобы редактировать, добавлять или удалять элементы из массива объектов неизменным образом, мы могли бы использовать комбинацию операторов распространения и методов массива. Каждый раз мы создаем новую коллекцию с некоторыми вариациями, исходя из конкретной задачи.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
// original const subscribers = [ {id: 1, name: 'Tyler', registered: true, money: 36 }, {id: 2, name: 'Donald', registered: true, money: 26 }, {id: 3, name: 'William', registered: true, money: 61 } ] // EDIT const newSubscribers1 = subscribers .map( sub => sub.name === 'Donald' ? {...user, money: 89} : user ) // DELETE const newSubscribers2 = newSubscribers1.filter( sub => sub.name !== 'Tyler' ) // ADD const newSubscribers3 = [ ...newSubscribers2, { id: 4, name: 'Bob', registered: false, money: 34 } ] |
Давайте быстро поговорим о мелких и глубоких копиях , начиная с некоторого кода.
|
1 2 3 4 5 6 7 8 9 |
const subscribers = [ { id: 1, name: 'Tyler', registered: true, money: 36 }, { id: 2, name: 'Donald', registered: true, money: 26 }, { id: 3, name: 'William', registered: true, money: 61 } ] // SHALLOW copy const newSubscribers1 = [ ...subscribers ] // DEEP copy (specific case) const newSubsibers2 = subscribers.map( sub => ({...user}) ) |
Разница между двумя типами копий заключается в том, что, если мы изменим свойство объекта в массиве с мелким копированием, это изменение также будет отражено в оригинале, чего не происходит в глубокой копии. В последнем случае это происходит потому, что в дополнение к операции клонирования массива мы также клонируем содержащиеся объекты.
Оба типа копий удобны в использовании и хороши, если вы всегда клонируете части, которые необходимо изменить . Таким образом, мы никогда не будем изменять оригинал.
Общее «глубокое» решение сделано с рекурсивными функциями (которые мы должны взять из библиотек для удобства и надежности). Глубокие копии полезны, если мы хотим быть полностью свободными в манипулировании данными или если мы не доверяем стороннему коду.
Примечание о производительности
Давайте кратко поговорим о производительности . Существуют определенные ситуации, когда неизменность может повысить наши приложения. Например, клон будет размещен в ячейке памяти, отличной от оригинала, что позволяет легко и быстро сравнивать по ссылке. Тот же указатель / ссылка (=== для объектов)? Без изменений. Другая ссылка? Изменения обнаружены, поэтому реагируйте правильно. Нет необходимости внутренних сравнений, потому что мы решили создать отдельные копии для каждого изменения.
С другой стороны, создание новых копий каждый раз может привести к значительному потреблению памяти, что приведет к снижению производительности. Это хорошо известная внутренняя проблема функционального программирования, решаемая путем разделения частей манипулируемых структур данных между клонами. В любом случае, эта сложная тема выходит за рамки настоящей статьи.
Полное управление и побочные эффекты
В какой-то момент нам нужно использовать состояние, чтобы сохранить постоянные переменные, сделать несколько операций ввода-вывода, изменить файловую систему и так далее. Без этих операций приложение — просто черный ящик. Итак, как и где управлять состоянием и побочными эффектами?
Давайте начнем с основ. Почему мы стараемся избегать общего, изменчивого и рассеянного состояния? Что ж, проблема в основном сводится к этой идее: с общим состоянием, чтобы понять влияние функции, вы должны знать всю историю каждой разделяемой переменной, которую функция использует или затрагивает. Другой способ решить эту проблему: функции / операции / подпрограммы, которые воздействуют на общее состояние, зависят от времени и порядка .
В заключение, разделяемое изменяемое состояние снижает предсказуемость и усложняет отслеживание логического потока.
Чистые языки FP имеют тенденцию выдвигать состояние и побочные эффекты на границах приложения, чтобы управлять ими в одном месте. Действительно, функциональное решение этой проблемы заключается в обработке состояния в одном (большом) объекте «вне» приложения , обновленном неизменным подходом (таким образом, клонируется и обновляется каждый раз).
В области внешней разработки этот шаблон применяется и реализуется с помощью так называемых менеджеров состояний, таких как Redux, Vuex и NgRx. За счет увеличения кода (не так много) и сложности наши приложения станут более предсказуемыми, управляемыми и обслуживаемыми.
Вот как работают менеджеры состояний в супер упрощенной диаграмме. События запускают действия, которые активируют редукторы, которые обновляют состояние (хранилище). В результате (в основном) пользовательский интерфейс без сохранения состояния будет обновлен должным образом. Аргументация сложная, но я кратко коснулся темы, чтобы познакомить вас с основной идеей.
Кроме того, побочные эффекты заключены в контейнеры и выполняются в одной или нескольких конкретных точках приложения (см. Эффекты NgRx), всегда с целью улучшения их управления.
Кроме того, этот шаблон позволяет отслеживать мутации . Что мы имеем в виду? Если мы обновляем состояние приложения только с неизменяемыми версиями, мы можем собирать их с течением времени (даже тривиально в массиве). В результате мы можем легко отслеживать изменения и переключаться с одного «состояния» приложения на другое. Эта функция известна как отладка путешествий во времени в Redux-подобных менеджерах состояний.
Выводы
В попытке широко рассмотреть FP, мы не говорили о некоторых важных концепциях, которые мы должны упомянуть сейчас: каррирование и частичное применение , запоминание и функциональные типы данных .
Подробное обсуждение FP будет занимать месяцы, но я думаю, что это введение уже является хорошей отправной точкой для тех, кто хочет представить парадигму в некоторых частях своих приложений.