Реагирует ли конечный автомат на роль маршрутизатора?

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

Должен ли я создавать конечный автомат для всего приложения или мне нужно создавать маленькие машины для каждого маршрута?

1 ответ

Решение

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

Например, https://state-machine-yzgnuxxwmg.now.sh/

Однако в первом абзаце https://statecharts.github.io/how-to-use-statecharts.html рекомендуется использовать диаграммы состояний на уровне компонентов при запуске.

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

Другие вопросы по тегам