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

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

In modalità sviluppo, il rilevamento modifiche esegue una seconda esecuzione immediatamente dopo la prima esecuzione e genera un errore se un valore associato è stato modificato tra la prima e la seconda esecuzione. Questo aiuta a localizzare bug dove i valori di controllo hanno effetti collaterali o campi o funzioni non restituiscono lo stesso valore nelle chiamate successive che minano il rilevamento delle modifiche di Angular.

In modalità di sviluppo, durante la seconda esecuzione di rilevamento del cambiamento, Angular esegue anche alcuni confronti di oggetti profondi che non eseguirà in produzione per rilevare modifiche del modello non consentite.

Aggiornare:

In modalità sviluppo, viene anche stampato un suggerimento sulla console quando il servizio disinfettante HTML rimuove i valori dai collegamenti [innerHTML]="..." o [ngStyle]="..." . Vedi anche: in RC.1 non è ansible aggiungere alcuni stili usando la syntax del bind

I documenti per lo stato ApplicationRef.tick () :

Nella modalità di sviluppo, tick() esegue anche un secondo ciclo di rilevamento delle modifiche (TTL = 2) per garantire che non vengano rilevate ulteriori modifiche. Se vengono rilevate ulteriori modifiche durante questo secondo ciclo, i collegamenti nell’app presentano 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 Angolare 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 è ansible apportare ulteriori modifiche è dovuto al fatto che in modalità produzione, il rilevamento modifiche viene eseguito una sola 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 provoca una modifica ad alcune altre proprietà che il componente principale ha associato in una vista / modello, la vista del componente principale non verrà aggiornata (perché il rilevamento delle modifiche non rivedrà il componente genitore in modalità produzione … a causa della traversata dell’albero “one pass”). Si aggiornerà solo la prossima volta che si verifica qualche evento e il cambio di rilevamento viene eseguito di nuovo, ma è troppo tardi!

Ecco un Plunker che viola la regola: un componente figlio ha un metodo set su una proprietà di input che modifica un’altra proprietà di input. Sì, è un esempio forzato, ma è più facile da capire rispetto al prossimo:

Un altro scenario in cui potresti incontrare questo problema è con pipe stateful. 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.