Error handling in components

Обработка ошибок в компонентах

Автоматическая

Каждый компонент оборачивается в try/catch и показывает заглушку в случае ошибки.

Плюсы:

• автоматизация
• гранулярность
• единый вид

Минусы:

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

Например, вместо лицензионного соглашения о продаже души дъяволу, пользователь, при покупке курса успешного успеха, увидит заглушку, при этом сможет кликнуть галочку - "согласен".

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

Ручная

Программист вручную заворачивает в try/catch некоторые компоненты.

Плюсы:

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

Минусы:

• Дефолтность, если что-то не обработано - оно фейлит все дерево
• Не определить важность сломанной детали для фичи, например, в форме оплаты может повалиться как инпут цены, так и рекламный баннер. В форме фоловера твиттера, где есть имя и кнопка follow, при отвале кнопки, скрывать всю форму - не fault tolerance, хоть и обратная ситуация выглядит логичнее, однако это вскрывает в данном случае несовершенство самого подхода try/catch фичи.
• Не всегда надо решать за пользователя. В случае отображения информации, лучше, если повалится какой-то один график или карточка, чем вся страница или выдача.
• Трудоемкость. Т.к. надо приложить усилия, что б правильно выделить компоненты-фичи, обернуть их в try/catch, таких компонент может быть много. Часто ошибки вообще не обрабатывают, а пользователь видит белую страницу или "что-то пошло не так".

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

broken UI

Когда ui "сломается" - пользователь увидит неконсистентные данные. На мысль об этом наводят термины wrong, broken, inconsistent state в вышеприведенной статье. Реакт это система с push-реактивностью, в ней могут возникать такие ситуации. Однако, в системах с pull-реактивностью, к которой принадлежит mol, все зависимые начнуть кидать ошибку, даже если одна деталь сфейлится и восстановятся, когда деталь перестанет кидать ошибку.

Неконсистентного состояния не может быть, это разобрано в статье про реактивность.

different elements have different layout requirements

В реакте заглушка в ErrorBoundary никак не связанна с контентом, который должен отображаться вместо нее. В mol же у любого компонента всегда есть дефолтный width и height, который подбирается сообразно предполагаемым размерам компонента с контентом. Поэтому, при ошибке на первом рендере, layout либо не изменится, либо изменится не сильно. При ошибке на последующих рендерах, будет взята старая версия контента и на нее наложена бленда с ошибкой (в реакте тоже такой паттерн можно реализовать). Даже для маленьких кнопок такой подход работает.

performance penalty

try/catch в компоненте, ресурсов потребляет мало, жаль только для ErrorBoundary в реакте это не так.

We debated this decision, but in our experience it is worse to leave corrupted UI in place than to completely remove it

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

Вывод

Тут важно иметь ввиду:

• каких случаев больше
• какое мы хотим поведение по умолчанию

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

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