Práctica recomendada para StateManager en Ember.js

Question

El StateManager en Ember.js aún no está bien documentado, por lo que tengo algunas preguntas sobre su uso.

1. ¿Debería uno esforzarse por llamar al .goToState solo desde el administrador de estado?
2. A veces me encuentro reflejando métodos en el administrador de estado en la vista, p. save: -> StateManager.send("save"). ¿Tiene sentido o me estoy perdiendo algo?
3. ¿Todas las modificaciones de modelos (generalmente) deben pasar por el administrador de estado?
4. Si una vista tiene estados diferentes, debe modelarse utilizando un ViewState con estados secundarios, o debería usar propiedades calculadas y propiedades de vista para mantener esa información solo en la vista (sin que el administrador de estado conozca el estado interno de las vistas) ? *

* un ejemplo podría ser una forma de tres pasos, donde se utiliza la misma plantilla para todos los estados, pero diferentes áreas se muestran/oculto en los tres pasos. referencia

Github: https://github.com/emberjs/ember.js/tree/master/packages/ember-states/lib

Answer 1

¿Debería uno esforzarse para llamar a .goToState solo desde el administrador del estado ?

Probably. No lo sé con certeza, pero me parece que debido a que el administrador del estado sabe en qué estado se encuentra, es el lugar para hacer cumplir las transiciones legales del estado. Si llama a .goToState desde fuera del administrador estatal, lo hace sin saber realmente en qué estado se encuentra, y aunque a veces eso está bien (quizás es un estado al que puede llegar desde cualquier otro estado) no es un gran hábito para estar en.

veces me encuentro reflejo métodos en el gestor de estado en la vista, por ejemplo, guardar: -> StateManager.send ("guardar"). ¿Tiene sentido o me falta algo?

Me gusta lo que pangratz tiene que decir sobre esto.

¿Debería pasar toda la modificación de los modelos (en general) a través del administrador de estado?

La forma en que uso los diagramas de estados, no. Sin embargo, he visto a algunas personas que usan gráficos de estado como un reemplazo completo para la capa de controlador, y si así es como estás trabajando, entonces sí, debería pasar por el administrador de estado. El patrón es evitar la manipulación directa de modelos desde las vistas; si es una capa de controlador o un administrador de estado en el medio parece un punto discutible para mí.

La forma en que uso tablas de estado, sin embargo, el administrador de estado está hecho para administrar el estado de la aplicación. Puede jugar al administrador de tráfico para la modificación de modelos si esa modificación cambiará el estado de la aplicación (por ejemplo, si hay un indicador de progreso mientras se completa una actualización), pero me parece que las actualizaciones del modelo no son parte de su mandato; ellos pertenecen a los controladores.

Si un punto de vista tiene estados diferentes, en caso de que se pueden modelar mediante un ViewState con niño estados, o debería utilizar las propiedades calculadas y las propiedades de vista de sostener que la información sólo en la vista (sin el gestor de estado conociendo el estado interno de las vistas)?

Creo que el administrador de estado necesita saber (o debería saber) el estado interno de la vista.

Por curiosidad, ¿vienes de un fondo de desarrollo web, o un fondo de desarrollo de aplicación de escritorio/móvil? Vengo del desarrollo web y las tablas de estado fueron un concepto nuevo para mí. Me pareció muy útil leer the canonical State Chart paper por David Harel ('ware PDF!). Es sorprendentemente legible para un documento académico y establece el concepto de gráfico de estado básico que la mayoría del mundo SproutCore/Ember ha estado utilizando desde finales de 2010 (es decir, es lo que Michael Cohen tenía en mente cuando escribió Ki.)

Answer 2

Con respecto a su punto de :

a veces me encuentro a mí mismo reflejo métodos en el gestor de estado en la vista, por ejemplo, save: -> StateManager.send("save"). ¿Tiene sentido o me estoy perdiendo algo?

podría utilizar el ayudante action en su plantilla Pomos y fija su StateManager como target

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

Y el caso send es enviar a su App.stateManager.