Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

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

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

3 <h2>Содержание</h2>

4 <ul><li><a>Про isLoading</a></li>

5 <li><a>Конечный автомат</a></li>

6 <li><a>Вывод</a></li>

7 </ul><h2>Про isLoading</h2>

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

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

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

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

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

13 <ol><li>Убедиться, что приложение всегда показывает местоположение и ошибку.</li>

14 <li>Очистить поле error, если данные о геопозиция получены успешно, или очистить поле position, когда произошла ошибка.</li>

15 <li>Вернуть дополнительное свойство, которое определяет текущий статус информации о геопозиции.</li>

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

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

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

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

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

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

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

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

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

25 <h2>Конечный автомат</h2>

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

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

28 <blockquote><h3>Читайте также:</h3>

29 Как спроектировать<a>правильный конечный автомат</a>на REST

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

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

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

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

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

35 <h2>Вывод</h2>

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