Рассказ о марте и дане на дзен

Недавно я, используя React Native, занимался разработкой мобильного приложения для медитации Atomic Meditation. Эта программа помогает тем, кто ей пользуется, выработать привычку медитировать, ежедневно уделяя этому занятию какое-то время. В ходе работы у меня появились серьёзные причины приступить к изучению TypeScript и начать пользоваться им вместо JavaScript в проектах среднего и крупного размера.

Прежде чем я начну свой рассказ, мне хотелось бы отметить, что вы сможете разобраться в этой статье, даже если никогда не пользовались React Native. Я буду всё подробно объяснять. А если вы делали какие-нибудь проекты на React, то, читая эту статью, можете считать, что React и React Native — это одно и то же.

А теперь расскажу о том, как обычный JavaScript втянул меня в неприятности.

День 1: всё идёт как надо

В React Native есть объект AsyncStorage, который представляет собой хранилище данных типа ключ/значение с асинхронным доступом к значениям по ключам. Он даёт разработчику очень простой механизм для организации постоянного хранения данных на мобильном устройстве пользователя.

Например, воспользоваться им можно так:

AsyncStorage.setItem("@key", value)

AsyncStorage позволяет хранить лишь строковые данные. Поэтому для того чтобы поместить в это хранилище число — это число сначала надо конвертировать в строку.

Ниже показано применение React-хука useState для объявления переменной sessionCount и для установки её начального значения в 0. Тут же имеется и функция setSessionCount, которая позволяет менять состояние sessionCount:

const [sessionCount, setSessionCount] = useState(0)

Предположим, пользователь завершил сеанс медитации (я, напомню, занимался разработкой приложения для медитации). В sessionCount хранится общее количество сеансов медитации, завершённых пользователем (я буду теперь называть этого пользователя «Anxious Andy» — «беспокойный Энди»). Это значит, что нам надо прибавить 1 к значению, хранящемуся в sessionCount. Для этого вызывается функция setSessionCount, в которой и выполняется прибавление 1 к предыдущему значению sessionCount. А потом количество завершённых медитаций нужно сохранить в AsyncStorage в виде строки.

Всё это надо сделать в некоей функции, которую я предлагаю назвать saveData:

// Пользователь завершил сеанс медитации…
const saveData = () => {
  setSessionCount(prev => {
    const newSessionCount = prev + 1

    AsyncStorage.setItem("@my_number", newSessionCount.toString())

    return newSessionCount
  })
}

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

День 2: затишье перед бурей

Беспокойный Энди получает уведомление, которое напоминает ему о том, что через 5 минут начинается его медитация. Но он не только беспокойный, но ещё и нетерпеливый. Поэтому он тут же идёт к себе в комнату, находит своё рабочее кресло, удобно (но при этом — сохраняя ясное сознание) в него садится и открывает программу.

Теперь, когда программа загружается, данные сессии Энди нужно прочитать из хранилища. В React хук useEffect позволяет выполнять функцию-коллбэк при монтировании компонента.

В коллбэке мы асинхронно получаем данные из хранилища, а после этого вызываем функцию setSessionCount(), передавая ей эти данные, то есть — «1»:

useEffect(() => {
  AsyncStorage.getItem("@my_number").then(data => setSessionCount(data))
}, [])

Беспокойный Энди успешно справляется с ещё одной медитацией. Поэтому к sessionCount надо добавить 1, что позволит сохранить общее число завершённых сеансов медитации.

Новое значение, как и прежде, мы записываем в хранилище:

// Пользователь завершил сеанс медитации…
const saveData = () => {
  setSessionCount(prev => {
    const newSessionCount = prev + 1

    AsyncStorage.setItem("@my_number", newSessionCount.toString())

    return newSessionCount
  })
}

К настоящему моменту пользователь завершил 2 сеанса медитации.

День 3: буря

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

