Por alguna razón, tengo que ejecutar mi aplicación en modo de producción. ¿Cuál es la diferencia entre esos modos?
Por alguna razón, tengo que ejecutar mi aplicación en modo de producción. ¿Cuál es la diferencia entre esos modos?
Respuestas:
En el modo de desarrollo, la detección de cambios realiza una segunda ejecución inmediatamente después de la primera ejecución y produce un error si algún valor límite ha cambiado entre la primera y la segunda ejecución. Esto ayuda a localizar errores en los que la comprobación de valores tiene efectos secundarios o los campos o funciones no devuelven el mismo valor en llamadas posteriores, lo que socava la detección de cambios de Angular.
En el modo de desarrollo, durante la segunda ejecución de detección de cambios, Angular también hace algunas comparaciones profundas de objetos que no hará en producción para detectar cambios de modelo que no están permitidos.
Actualizar:
En el modo de desarrollo, también se imprime una sugerencia en la consola cuando el servicio de desinfección de HTML elimina los valores de los enlaces [innerHTML]="..."
o [ngStyle]="..."
. Ver también: En RC.1 algunos estilos no se pueden agregar usando sintaxis de enlace
Los documentos para ApplicationRef.tick () dicen:
En el modo de desarrollo,
tick()
también realiza un segundo ciclo de detección de cambios (TTL = 2) para garantizar que no se detecten más cambios. Si se detectan cambios adicionales durante este segundo ciclo, las vinculaciones en la aplicación tienen efectos secundarios que no se pueden resolver en una sola pasada de detección de cambios. En este caso, Angular arroja un error, ya que una aplicación Angular solo puede tener una pasada de detección de cambios durante la cual deben completarse todas las detecciones de cambios.
La razón por la que no podemos tener cambios adicionales es porque en el modo de producción, la detección de cambios solo se ejecuta una vez, lo que significa que cada componente en el árbol de componentes se examina una vez (TTL = 1) ... desde la parte superior, en profundidad primero orden. Entonces, si, por ejemplo, un cambio en la propiedad de entrada de un componente secundario provoca un cambio en alguna otra propiedad que el componente principal ha vinculado en una vista / plantilla, la vista del componente principal no se actualizará (porque la detección de cambios no volverá a visitar el componente padre en modo de producción ... debido al recorrido del árbol de "una pasada"). Solo se actualizará la próxima vez que ocurra algún evento y la detección de cambios se ejecute nuevamente, ¡pero es demasiado tarde!
Aquí hay un Plunker que viola la regla: un componente secundario tiene un set
método en una propiedad de entrada que modifica otra propiedad de entrada. Sí, es un ejemplo artificial, pero es más fácil de entender que el siguiente:
Otro escenario en el que puede encontrarse con este problema es con tuberías con estado. Mira esta respuesta si ese es tu problema.
Debe describir su problema (en otra pregunta SO). Debería haber una forma de solucionarlo.