Какие заметки я сделал, описывая связанные AJAX запросы через State Machine

В качестве библиотеки использовал https://github.com/jakesgordon/javascript-state-machine

  1. Типизирвать javascript-state-machine (далее SM) сложно потому что методы SM генерируются налету из названий состояний. Т.е. мне бы пришлось вручную поддерживать конфигурацию SM и интерфейса.
  2. Нужно внимательно обращать внимание на какую стадию состояния (state) или перехода (transition) приходится мутация основого стора приложения.
  3. Изнутри перехода или lifecycle коллбека нельзя вызвать другой переход. Пришлось добавлять таймауты. Я так понял что авторы библиотеки не ожидали что SM будет управляться изнутри себя.
  4. Можно визуализировать мою SM. И это очень удобно. Нашел проблему таким образом. Моя SM выглядит так. Суть в том что запрашивается coreData и на основании ее результатов подгружается еще данные. При этом многое может пойти не так (coreData запрос отменится, или новый пока выполняется запрос за дополнительными данными. Плюс в будущем будут добавляться запросы за дополнительными данными).
  5. Отладка удобна потому что в единый момент времени нужно думать только о нескольких переходах и состояниях.
  6. Кода получается намного больше чем писать “влоб”. Но этот код более контролируем.
  7. Начинаешь думать о проблеме в терминах SM. Иногда проще влепить условие вместо того чтобы разобраться почему SM не в том состоянии в котором ождаешь.
  8. Отражать состояние SM в store для отображения на UI - одно удовольствие.

В посте где я спрашивал про опыт с SM мне пару человек порекомендовали RXJS для моей задачи. Было бы интересно увидеть ваше решение на RXJS чтобы сравнить наш код.


Статья в рамках рубрики “Today I Learned