что такое side effects js
Борьба с грязными побочными эффектами в чистом функциональном JavaScript-коде
Если вы пробуете свои силы в функциональном программировании, то это значит, что вы довольно скоро столкнётесь с концепцией чистых функций. Продолжая занятия, вы обнаружите, что программисты, предпочитающие функциональный стиль, похоже, прямо-таки одержимы этими функциями. Они говорят о том, что чистые функции позволяют рассуждать о коде. Они говорят, что чистые функции — это сущности, которые вряд ли будут работать настолько непредсказуемо, что приведут к термоядерной войне. Ещё вы можете узнать от таких программистов, что чистые функции обеспечивают ссылочную прозрачность. И так — до бесконечности.
Кстати, функциональные программисты правы. Чистые функции — это хорошо. Но есть одна проблема…
Проблема чистых функций
Чистая функция — это функция, не имеющая побочных эффектов (на самом деле, это — не полное определение чистой функции, но мы к такому определению ещё вернёмся). Однако если вы хоть что-то понимаете в программировании, то вы знаете, что самое важное здесь как раз таки и заключается в побочных эффектах. Зачем вычислять число Пи до сотого знака после запятой, если никто это число не сможет прочесть? Для того чтобы вывести что-то на экран или распечатать на принтере, или представить в каком-то другом виде, доступном для восприятия, нам нужно вызвать из программы подходящую команду. А какая польза от баз данных, если в них ничего нельзя записывать? Для обеспечения работы приложений нужно считывать данные из устройств ввода и запрашивать информацию из сетевых ресурсов. Всё это нельзя сделать без побочных эффектов. Но, несмотря на такое положение дел, функциональное программирование построено вокруг чистых функций. Как же программистам, которые пишут программы в функциональном стиле, удаётся решить этот парадокс?
Если ответить на этот вопрос в двух словах, то функциональные программисты делают то же, что и математики: они жульничают. Хотя, несмотря на это обвинение, надо сказать, что они, с технической точки зрения, просто следуют определённым правилам. Но они находят в этих правилах лазейки и расширяют их до невероятных размеров. Делают они это двумя основными способами:
Внедрение зависимостей
Внедрение зависимостей — это первый метод работы с побочными эффектами. Используя этот подход, мы берём всё, что загрязняет код, и выносим это в параметры функции. Затем мы можем рассматривать всё это как нечто, входящее в сферу ответственности какой-то другой функции. Поясню это на следующем примере:
Тут хотелось бы сделать примечание для тех, кто знаком с сигнатурами типов. Если бы мы строго придерживались правил, то нам надо было бы учесть здесь и побочные эффекты. Но мы займёмся этим позже.
У функции logSomething() есть две проблемы, не позволяющие признать её чистой: она создаёт объект Date и что-то выводит в консоль. То есть, наша функция не только выполняет операции ввода-вывода, она ещё и выдаёт, при её вызове в разное время, разные результаты.
Как сделать эту функцию чистой? С помощью техники внедрения зависимостей мы можем взять всё, что загрязняет функцию и сделать это параметрами функции. В результате, вместо того, чтобы принимать один параметр, наша функция будет принимать три параметра:
Теперь, для того, чтобы вызвать функцию, нам надо самостоятельно передавать ей всё, что её до этого загрязняло:
Тут вы можете подумать, что всё это — глупость, что мы лишь переместили проблему на один уровень вверх, а это не добавило чистоты нашему коду. И знаете, это — правильные мысли. Это — лазейка в чистом виде.
Это похоже на притворную безграмотность: «Я и не знал, что вызов метода log объекта cnsl приведёт к выполнению оператора ввода-вывода. Мне просто это кто-то передал, а я знать не знаю, откуда всё это взялось». Такое отношение к делу — это неправильно.
Кроме того, важно отметить, что мы можем передавать нашей функции, которая раньше не отличалась чистотой, другие функции. Взглянем на другой пример. Представим, что в некоей форме имеется имя пользователя и нам нужно получить значение соответствующего поля этой формы:
Если надо, мы можем выносить непредсказуемые механизмы на уровни, ещё более отдалённые от основной функции. В итоге мы можем вынести их, условно говоря, в «пограничные области» кода. Это приведёт к тому, что у нас будет тонкая оболочка из нечистого кода, которая окружает хорошо протестированное и предсказуемое ядро. Предсказуемость кода оказывается крайне ценным его свойством тогда, когда размеры проектов, создаваемых программистами, растут.
▍Недостатки механизма внедрения зависимостей
Используя внедрение зависимостей можно написать большое и сложное приложение. Я это знаю, так как сам написал такое приложение. При таком подходе упрощается тестирование, становятся чётко видны зависимости функций. Но внедрение зависимостей не лишено недостатков. Главный из них заключается в том, что при его применении могут получаться очень длинные сигнатуры функций:
На самом деле, это не так уж и плохо. Минусы таких конструкций проявляются в том случае, если некоторые из параметров нужно передавать неким функциям, которые очень глубоко вложены в другие функции. Выглядит это как необходимость передавать параметры через много уровней вызовов функций. Когда число таких уровней растёт, это начинает раздражать. Например, может возникнуть необходимость в передаче объекта, представляющего дату, через 5 промежуточных функций, при том, что ни одна из промежуточных функций этим объектом не пользуется. Хотя, конечно, нельзя сказать, что подобная ситуация — это нечто вроде вселенской катастрофы. К тому же, это даёт возможность чётко видеть зависимости функций. Правда, как бы там ни было, это всё равно не так уж и приятно. Поэтому рассмотрим следующий механизм.
▍Ленивые функции
Взглянем на вторую лазейку, которую используют приверженцы функционального программирования. Она заключается в следующей идее: побочный эффект — это не побочный эффект до тех пор, пока он не произойдёт на самом деле. Знаю, звучит это таинственно. Для того чтобы в этом разобраться, рассмотрим следующий пример:
Итак, перед нами пример нечистой функции. Она выводит данные в консоль и ещё является причиной ядерной войны. Однако вообразите, что нам нужен тот ноль, который эта функция возвращает. Представьте себе сценарий, в соответствии с которым нам надо что-то посчитать после запуска ракеты. Скажем, нам может понадобиться запустить таймер обратного отсчёта или что-то в этом роде. В данном случае совершенно естественным будет заранее подумать о выполнении вычислений. И мы должны позаботиться о том, чтобы ракета запустилась именно тогда, когда нужно. Нам не надо выполнять вычисления таким образом, чтобы они могли бы случайно привести к запуску этой ракеты. Поэтому подумаем над тем, что произойдёт, если мы обернём функцию fZero() в другую функцию, которая просто её возвращает. Скажем, это будет нечто вроде обёртки для обеспечения безопасности:
Есть ли у неё побочные эффекты? Мы только что выяснили, что вызов returnZeroFunc() не приводит к запуску ракет. Если не вызывать то, что возвращает эта функция, ничего не произойдёт. Поэтому мы можем заключить, что у этой функции нет побочных эффектов.
Является ли эта функция ссылочно прозрачной? То есть, всегда ли она возвращает одно и то же при передаче ей одних и тех же входных данных? Проверим это, воспользовавшись тем, что в вышеприведённом фрагменте кода мы вызывали эту функцию несколько раз:
Выглядит всё это хорошо, но функция returnZeroFunc() пока не вполне чиста. Она ссылается на переменную, находящуюся за пределами её собственной области видимости. Для того чтобы эту проблему решить, перепишем функцию:
Теперь функцию можно признать чистой. Однако в данной ситуации правила JavaScript играют против нас. А именно, мы больше не можем использовать оператор === для проверки ссылочной прозрачности функции. Происходит это из-за того, что returnZeroFunc() всегда будет возвращать новую ссылку на функцию. Правда, ссылочную прозрачность можно проверить, изучив код самостоятельно. Такой анализ покажет, что при каждом вызове функции она возвращает ссылку на одну и ту же функцию.
Перед нами — маленькая аккуратная лазейка. Но можно ли использовать её в реальных проектах? Ответ на этот вопрос положителен. Однако прежде чем поговорить о том, как пользоваться этим на практике, немного разовьём нашу идею. А именно, вернёмся к опасной функции fZero() :
Попытаемся воспользоваться тем нулём, который возвращает эта функция, но сделаем это так, чтобы (пока) ядерную войну не начинать. Для этого создадим функцию, которая берёт тот ноль, который возвращает функция fZero() и добавляет к нему единицу:
Вот незадача… Мы случайно начали ядерную войну. Попробуем снова, но в этот раз не будем возвращать число. Вместо этого вернём функцию, которая, когда-нибудь, возвратит число:
Теперь можно вздохнуть спокойно. Катастрофа предотвращена. Продолжим исследования. Благодаря этим двум функциям мы можем создать целую кучу «возможных чисел»:
Видите, что мы тут сделали? С «возможными числами» можно делать то же самое, что и с обычными числами. Математики называют это изоморфизмом. Обычное число всегда можно превратить в «возможное число», поместив его в функцию. Получить «возможное число» можно, вызвав функцию. Другими словами, у нас имеется маппинг между обычными числами и «возможными числами». Это, на самом деле, гораздо интереснее, чем может показаться. Скоро мы вернёмся к данной идее.
Вышеописанный приём с использованием функции-обёртки — это допустимая стратегия. Мы можем скрываться за функциями столько, сколько нужно. И, так как мы пока не вызывали ни одной из этих функций, все они, теоретически, являются чистыми. И войну никто не начинает. В обычном коде (не связанном с ракетами) нам, на самом деле, в итоге нужны побочные эффекты. Оборачивание всего, что нужно, в функции, позволяет нам с точностью контролировать эти эффекты. Мы сами выбираем время появления этих эффектов.
Функтор Effect
Теперь опишем функцию-конструктор для создания объектов типа Effect :
Так… Сейчас у нас нет возможности наблюдать за тем, что тут произошло. Поэтому давайте модифицируем Effect для того, чтобы, так сказать, получить возможность «спускать курок»:
Если будет нужно, мы можем продолжать вызывать функцию map() :
Вот здесь происходящее уже начинает становиться интереснее. Мы называем это «функтором». Всё это означает, что у объекта Effect есть функция map() и он подчиняется некоторым правилам. Однако это не такие правила, которые что-либо запрещают. Эти правила посвящены тому, что можно делать. Они больше похожи на привилегии. Так как объект Effect — это функтор, он подчиняется этим правилам. В частности это — так называемое «правило композиции».
Другими словами, два выполненных подряд метода map() эквивалентны композиции двух функций. Это означает, что объект типа Effect может выполнять действия, подобные следующему (вспомните один из вышеприведённых примеров):
Теперь предлагаю прекратить эксперименты с числами и поговорить о том, что больше похоже на код, используемый в реальных проектах.
▍Метод of()
Для того чтобы продемонстрировать ситуацию, в которой может пригодиться подобный метод, представим, что мы работаем над веб-приложением. У этого приложения есть некие стандартные возможности, скажем, оно может выводить список статей и сведения о пользователе. Однако расположение этих элементов в HTML-коде у разных пользователей нашего приложения различается. Так как мы привыкли принимать продуманные решения, мы решили хранить сведения о расположении элементов в глобальном конфигурационном объекте. Благодаря этому мы всегда сможем к ним обратиться. Например:
▍Создание структур из вложенных объектов Effect и раскрытие вложенных структур
Теперь, если нам нужно всё это объединить, мы можем воспользоваться функцией map() :
Хотя и это — тоже не вполне корректно. Скорее это будет выглядеть так:
Если раскрыть это выражение, то получится следующее:
Обратите внимание на то, что весь код, который выполняет реальные действия, находится в самой глубоко вложенной функции. Во внешний объект Effect он не попадает.
▍Метод join()
Эту функцию мы можем использовать для того, чтобы извлечь из вложенной конструкции элемент со сведениями о пользователе:
▍Метод chain()
Мы назвали эту новую функцию chain() из-за того, что она позволяет объединять операции, выполняемые над объектами Effect (на самом деле, мы так назвали её ещё и потому что стандарт предписывает называть подобную функцию именно так). Теперь наш код для получения внутреннего HTML-кода блока со сведениями о пользователе будет выглядеть так:
▍Комбинация объектов Effect
Пока всё выглядит нормально. Теперь давайте получим нужные данные:
Происходящее станет понятнее, если взглянуть на типы. Сигнатура типа для метода map() выглядит примерно так:
Вот сигнатура функции для работы с шаблонами:
Вышеприведённый пример с использованием функции liftA2() можно переписать так:
Зачем это всё?
Сейчас вы можете подумать о том, что для того, чтобы избежать побочных эффектов, требуются немалые усилия. Что это меняет? У вас может возникнуть ощущение, что упаковка сущностей в объекты Effect и возня с методом ap() предусматривают выполнение слишком больших объёмов сложной работы. Зачем это всё, если обычный код и так вполне нормально работает? И понадобится ли вообще нечто подобное в реальном мире?
Позволю себе привести тут одну известную цитату Джона Хьюза из этой статьи: «Функциональный программист смотрится как средневековый монах, отвергающий удовольствия жизни в надежде, что это сделает его добродетельным».
Рассмотрим вышеозначенные замечания с двух точек зрения:
▍О важности функциональной чистоты кода
Чистые функции — это важно. Если рассмотреть маленькую функцию в изоляции, то некоторая доля конструкций в ней, не позволяющих назвать её чистой, особого значения не имеет. Написать нечто вроде const pattern = window.myAppConfig.templates[‘greeting’]; быстрее и проще, чем писать, например, так:
И если это — всё, что вы когда либо делали в программировании, то первый вариант, и правда, проще и лучше. Побочные эффекты в таком случае значения не имеют. Однако это — всего одна строка кода, находящаяся в приложении, которое может содержать тысячи или даже миллионы строк. Функциональная чистота начинает приобретать куда большее значение, когда вы пытаетесь выяснить, почему приложение таинственным образом, и, как кажется, совершенно без причин, перестаёт работать. В подобной ситуации происходит нечто неожиданное, и вы пытаетесь разбить проблему на части и изолировать её причину. Чем больше кода вы сможете исключить из рассмотрения — тем лучше. Если ваши функции являются чистыми, это позволяет вам быть уверенным в том, что на их поведение влияет только то, что им передают. И это значительно сужает диапазон возможных причин ошибки, которые вам нужно рассмотреть.
Другими словами это позволяет вам тратить меньше усилий на размышления. Это крайне важно при отладке больших и сложных приложений.
▍Паттерн Effect в реальном мире
Скажем, у вас есть некие данные. Причём этих данных у вас довольно много. Это могут быть миллионы строк в виде текстовых CSV-файлов или огромные таблицы базы данных. Вы должны эти данные обработать. Возможно, вы, используя их, обучаете нейронную сеть для построения модели логического вывода. Возможно, вы пытаетесь предсказать следующее крупное движение на рынке криптовалют. На самом деле, цель обработки больших объёмов данных может быть какой угодно. Дело тут в том, что для того, чтобы достичь этой цели, требуется выполнить огромный объём вычислений.
Для того чтобы сделать это возможным, вам нужно сначала описать вычисления, которые вы хотите выполнить. Но описывать их нужно, не выполняя реального запуска таких вычислений. Ничего не напоминает? В идеале, после того, как вы создадите подобное описание, вы передаёте его некоему фреймворку. Этот фреймворк затем позаботится о чтении информации из хранилища и о распределении задач по узлам обработки данных. Затем тот же фреймворк соберёт результаты и сообщит вам о том, что получилось после выполнения вычислений.
Именно так работает опенсорсная библиотека TensorFlow, предназначенная для выполнения высокопроизводительных численных расчётов.
Используя TensorFlow, не применяют обычные типы данных языка программирования, на котором пишут приложение. Вместо этого создают так называемые «тензоры». Скажем, если нам надо сложить два числа, то выглядеть это будет так:
Итоги
Оба рассмотренных подхода — это своего рода жульничество. И тот и другой не позволяют избавиться от конструкций, нарушающих функциональную чистоту кода. Они лишь выносят подобные конструкции, так сказать, на периферию. Но это весьма полезно. Это позволяет чётко разделять код на чистый и нечистый. Возможность подобного разделения может дать программисту реальные преимущества в ситуациях, когда ему приходится отлаживать большие и сложные приложения.
Уважаемые читатели! Пользуетесь ли вы концепциями функционального программирования в своих проектах?
JavaScript: Побочные эффекты
console.log() выводит что-то на экран, но это не возврат значения — это просто какое-то действие, которое выполняет функция.
Вывод на экран и возврат значения из функции — разные и независимые операции. Технически вывод на экран равносилен записи в файл (немного особый, но всё-таки файл). Для понимания этой темы необходимо немного разобраться в устройстве операционных систем, что крайне важно для программистов.
С точки зрения программы вывод на экран — это так называемый побочный эффект. Побочным эффектом называют действия, которые взаимодействуют с внешним окружением (средой выполнения). К таким действиям относятся любые сетевые взаимодействия, взаимодействие с файловой системой (чтение и запись файлов), вывод информации на экран, печать на принтере и так далее.
Побочные эффекты — один из основных источников проблем и ошибок в программных системах. Код с побочными эффектами сложен в тестировании и ненадежен. При этом без побочных эффектов программирование не имеет смысла. Без них было бы невозможно получить результат работы программы (записать в базу, вывести на экран, отправить по сети и так далее).
Понимание принципов работы с побочными эффектами очень сильно влияет на стиль программирования и способность строить качественные программы. Эта тема полностью раскроется в курсах на Хекслете.
Вопрос для самопроверки. Можно ли определить наличие побочных эффектов внутри функции, опираясь только на её возврат?
Задание
Это задание не связано напрямую с уроком
Советы
Определения
What are side effects, and what you can do about them
What are side effects? It’s one of those questions that gets frequently asked on Stack Overflow, around the water cooler and in interviews, but what does it mean? How do you know if your code or function has a side effect?
Functional programming has become hot topic in the JavaScript world, with large code bases making heavy use of declarative paradigm ideas, while practitioners have campaigned for wider adoption.
Functional programming is the process of building applications, composing it primarily of pure functions, avoiding shared state, mutations on data and side effects. It is declarative rather than imperative, and application state flows from one function to the next.
Functional programming goes someway towards reducing the impact of side effects in code that follows an imperative paradigm. Side effects are not only limited to state manipulation, interacting with the I/O, database, log system, APIs and anything else that can be controlled, has a side effect.
Some side effects are beneficial, and desired, such as the setTimeout() function, equivalent to sleep() and wait() in multi-threaded applications. Side effects aren’t a bad thing, but when hidden, or not otherwise obvious what’s happening, they can be dangerous.
Functional programming is not the panacea, but it is a good option, and should be combined with good application design and development practices.
A side effect is the modification of state through the invocation of a function or expression. In order for a function or expression to have a side effect, the state it modifies should be out of its local scope. Such as passing an object by reference through functions to be mutated and performing I/O operations.
The presence of side effects in code is neither a good or bad thing. They are inevitable in some cases, such as when working with languages that follow the imperative programming paradigm, or when mutating state through necessity.
In functional programming, functions are often designed to avoid side effects, with the result of most function calls being a derived value from the input parameters. The lack of side effects makes it easier to do formal verifications, and tends to lean towards an easier method of testing.
A shared state is any kind of shared state, an object, variable or memory space, that exists in a shared scope, such as closures, classes, functions and even global scopes, or as the input property being passed through functions.
The problem with shared state is by virtue its shared nature; you need to know the history of the object, shared events and other potential points of mutation and interaction.
When working with shared state, there are strategies to mitigate collisions, races and deadlocks.
Another problem with shared state is the cascading function problem, in which the order and even timing of function calls has to be changed as the state changes. This is typically a side effect of changing the order of functions calls, which causes a cascade of errors.
If we don’t call doSomehing() before our switch statement, handleSomeEvent() doesn’t even get called, and the same thing happens when the invocation of doSomething() is shifted after the switch statement.
Introducing pure functions following the functional programming paradigm helps us avoid shared state, thus avoiding issues such as cascading function errors, potential race conditions, and situations where state is stale.
In the example above, using the object spread, we’re able to copy the values of the input onto our output state, while performing the mutations to the new object that we need, rather than mutating the values of state directly. This is a common pattern in JavaScript for copying values in one object into another, such as setting default values.
An immutable object is an object that can’t be modified after creation, through manipulation of a property, or through assignment. A mutable object is an object which can be modified.
Immutability and data flow is a central concept in functional programming. In JavaScript, it’s important not to confuse the keyword const with immutability; const declares a variable that cannot be reassigned after it has been created.
However, immutable objects can still be achieved in JavaScript by using the Object.freeze, which prevents the modification of the object one-level deep, thus making it partially immutable.
Frozen objects are only superficially frozen; to achieve immutable objects, you will need to deep-freeze the object, by recursively calling Object.freeze over all properties in the object, from the deepest child and work your way up.
Thera are several libraries in JavaScript that provide trie data structure-like behaviour with immutable stores, such as immutable.js and mori.
A function (or subroutine) is considered idempotent in computer science when:
A function f() with side effects is idempotent under sequential composition f; f if, when called n-times with the same list of arguments, the nth call has no side effects, and returns the same value as the first invocation, assuming no other procedures were called.
A typical example of an idempotent function, is a function that queries a database for a customer’s name and address.
The influence of functional programming
A function is not pure and has no side effects, if the result of the invocation of the function is different each time without modifying state.
A function is both not pure and has side effects if during the invocation, it modifies state. This can be state that is passed to it as an input parameter, or state that it can access through its closure scope.
While classes colocate functionality and bound together under the namespace of the object class, functional programming tends to reuse a collection of functional utilities to process data.
Typically in functional programming, any type of data is fair game. For example, being able to use the map utility function to map over objects, strings, arrays and other data types. This is achieved by using higher-order functions, which is a function that takes a function as an argument, returns a function, or both.
JavaScript has first class functions, which allows us to treat functions as data and assign them to variables, pass them as arguments, return them from other function calls, etc.
So it’s not all bad?
So far we’ve covered what happens when a function assigns a new value to a variable, or looks like a pure function, but may not be one. Other side effects can happen when a function call invokes another function.
In multi-threaded applications, pausing a thread is a side effect. The state of the application has been modified in some way, and in some cases functions like sleep() or wait() are only useful for their side effects.
The term side effect may sound negative, but normally effect of calling a function is the very purpose of the function itself. In some way there is a side effect, be it memory or cpu utilisation, storing data to a database, creating a system log, communicating with a message bus server, etc.
Given the mathematical nature of what a function is, and how that differs in programming languages, there’s bound to be side effects in the invocation of any function, just that most of those are abstracted away from us, so that we don’t know about it.
There are instances though when following the declarative programming paradigm, that creating pure functions is a cleaner, safer and an easier way to develop. JavaScript has made great strides towards incorporating functional programming ideas into many of its languages features since ES2015, such as with the Array.* functions.
The negative aspect of side effects normally comes from cases where side effects are hidden or unknown. This is bad programming in the first place and should be avoided at all costs. Any code that produces a side effect should make it clear that it is doing so. Even Haskell, one of the most popular functional programming languages, still allowed I/O operations.
Statelessness is one approach to avoiding side effects, but that only takes into considering that state is cached and stored inside the application. Often this isn’t the case, such as with RESTful APIs, or Web UIs that don’t cache data locally.
In general, most applications will combined the declarative and imperative programming paradigms. There’s a fine balancing act between the declarative (what do to) and imperative (how to do) paradigms, with more a shift in the community towards declarative programming.
Practicing good software design principles, adopting declarative coding paradigm where necessary, and utilising immutable objects is a solid step in the right direction.