Лучшая практика в отношении StateManager в Ember.js

StateManager в Ember.js еще недостаточно документирован, поэтому у меня есть некоторые вопросы относительно его использования.

Следует ли пытаться вызвать .goToState только из диспетчера состояний?
Иногда я нахожу себя зеркальным отражением в диспетчере состояний в представлении, например. save: -> StateManager.send("save"). Это имеет смысл или я чего-то не хватает?
Должны ли все модификации моделей (вообще) проходить через диспетчер состояний?
Если одно представление имеет разные состояния, оно должно быть смоделировано с использованием ViewState с дочерними состояниями, или я должен использовать рассчитанные свойства и свойства представления для хранения этой информации только в представлении (без управления государственным менеджером представлений внутреннего состояние)? *

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

Ссылка Github: https://github.com/emberjs/ember.js/tree/master/packages/ember-states/lib

Ответ 1

Следует ли пытаться вызвать .goToState только из состояния менеджер?

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

Я иногда оказываю зеркальное отражение в состоянии менеджер на вид, например. save: → StateManager.send( "save" ). Есть ли это имеет смысл или я что-то упускаю?

Мне нравится, что pangratz должен сказать об этом.

Все изменения модели (как правило) проходят через государственного менеджера?

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

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

Если один вид имеет различные состояния, которые должны быть смоделированы с использованием ViewState с дочерним элементом состояния, или я должен использовать рассчитанные свойства и свойства вида для держите эту информацию только в представлении (без государственного менеджера знание внутреннего состояния взглядов)?

Я думаю, что менеджер штата должен знать (или должен знать) внутреннее состояние представления.

Из любопытства вы исходите из фона веб-разработки или фона для разработки настольных/мобильных приложений? Я пришел из веб-разработки, и диаграммы состояний стали для меня новой концепцией. Мне было очень полезно прочитать каноническую диаграмму состояния диаграммы Дэвида Харела ('ware PDF!). Это удивительно читаемо для научной статьи и излагает концепцию базового состояния, большую часть мира SproutCore/Ember использует с конца 2010 года (т.е. Что

Ответ 2

Относительно вашей точки 2:

Иногда я нахожу себя зеркальным отражением в диспетчере состояний в представлении, например. save: -> StateManager.send("save"). Это имеет смысл или я чего-то не хватает?

Вы можете использовать помощник action в вашем шаблоне Handlebars и установить свой StateManager как target

{{action "send" target="App.stateManager"}}

И событие send отправляется на ваш App.stateManager.