Почему не стоит использовать логические значения isLoading в своем коде
2026-02-26 22:25 Diff
https://ru.hexlet.io/blog/posts/no-isloading

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

Это адаптированный перевод статьи Stop using isLoading boolean Кента Додса, JS-разработчика и преподавателя программирования. Повествование ведётся от лица автора оригинала.

Содержание

Про isLoading

isLoading (и подобные ему выражения: isRejected, isIdle, isResolved и другие) создают больше проблем, чем решают. Продемонстрирую это на примере эксперимента с API геолокации. Весь код ниже написан на React, но его можно адаптировать к любому фреймворку или языку.

Это классический пример использования логических значений в API геолокации — его используют многие разработчики приложений, которые пишут на JS и других языках. У этого кода есть проблема:

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

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

Есть несколько решений этой проблемы:

  1. Убедиться, что приложение всегда показывает местоположение и ошибку.
  2. Очистить поле error, если данные о геопозиция получены успешно, или очистить поле position, когда произошла ошибка.
  3. Вернуть дополнительное свойство, которое определяет текущий статус информации о геопозиции.

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

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

Остается третий вариант. Попробуем реализовать его:

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

Теперь вместо логических значений мы используем переменную status:

Использование переменной status вместо isLoading помогает точно узнать, в каком состоянии находится процесс определения геолокации в любой момент времени.

Если вы хотите избавиться от выражений вида variable === 'string' в if, сделайте следующее:

Здесь возникает пространство для дискуссий — переменные можно хранить в состоянии редьюсера, а не выводить их значения. Однако такой подход делает код уязвимым для невыполнимых состояний.

Если вы действительно хотите, чтобы вашим пользователям не приходилось использовать variable === 'string', убедитесь, что вы придерживаетесь status в своем состоянии. Это поможет гарантировать, что существует только одно возможное значение конечного состояния. После этого вы можете выводить логические состояния:

Конечный автомат

XState — это удобная библиотека для реализации конечных автоматов в коде. Посмотрим, как она работает на реальном примере:

Если вы не знакомы с конечным автоматом или с библиотекой XState, возможно, код в этом разделе покажется вам сложным. Любая абстракция становится понятнее со временем, если уделять ей достаточно внимания.

Читайте также:

Как спроектировать правильный конечный автомат на REST

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

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

Вот как мы будем это использовать:

Если вам понравился API выше, вы можете сохранить себе и этот:

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

Вывод

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