Classe Aurelia Costruttore vs Attiva

Question

Quando esporti una classe es6, che funge da modello di visualizzazione in aurelia, mi sembra di essere in grado di impostare il codice di inizializzazione sia nel costruttore che in una funzione di attivazione.

Esistono convenzioni standard qui?

Devo eseguire l'inizializzazione in uno ma non nell'altro?

È la funzione di attivazione lì per gli utenti che non implementano le classi es6?

Answer 1

È possibile impostare le proprietà dell'istanza in entrambi i metodi di costruzione e attivazione, entrambi verranno invocati da Aurelia. Tuttavia, qui c'è una sorta di differenza concettuale.

L'attivazione è uno dei metodi del ciclo di vita dell'attivazione dello schermo e dovrebbe essere idealmente utilizzato per controllare solo il comportamento di schermo/modello di visualizzazione. Ad esempio, il metodo canDeactivate controlla se è possibile navigare nel modello di visualizzazione, ecc. Activate è anche un hook che viene eseguito appena prima che il modello di visualizzazione venga sottoposto a rendering (ma prima di attached hook). Tuttavia, è possibile che il metodo activate non venga mai chiamato è dire che il percorso si allontana nel costruttore o nei metodi canActivate rifiuta/restituisce falso - in questo caso il costrutto verrà comunque richiamato, ma l'attivazione non lo sarà.

D'altra parte, il metodo construct viene richiamato prima di qualsiasi altro hook e metodo, quindi viene chiamato prima di activate. Per questo motivo, il costrutto è un luogo primario per l'impostazione delle proprietà di configurazione perché richiede iniezioni di dipendenza. Quindi mentre si attiva prende un insieme fisso di parametri (params, routeConfig, navigationInstruction), l'elenco dei parametri passati al metodo constructor dipende da quali servizi si iniettano nella classe del modello di visualizzazione.

Answer 2

Una grande differenza che vedo qui è che il metodo di attivazione ha un Promis come valore di ritorno in modo da poter eseguire qui il codice asincrono. L'attivazione del codice asincrono nel costruttore è una pessima idea. Ulteriori dettagli sono che il costruttore non deve lanciare un'eccezione, quindi in genere qui si assegnano i parametri del costruttore alle variabili locali senza qualsiasi logica. Non vorrei fare più cose nel costruttore e l'effettiva inizializzazione viewmodel con logica dovrebbe accadere in attivare o metodo collegato.