Он хочет узнать о том, как далеко продвинулся в деле выработки полезной привычки. Поэтому он открывает экран статистики. «О, да тут много всего интересного», — приговаривает он. «Отличная программа!».

Но его любовь к этой программе быстро сходит на нет…

Программа сообщает ему о том, что он провёл 11 сеансов медитации. А он-то медитировал всего два раза!

Неправильная статистика по сеансам медитации

Что пошло не так?

В первый день мы записали в sessionCount начальное значение — число 0.

Пользователь завершил сеанс медитации — поэтому мы добавили к sessionCount 1. Затем мы преобразовали то, что получилось, в строку — в «1», после чего записали это в асинхронное хранилище (вспомните — оно может хранить только строковые данные).

Во второй день мы загружаем данные из хранилища и записываем в sessionCount загруженное значение. То есть — «1» (строку, а не число).

Пользователь завершает сеанс медитации и мы прибавляем к sessionCount 1. А в JavaScript «1» + 1 равняется «11», а не 2.

Мы забыли преобразовать строковые данные, считанные из хранилища, в число.

А хуже всего тут то, что наша программа при этом не выдала никаких сообщений об ошибках. Эта ошибка какое-то время оставалась незамеченной, а позже довела нас до неприятностей. Поиск источников подобных проблем может оказаться не таким уж и простым делом.

JavaScript позволил нам свободно, не сознавая того, что мы делаем, поменять в ходе выполнения программы тип данных, хранящихся в переменной.

Решить эту и другие подобные проблемы можно с помощью TypeScript.

Что такое TypeScript?

Если вы не знакомы с TypeScript, то знайте, что это, в сущности, то же самое, что и JavaScript, но оснащённое некоторыми полезными возможностями. В частности, переменные не могут менять типы. А если это случится — TypeScript выдаст сообщение об ошибке.

Браузеры не могут выполнять TypeScript-код. Поэтому TypeScript-файлы проекта надо транспилировать в JavaScript. На выходе получится несколько JavaScript-файлов (или один большой «бандл» с JS-кодом проекта).

Использование TypeScript в React Native-проектах

Добавить поддержку TypeScript в существующий React Native-проект очень просто. А именно, надо будет кое-что установить из npm и сделать пару настроек.

Теперь нужно будет лишь переименовать файлы с кодом, например — App.js в App.tsx, после чего заработает автоматическая система контроля типов.

После того, как изменено расширение файла, TypeScript разразится гневной тирадой о том, что аргумент типа 'string | null' нельзя назначить параметру типа 'SetStateAction<number>'.

TypeScript предупреждает разработчика о том, что с типами данных что-то не так

Это значит, что мне тут, чтобы избавиться от сообщения об ошибке, надо, во-первых, проверить data на null, а во-вторых — преобразовать из строки в число (воспользовавшись parseInt()):

useEffect(() => {
  AsyncStorage.getItem("@my_number").then(data => {
    if (data) {
      setSessionCount(parseInt(data))
    }
  })
}, [])

Использование TypeScript подталкивает разработчика к написанию более качественного и надёжного кода. Это просто замечательно!

По каким материалам изучать TypeScript?

Я изучал TypeScript по этому видеокурсу канала Net Ninja. И если бы мне надо было бы что-нибудь изучить, то я в первую очередь поинтересовался бы тем, нет ли на этом канале курса по тому, что мне нужно.

Кроме того, официальная документация по TypeScript очень даже хороша.

Итоги

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

Да, не могу не отметить, что JavaScript хорошо подходит для маленьких проектов. Но при работе над средними и большими проектами, а так же — над маленькими проектами, которые вполне могут вырасти, лучше, пожалуй, прибегнуть к TypeScript, даже если для этого придётся потратить время на его изучение. А если вы знаете JavaScript, то и TypeScript освоите без особого труда.

Используете ли вы TypeScript в своих React-проектах?

TeaOwl
16 декабря 2021 в 12:00

