Qual è la differenza tra la modalità di produzione e quella di sviluppo in Angular2?

Per qualche motivo, devo eseguire la mia app in modalità di produzione. Qual è la differenza tra queste modalità?

In modalità di sviluppo, il rilevamento delle modifiche esegue una seconda esecuzione immediatamente dopo la prima e produce un errore se un valore limite è cambiato tra la prima e la seconda esecuzione. Questo aiuta a individuare i bug in cui il controllo dei valori ha effetti collaterali o campi o funzioni non restituiscono lo stesso valore nelle chiamate successive, il che compromette il rilevamento delle modifiche di Angular.

In modalità di sviluppo, durante la seconda esecuzione di rilevamento delle modifiche, Angular esegue anche alcuni confronti approfonditi degli oggetti che non farà in produzione per rilevare le modifiche al modello non consentite.

Aggiornare:

In modalità di sviluppo, viene stampato anche un suggerimento sulla console quando il servizio di disinfezione HTML rimuove i valori dalle associazioni [innerHTML]="..."o [ngStyle]="...". Vedi anche: In RC.1 alcuni stili non possono essere aggiunti usando la sintassi di associazione

La documentazione per ApplicationRef.tick () afferma:

In modalità di sviluppo, tick()esegue anche un secondo ciclo di rilevamento delle modifiche (TTL = 2) per garantire che non vengano rilevate ulteriori modifiche. Se durante questo secondo ciclo vengono rilevate ulteriori modifiche, le associazioni nell'app hanno effetti collaterali che non possono essere risolti in un singolo passaggio di rilevamento delle modifiche. In questo caso, Angular genera un errore, poiché un'applicazione Angular può avere solo un passaggio di rilevamento delle modifiche durante il quale deve essere completato tutto il rilevamento delle modifiche.

Il motivo per cui non possiamo avere modifiche aggiuntive è perché in modalità di produzione, il rilevamento delle modifiche viene eseguito solo una volta, il che significa che ogni componente nell'albero dei componenti viene esaminato una volta (TTL = 1) ... dall'alto, in profondità prima ordine. Quindi, se, ad esempio, una modifica alla proprietà di input di un componente figlio causa una modifica a qualche altra proprietà che il componente padre ha associato in una vista / modello, la vista del componente padre non verrà aggiornata (perché il rilevamento delle modifiche non rivisiterà il componente genitore in modalità di produzione ... a causa dell'attraversamento dell'albero "one pass"). Verrà aggiornato solo la prossima volta che si verifica un evento e viene eseguito nuovamente il rilevamento delle modifiche, ma è troppo tardi!

Ecco un Plunker che viola la regola: un componente figlio ha un setmetodo su una proprietà di input che modifica un'altra proprietà di input. Sì, è un esempio artificioso, ma è più facile da capire del prossimo:

Un altro scenario in cui potresti incorrere in questo problema è con le pipe con stato. Dai un'occhiata a questa risposta se questo è il tuo problema.

Dovresti descrivere il tuo problema (in un'altra domanda SO). Ci dovrebbe essere un modo per risolverlo.