В качестве библиотеки использовал https://github.com/jakesgordon/javascript-state-machine
- Типизирвать
javascript-state-machine
(далееSM
) сложно потому что методы SM генерируются налету из названий состояний. Т.е. мне бы пришлось вручную поддерживать конфигурацию SM и интерфейса. - Нужно внимательно обращать внимание на какую стадию состояния (state) или перехода (transition) приходится мутация основого стора приложения.
- Изнутри перехода или lifecycle коллбека нельзя вызвать другой переход. Пришлось добавлять таймауты. Я так понял что авторы библиотеки не ожидали что SM будет управляться изнутри себя.
- Можно визуализировать мою SM. И это очень удобно. Нашел проблему таким образом. Моя SM выглядит так. Суть в том что запрашивается coreData и на основании ее результатов подгружается еще данные. При этом многое может пойти не так (coreData запрос отменится, или новый пока выполняется запрос за дополнительными данными. Плюс в будущем будут добавляться запросы за дополнительными данными).
- Отладка удобна потому что в единый момент времени нужно думать только о нескольких переходах и состояниях.
- Кода получается намного больше чем писать “влоб”. Но этот код более контролируем.
- Начинаешь думать о проблеме в терминах SM. Иногда проще влепить условие вместо того чтобы разобраться почему SM не в том состоянии в котором ождаешь.
- Отражать состояние SM в
store
для отображения на UI - одно удовольствие.
В посте где я спрашивал про опыт с SM мне пару человек порекомендовали RXJS для моей задачи. Было бы интересно увидеть ваше решение на RXJS чтобы сравнить наш код.
Статья в рамках рубрики “Today I Learned”