Можно ли регулировать использование языка авторскими правами? Это рассказ о доступности информации и искусственном языке аборигенов Тасмании, восстановленном исследователями из мёртвых языков этого региона. Знакомьтесь, палава кани (palawa kani, «говорят тасманийские аборигены»).

Этот язык разработан и развивается Центром аборигенов Тасмании (ТАС), про него достаточно материалов на английском, есть несколько статей в рунете. Но есть одна вещь, про которую у нас в рунете почему-то не упоминают: сотрудники Центра ограничивают свободное использование языка авторскими правами для всех, кроме аборигенов Тасмании. Именно так, необходимо получить письменное разрешение в Центре для использования языка. Не знаю, почему, но вспоминаются классические произведения в жанре антиутопии, но об этом чуть позже.

▍ Разработка языка

Язык палава кани входит в базу языков австралийских аборигенов AUSTLANG, хотя никогда не являлся родным для какого-либо из коренных народов региона.

Разработка языка началась в 1992 году в рамках общенациональной Программы восстановления языков коренных народов Австралии. Первоначально планировалась совместная работа общины аборигенов Тасмании, Университета Тасмании и ТАС, но в итоге ТАС взяли взяли работу и управление проектом на себя. В рамках получения финансирования ТАС были заявлены следующие цели: «возрождение, запись, сохранение и продвижение языков аборигенов Тасмании, продвижение возрождённого языка палава кани».

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

Как пишут на сайте ТАС, от оригинальных тасманийских языков до нас дошли только короткие записи разговоров и традиционные песни. Первоначально на Тасмании использовалось по разным оценкам от 8 до 16 языков, точное количество мы уже не узнаем.

Одна из возможных классификаций языков Тасмании

К счастью, сохранились записи списков слов и заметок о языках более чем двадцати европейских исследователей начиная с XVIII века (шотландцы, датчане, французы). Каждый из них пытался воспроизвести незнакомые звуки, которые они слышали в словах аборигенов. Естественно, получались разные записи, а порой и по несколько вариантов от одного исследователя. Некоторые источники вызывают сомнения. Всё это вместе с сильной нехваткой информации приводит к путанице в правильном произношении слов, значении и их происхождении. Сохранившейся информации недостаточно, чтобы полностью восстановить хотя бы один язык. Также ТАС удалось проанализировать и собрать более двухсот слов, фраз и фрагментов песен из воспоминаний более чем тридцати аборигенов на протяжении XX века.

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

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

Реконструкция — это лингвистический термин, обозначающий стандартный процесс, используемый во всём мире для восстановления языков, на которых больше не говорят; большинство из них — языки коренных народов. К сожалению, этот термин слишком легко неправильно понять или умышленно неверно истолковать. Это не означает «конструировать» язык или «создавать» его — в смысле просто выдумывать какие-то вещи без каких-либо доказательств или случайным образом выбирать европейские варианты написания из списков слов и заявлять, что эти слова являются «языком». Напротив, это строгий процесс, с помощью которого лингвисты восстанавливают исходные звуки и значения слов языка из всех записанных версий слов.
…
Однако палава кани — не совсем то же самое, что любой из оригинальных языков тасманийских аборигенов… Остатков каждого из языков оказалось недостаточно, чтобы возродить какой-либо из них, но из их всех записей можно составить один язык. Семьи выживших…, где бы они ни жили сейчас по всей Тасмании, объединились в одну общину аборигенов штата. Язык, который помнят в семьях с островов Бассова пролива, также показывает, что «смесь» слов из нескольких первоначальных языков использовалась по крайней мере с начала «миссии» Робинсона и затем в течение всего периода Вибаленны (Wybalenna period).

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

▍ Устройство языка

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

