Пришло время обсудить обработку ошибок 🔥🧨🎆🌋☄️🌡️
Я еще в начале недели кидал ссылку в которой описаны некоторые идеи: github.com/artalar/state-…
Еще вы можете послушать об этом в сегодняшнем выпуске @5minreact: soundcloud.com/5minreact/062-…
Вернемся к нашей корзине с товарами и подумаем где могут возникнуть ошибки при работе стейт-менеджера (СТМ) и что с ними нужно в этом случае делать:
1, 2) при работе с данными
3) при вызове сайд-эффектов
Для каждого пункта, при ошибке, возникают вопросы:
- продолжать ли вызывать сущности текущего уровня?
- следует ли переходить на следующий уровень?
Причем чем раньше возникла ошибка, тем больше вероятность того что может возникнуть еще одна ошибка, повышая вариативность...
Ну т.е. все сложно...
Вообще лучше всего когда в СТМ по умолчанию заложена такая логика обработки ошибок, которая наименьшим образом сможет создать сайд-эффект для пользовательского кода, т.е. это стремление к идемпотентности - ru.wikipedia.org/wiki/Идемпотен…
Что такое сайд-эффект? Это какой-то эффект, который находится в стороне, в не ореола нашего контроля. Сайд-эффект - это выход из зоны ответственности, порождение хаоса, чего-то безконтрольного, непредсказуемого... Звучит не очень для конечного продукта, который приносит деньги?
На самом деле, с точки зрения разработчика, сайд-эффектов в приложении может вообще не быть, потому что в его руках находится контроль над всем приложением.
Но нам необходимо рассмотреть зону ответственности СТМ, который, конечно, вообще ничего не знает про свое окружение и в каком он там приложении и как используется. Область ответственности СТМ достаточно скромна: обновить данные, вызвать подписчиков.
Соответственно какое есть влияние у СТМ на окружающую среду (я не про патчинг протатипов 😁)? - Состояние и подписчики.
Когда разработчик проектирует какую-то логику он ожидает что при определенном изменении состояния вызовутся определенные подписчики - так работает СТМ.
Причем в реальном приложении связей "изменение - вызов подписчика" так много, что проконтролировать каждое и, возвращаясь к теме треда, обработать каждое возможное исключение - нереально! Потому что исключение может наступить в случайной часте связи и это комбинаторный взрыв!
В итоге, СТМ имеет возможность внести непредсказуемое поведение в приложение двумя способами: изменить состояние не полностью (ошибка в 1, 2), вызвать не всех подписчиков (ошибка в 3).
Что бы избежать неконсистентности данных для иммутабельной модели - необходимо использовать rollback'и, либо использовать иммутабельную модель данных - но и это не панацея.
У протестированных мной СТМ: redux, MobX, effector есть одна и та же проблема - возможны ситуации когда состояние измениться лишь частично. И это точно является не верным поведением: en.wikipedia.org/wiki/Atomicity…
Reatom задизайнен так, что там никогда не произойдет частичного изменения состояния: либо полное изменение соответствующее подпискам на апдейт (экшен), либо никакого (throw).
Хотя, справедливости ради, в селекторах useAtom (react) это не гарантируется из-за zombie children.
При этом, подчеркиваю, я описал необходимое поведение по умолчанию. В идеале библиотека должна так же предоставлять какие-то средства обработки ошибок. В том же effector что-то такое есть. В Reatom этого нет, что бы не создавалась иллюзия полного контроля - спорный вопрос 🤷♂️.
Выводы такие: стейт-менеджемент - это сложно, имеется множество подводных камней (мы разобрали только часть) с которыми можно никогда не столкнуться или столкнуться в самый неподходящий момент. Изучайте ваши инструменты лучше и требуйте этого от разработчиков (документация).