2016-03-14 17 views
8

Ho un problema con ngOnChange. Ho seguenti componenti:Come gestire gli input asincroni nei componenti?

@Component({ 
    selector:'user-table', 
    template: `...`, 

}) 

export class UserTable implements OnChanges{ 
    @Input() users: User[]; 
    years:string[]; 
    constructor(private _usersCollection:UsersCollection){ 
    } 

    ngOnChanges(){ 
    if (this.users.length) 
     {this.years =this._usersCollection.createYearsArray(this.users)} 
    } 
} 

Tuttavia, se unica condizione viene controllato una volta - quando this.users non è ancora recuperato dal server, e quindi la sua lunghezza è pari a 0. Come faccio a trovare la soluzione per affrontare questo tipo di asincrona ingressi?

La matrice viene aggiornato, come quando ho impostato i seguenti registri:

console.log('ON FIRST INIT' , this.programs); 
    this.years = this._usersCollection.createYearsArray(); 
    console.log(this.years); 
    setInterval(()=>{ 
     console.log('IN INTERVVAL' , this.programs); 
    },1000); 

L'uscita della console è:

ON FIRST INIT [] 
UsersTable.component.ts:21 [] 
UsersTable.component.ts:23 IN INTERVVAL [Object, Object, Object, Object] 
+0

Difficile vedere da questo codice cosa sta succedendo. Dove stai andando a prendere i dati. Come sono passati al componente 'UserTable'? –

+0

Sono in macchina - aggiornerò q in 30 ':) – uksz

risposta

7

Se non è necessario eseguire alcuna logica quando la proprietà di input cambia (ad esempio, si utilizza solo la proprietà nei collegamenti del modello), non è necessario eseguire alcuna operazione. Angular propagherà automaticamente i nuovi valori dalla proprietà padre alla proprietà di input.

Se si desidera eseguire la logica di alcuni componenti quando la proprietà di input cambia, utilizzare ngOnChanges(), che viene chiamato ogniqualvolta qualsiasi proprietà di input del componente cambia.

Da angolare utilizza === per rilevare cambiamenti (bene, c'è qualche gestione speciale per NaN troppo), ciò significa che

  • per i tipi di riferimento (Array, Object, Data, ecc), il riferimento (cioè , il riferimento dell'array, dell'oggetto, ecc.) deve cambiare. Ad esempio, myArray = someNewArray;
    Se solo un elemento nell'array cambia, ngOnChanges() non viene chiamato. Ad esempio, per una modifica come myArray[0].name = newName;, non viene chiamato ngOnChanges().
  • per tipi primitivi (numero, booleano, stringa), ciò significa semplicemente che il valore deve cambiare. E.g, myNumber = 5; o myNumber = newNumber;

Un'altra opzione è quella di implementare la propria logica di rilevamento cambiamento utilizzando ngDoCheck(). Vedere this answer per un esempio. Tale hook del ciclo di vita viene chiamato "ogni volta che vengono controllate le proprietà di input di un componente o di una direttiva. Utilizza per estendere il rilevamento delle modifiche eseguendo un controllo personalizzato" - da lifecyle hooks.md

+0

Questo dovrebbe essere rilevato da Object.assign (this.users, success.json())? – uksz

+0

@uksz, 'Oggetto.assign() 'non crea una nuova matrice, modifica la matrice' this.users' esistente. Quindi, 'ngOnChanges()' non sarà chiamato. –

+0

Grande, grazie! quindi questo era effettivamente il problema. A proposito, come hai saputo del rilevamento dei cambiamenti in angular2? Ho letto ngbook2 e ne ho parlato molto poco. – uksz

0

ngOnChanges() viene chiamato quando users vengono aggiornati. Devi solo assicurarti che un nuovo array sia assegnato a users nel componente principale invece di riempire un array esistente. In caso contrario, il rilevamento del cambiamento degli angolari non riconoscerà la modifica.

+0

In realtà, la matrice è cambiata. Ho modificato la mia domanda con altri registri della console. – uksz

+0

È consigliabile utilizzare un setter su @Input quando ho più ingressi asincroni e logica diversa da eseguire? ngOnChanges() funzionerebbe bene ma ho bisogno di controllare quale proprietà è cambiata. – Gambo

+0

Non sicuro senza dettagli completi su ciò che si tenta di realizzare. Se la tua logica dipende dalla modifica di più input, 'ngOnChanges' potrebbe essere più conveniente in alcuni casi, ma altrimenti penso che un setter sia solitamente più conveniente. –

Problemi correlati