pama — 1, paya — 2, luwa — 3, wulya — 4, mara — 5, nana — 6, tura — 7, pula — 8, tali — 9, kati — 10, pamakati — 11, payakati — 12, luwakati — 13, payaka — 20, luwaka — 30, wulyaka — 40, pamaki — 100, payaki — 200, luwaki — 300, pamaku — 1000, taliku — 9000.

kipli — есть, krakapaka — умирать, laykara — бежать, liyini — петь, mulaka — охотиться, takara — гулять, tunapri — понимать, запоминать, yangina — плавать, kanaplila — танцевать.

▍ Культурный артефакт

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

Так сложилось, что этот язык служит не столько средством общения, сколько сознательно созданным культурным артефактом, служащим для укрепления социального статуса и аутентичности аборигенов. Роль языка можно рассматривать в контексте мифопоэтики аборигенов Австралии. Аборигены Тасмании являются одновременно и сообществом постколониальным, и восстановленным после исчезновения. Они пытаются реализовать личную и общинную привязанность к прошлому через культурную артикуляцию. «Культуру» следует понимать как конструкцию, но без примеси фальсификации. Культура — это «важнейший инструмент для создания других» (Л. Абу-Лагод), и её сознательное воссоздание в Тасмании носит личный и политический характер. Однако такое восстановление культуры не всегда встречает всеобщее признание. Более того, составные или реконструированные языки вызывают дополнительный скептицизм по сравнению с более «осязаемыми» культурными компонентами, как изделия народных промыслов.

Топонимы на языке палава кани признаются правительством штата как официальные альтернативные названия географических объектов, аналогичные по статусу названиям на сохранившихся до сих пор естественных языках других народов Австралии. Так, река Теймар носит название Kanamaluka, а гора Веллингтон — Kunanyi.

Язык использовали в съёмках фильма «Соловей». На Медузе есть подробная рецензия на фильм.

▍ Авторские права

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

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

Все географические названия палава кани находятся в свободном доступе для общественного пользования.

Ни одному аборигену Тасмании нет необходимости запрашивать разрешение на использование языка аборигенов Тасмании в своих целях.

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

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

Заявки рассматриваются в каждом конкретном случае. Утверждение будет зависеть от контекста предлагаемого использования и его соответствия ценностям аборигенов.

Как относиться к такой политике ТАС касательно языка? Не знаю, у каждого будет своё мнение на этот счёт. Согласно международному праву, нельзя ограничить язык авторскими правами. Пока что.

P.S. Автор интересуется искусственными языками исключительно в качестве хобби. Ни на какую объективную истину этот материал не претендует. Куда лучше ознакомиться с источниками. Буду благодарен любым исправлениям и уточнениям от разбирающихся в теме людей.

▍ Источники

1. Breathing new life into Indigenous language
2. Christopher D. Berk. Palawa Kani and the Value of Language in Aboriginal Tasmania
3. Tasmanian Aboriginal Centre
4. Policy and Protocol for Use of palawa kani Aboriginal Language, 2019
5. Respecting cultures. An initiative of Arts Tasmania’s Aboriginal Arts Advisory Committee
6. Палава-кани (википедия)
7. Palawa kani (википедия)
8. Explainer: how Tasmania’s Aboriginal people reclaimed a language, palawa kani
9. The Tasmanians. Part 6: The Tasmanian Languages

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

Асинхронность означает возможность написания кода, который не подвержен обычным проблемам, связанным с потокобезопасностью, и поддерживает выполнение множества задач в «параллельном» режиме. Например — ожидание считывания файла не блокирует другие вычисления.

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

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

Эти соединения что-то захватывало.

Речь идёт о кодовой базе в миллионы строк кода, которой в течение нескольких лет занимались десятки программистов. Может — проблема заключается в неразрешённых промисах? Я решил исследовать этот вопрос.

Проблема останова поднимает голову

Поиск неразрешённых промисов — это пример попытки решения проблемы останова, а известно, что не существует общего алгоритма решения этой проблемы.

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

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

