ember.js - create - ¿Qué puede hacer con los modelos de datos Ember cuando está en el estado de error?

ember onclick

Question

Me cuesta entender el flujo de trabajo que se usaría en el siguiente escenario:

Un usuario crea un modelo, llamémoslo Producto. Les presentamos un formulario para completar. Los errores de guardado por algún motivo que no sean validaciones (tiempo de espera, acceso denegado, etc.) En Ember, esto pone al modelo en un estado de error. Desde la perspectiva de la interfaz de usuario, todo lo que quiero hacer es poner un mensaje en la pantalla (fácil) y permitir que el usuario intente nuevamente (aparentemente no es tan fácil).

Lo he visto escrito muchas veces para no reutilizar una transacción. Entiendo la lógica de eso. En el caso de un nuevo producto, simplemente creo otro nuevo producto, fusiono los datos del producto original (atributos, relaciones) y sustituyo el contenido de mi controlador con el nuevo producto. Esto no fue difícil y parece funcionar bien, aunque puede haber (con suerte) una mejor manera.

Sin embargo, cuando edito un producto, me encuentro con un problema grave y la solución anterior no funciona. El modelo del producto ahora está en el estado de error y no puedo encontrar ninguna forma de obtener una copia de este producto que no esté en el mismo estado.

Lo que no puedo entender es lo que puedo hacer con este modelo una vez que alcanza el estado de error. He probado lo siguiente:

Rollback: Esto no funciona. No puede deshacer una transacción en el estado de error.

Recarga: igual que el anterior. No se permite recargar un registro en el estado de error.

Agarra una nueva copia del registro: Así que intento App.Product.find (id) con la misma ID que el registro existente. Solo me da una copia del registro existente, en el estado de error.

Espero que me esté perdiendo algo bastante básico aquí. ¿Es posible sacar bien un registro de un estado de error (o un estado no válido para esa materia)?

Si hay una forma sencilla de cambiar el estado de estos modelos, ¿deberíamos seguir creando una nueva transacción para futuros intentos de confirmación?

Answer 1

Con la adición de DS.Errors en 1.0.0-beta5 (consulte https://github.com/emberjs/data/commit/994f3b234ef899b79138ddece60d8b214c5449e3 ) debe poder llamar ...

record.get("errors").clear();

Esto borrará los errores anteriores y los desencadenantes se becameValid .

Answer 2

Puede desencadenar un evento becameValid en becameValid en él:

record.send("becameValid");

Esto debería hacer que el modelo pase al estado no comprometido .

Answer 3

Puede intentar crear una representación paralela del modelo como un objeto Ember.Object que no se conserva pero tiene las mismas propiedades que su modelo persistente. Si su ajax se recupera en un estado de error, puede utilizar la devolución de llamada de error proporcionada por el método ajax para hacer algo.

En este caso, el "algo" podría ser eliminar el registro, y luego clonar las propiedades de su objeto ficticio en un nuevo registro y volver a guardar el registro. En una devolución de llamada exitosa, simplemente destruya su objeto temporal y, si todos los registros están limpios, borre los objetos temporales (para evitar objetos temporales persistentes).

Esto también podría ser una locura ... pero me parece una opción.

Answer 4

Entonces, después de unos días de leer la fuente y experimentar, llegué a la conclusión de que esta funcionalidad aún no está implementada. Para mover un registro a otro estado, se supone que le enviará un evento que lo pasa al statemanager . Parece que no hay eventos registrados en el estado de error que nos permita recuperar el registro.

Hay una solución fea: puedo llamar a transitionTo a el statemanager de statemanager del registro y forzarla al estado que queremos. No decidí hacer esto a la ligera, pero en este punto debo continuar con el proyecto mientras espero que los datos de ascua evolucionen. Entonces, si el registro no está guardado hasta ahora, podemos rescatarlo de un estado no válido o error llamando a:

model.get(''stateManager'').transitionTo(''loaded.created.uncommitted'')

o para un registro existente:

model.get(''stateManager'').transitionTo(''loaded.updated'')

Una vez que se haya llamado, puede intentar llamar a commit nuevamente en la transacción en la que reside el modelo. Esta será la transacción por defecto, ya que el comportamiento de los datos de brasas es mover un modelo a la transacción por defecto una vez que se haya llamado a commit. Es una transacción original. Siempre puede recuperar la transacción actual de un modelo llamando a model.get(''transaction'')

Así que al final de esto, tengo una manera de crear el escenario típico de CRUD que podríamos ver en Ruby on Rails, pero no creo que esta sea la forma ideal de hacerlo. Sin embargo, creo que en este momento, el equipo de datos de ascua tampoco.

Para aquellos de ustedes interesados ​​en tener la funcionalidad CRUD como controlador y mezclar rutas para Ember, tengo un Gist que contiene el código que estoy usando actualmente. Esto funciona bien, se recupera de los errores de guardado, así como los errores de validación. Espero poder continuar refinando esto a medida que evoluciona la información de brasas.