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

Question

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

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

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

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

Answer 1

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

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

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

Мне нравится, что Пангратц говорит по этому поводу.

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

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

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

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

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

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

Answer 2

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

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

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

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

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