Типичное решение проблемы останова заключается в том, чтобы добавить в систему временные ограничения. Если функция не завершает работу в пределах N секунд — мы считаем, что она где-то застопорилась. Может, это и не так, но мы решаем, что это так, и «убиваем» программу.

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

Но «убийство» процесса сервера при каждом недоразумении — это решение не идеальное. И, кроме того, оснащение каждого промиса в кодовой базе тайм-аутом — это, в лучшем случае, очень сложно.

Но не так всё плохо! Проблему останова можно решить для подмножества распространённых паттернов.

Паттерны проблемных промисов

В прочитанной мной публикации «Нахождение проблемных промисов в асинхронных JavaScript-программах» Алимадади с соавторами выделили распространённые паттерны, которые приводят к появлению неразрешённых промисов, и представили программу PromiseKeeper. Эта программа находит потенциально неразрешаемые промисы с использованием графа промисов.

▍Краткий рассказ о JavaScript-промисах

Та публикация начинается с обзора JavaScript-промисов.

Промисы представляют асинхронные вычисления и могут пребывать в трёх состояниях: pending (ожидание), fulfilled (успешное разрешение) и rejected (отклонение). Вначале они оказываются в состоянии pending.

Код, реагирующий на результат работы промиса (обработчик определённого события), регистрируют с помощью метода .then().

// Немедленно разрешается со значением 17
const promise = Promise.resolve(17)
promise.then(
  function fulfilledReaction(value) {
    console.log({ value })
  },
  function rejectedReaction(error) {
    console.log({ error })
    throw error
  }
)

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

// Немедленно разрешается со значением 17
const promise = Promise.resolve(17)
promise.then(value => value + 1)
       .then(value => value + 1)
       .then(function (value) => { console.log(value) })

Каждый вызов .then() приводит к созданию нового промиса, который разрешается возвращаемым значением кода, реагирующего на завершение работы предыдущего промиса. Обратите внимание на то, что последний вызов неявно разрешается со значением undefined. Дело в том, что в JavaScript функция, которая не возвращает что-либо, неявным образом возвращает undefined.

Важная деталь.

В цепочку промисов можно добавить механизм обработки ошибок с использованием .catch():

// Немедленно разрешается со значением 17
const promise = Promise.resolve(17)
promise.then( ... )
       .then( ... )
       .then( ... )
       .catch(err => ...)

Каждый промис, созданный .then(), неявно определяет код, реагирующий на отклонение промиса, аналогичный конструкции err => throw err. Это значит, что .catch() в конце цепочки промисов может отреагировать на ошибки, возникшие в любом из предыдущих промисов.

На практике редко полагаются на стандартный механизм обработки успешно разрешённых промисов, но следующий код корректен:

// Немедленно разрешается со значением 17
const promise = Promise.resolve(17)
promise
  .then(undefined) // используется стандартный механизм value => value
  .then((value) => console.log(value))

Полагаю, подобное чаще происходит случайно, чем намеренно.

Промисы можно связывать, используя один промис для разрешения другого промиса:

const p0 = Promise.resolve(17) // Немедленно разрешается
const p1 = Promise.reject("foo") // Немедленно отклоняется
p0.then(function (v) {
  return p1
})

Здесь состояние промиса p0 связано с p1. То есть — неименованный промис, созданный в строке 3, отклоняется со значением foo.

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

▍Паттерн №1: необработанное отклонение промиса

Обычным источником ошибок при работе с промисами являются необработанные отклонения промисов.

Это происходит, когда неявно отклоняют промис, выдавая ошибку в коде, реагирующем на успешное завершение промиса:

promise.then(function (val) {
  if (val > 5) {
    console.log(val)
  } else {
    throw new Error("Small val")
  }
})

Так как код, реагирующий на успешное завершение промиса, выполняется в отдельном асинхронном контексте, JavaScript не передаёт эту ошибку в главный поток. Ошибка «проглатывается» и разработчик никогда не узнает о том, что она произошла.

Исправить это можно, использовав метод .catch():

promise
  .then(function (val) {
    if (val > 5) {
      console.log(val)
    } else {
      throw new Error("Small val")
    }
  })
  .catch((err) => console.log(err))

Теперь у нас появляется возможность обработать ошибку.

Но мы не перевыбросили эту ошибку! Если другой промис, связанный с этим, или объединённый с ним в цепочку, полагается на этот код, ошибка будет оставаться «проглоченной». Код продолжит выполняться.

Попробуйте следующее в консоли браузера:

const p = Promise.resolve(17)
p.then(function (val) {
  throw new Error("Oops")
  return val + 1
})
  .catch(function (err) {
    console.log(err)
  })
  .then(function (val) {
    console.log(val + 1) // prints NaN
  })

Можно ожидать, что в этом коде выполняются вычисления 17 + 1 = 18, но, из-за неожиданной ошибки, мы получаем NaN. Промис, неявно созданный .catch(), неявно разрешается (а не отклоняется) со значением undefined.

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

▍Паттерн №2: незавершённые промисы

Новые промисы пребывают в состоянии pending до тех пор, пока не будут успешно разрешены или отклонены (то есть — завершены). Но если промис не завершается, его можно назвать остановившимся промисом. Он навсегда останется в состоянии pending, не давая выполняться коду, полагающемуся на его завершение.

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

Авторы вышеупомянутой публикации показывают пример проблемы из node-promise-mysql, где connection.release() возвращает промис, который никогда не разрешается.

Этот пример сложно свести к нескольким строкам кода, поэтому вот — кое-что попроще:

const p0 = new Promise((resolve, reject) => null)
const p1 = Promise.resolve(17)
p0.then((result) => p1)
  .then((value) => value + 1)
  .then((value) => console.log(value)) // ожидается 18

Последний промис соединён цепочкой из .then() с промисом p0, который никогда не разрешается и не отклоняется. Этот код может выполняться вечно, но он никогда не выведет никакого значения.

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

▍Паттерн №3: неявные возвраты и код, реагирующий на результаты работы промиса

Цепочка из промисов прерывается без выдачи каких-либо ошибок в том случае, если разработчик забывает о включении в код выражения return.

Эта проблема похожа на ту, связанную с «проглатыванием» ошибок, о которой я уже рассказывал. Вот фрагмент кода из Google Assistant, который приводят Алимадади с соавторами:

handleRequest (handler) {
    if (typeof handler === 'function') {
        const promise = handler(this)
        if (promise instanceof Promise) {
            promise.then(result => {
                debug(result)
                return result
            }).catch(reason => {
                this.handleError('function failed')
                this.tell(!reason.message ? ERROR_MESSAGE : reason.message)
                return reason
            })
        }
    }
}

Метод handleRequest() использует объект Map с обработчиками, предоставленными разработчиком, для организации асинхронной работы с запросами Assistant. Объект handler (обработчик) может быть либо коллбэком, либо промисом.

Если промис разрешается и вызывает предоставленный ему программистом анонимный обработчик, код возвращает результат. Если промис оказывается отклонённым — код возвращает причину этого.

Но все эти возвраты выполняются внутри кода, реагирующего на разрешение или отклонение промиса. Промис не осуществляет возврата значения. Результат реакции на промис handler теряется.

Пользователь этой библиотеки не может обработать результат разрешения или отклонения промисов, возвращённых его собственными обработчиками.

Поиск антипаттернов с помощью графа промисов

Алимадади с соавторами создали программу PromiseKeeper, которая динамически анализирует кодовую базу на JavaScript и рисует графы промисов.

Граф промисов

Мне не удалось запустить эту программу, поэтому передам то, о чём рассказали авторы публикации.

▍Графы промисов

Асинхронный код можно представить в виде графа, вершины которого (промисы, функции, значения, механизмы синхронизации) соединены рёбрами (разрешение промиса, регистрация обработчиков, связь, return или throw).

• Вершины-промисы (p) представляют собой случаи запуска промисов.
• Вершины-значения (v) представляют значения, с которыми разрешаются или отклоняются промисы. Это могут быть функции.
• Вершины-функции (f) — это функции, зарегистрированные для обработки разрешения или отклонения промиса.
• Вершины-механизмы синхронизации (s) представляют собой все использованные в коде вызовы Promise.all() или Promise.race().
• Рёбра разрешения или отклонения промиса (v)->(p) указывают на связи вершин-значений с вершинами-промисами. Они помечены как resolve или reject.
• Рёбра регистрации обработчиков (p)->(f) указывают на связи между промисом и функцией. Они помечены как onResolve или onReject.
• Рёбра связей (p1)->(p2) показывают взаимоотношения между связанными промисами.
• Рёбра return или throw (f)->(v) показывают связи функций и значений. Они помечены как return или throw.
• Рёбра механизмов синхронизации указывают на связи, идущие от множества промисов к одному механизму синхронизации промисов. Они помечаются как resolved, rejected или pending на основании того, как ведёт себя новый промис.

Вот аннотированная версия вышеприведённого графа.

Аннотированный граф промисов

▍Использование PromiseKeeper для поиска анти-паттернов

Программа PromiseKeeper направлена на конструирование и визуализацию графа промисов кода. Она анализирует код динамически, по мере выполнения тестов. Динамический контекст выполнения кода позволяет находить анти-паттерны, которые не видны при анализе самого кода.

Вот на какие анти-паттерны обращает внимание программа:

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

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

Реализация PromiseKeeper основана на фреймворке для динамического анализа JavaScript-кода Jalangi. В нём имеются коллбэки, которые реагируют на события жизненного цикла промисов.

Мне не удалось заставить работать PromiseKeeper на моём компьютере, но Алимадади с соавторами сообщают о том, что не вполне благополучные промисы встречаются почти во всех кодовых базах, в которых используется JavaScript.

Отчёт по выявленным анти-паттернам

Интересно то, что 1012 экземпляров незавершённых промисов встречаются всего в 17 местах кода Node Fetch.

Авторы сообщили, что в ходе их эксперимента 43% промисов оказались неразрешёнными. Это, вероятнее всего, указывает на неполноту тестов, а не на то, что популярные программные продукты, которые они исследовали, безнадёжно «поломаны».

Что делать?

Для того чтобы улучшить работу с промисами в своих проектах, стоит помнить об анти-паттернах и постараться не писать код, который изначально является некачественным. Применение async/await снижает вероятность появления в коде рассмотренных здесь анти-паттернов.

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

// Выводит полезное сообщение об ошибке когда
// отклонение промиса оказывается необработанным
process.on("unhandledRejection", (err, promise) => {
  const stack = err instanceof Error ? err.stack : ""
  const message = err instanceof Error ? err.message : err

  Logger.error("Unhandled promise rejection", {
    message,
    stack,
    promise,
  })
})

Ещё можно попробовать Node.js-модуль async_hooks, который позволяет наблюдать за жизненным циклом промисов, и попытаться выявлять промисы, которые выполняются слишком долго. Можно, например, сравнивать время работы промиса с заданным тайм-аутом и выводить в консоль предупреждение.

У меня была интересная попытка использования async_hooks для выявления промисов, выполняющихся слишком долго, но особого толку из этого не вышло. Нельзя получить ссылку на контекст выполнения (только — C-указатель). То есть — можно увидеть, что что-то работает медленно, но о том, что это такое, узнать нельзя.

Меня привлекает идея превращения PromiseKeeper в нечто вроде плагина для Jest. Представьте себе, что после каждого запуска тестов формируется граф промисов, вроде того, который вы здесь видели.

Сталкивались ли вы с проблемами, вызванными неправильной работой промисов?