Tempi Angularjs con un filtro e un servizio $ http

Question

Quando la mia app carica, registro un filtro e un servizio con angolare. Ma il filtro sta tentando di eseguire prima che il servizio ritorni con i dati, quindi la mia raccolta di articoli sta abbaiando nel filtro. Ho avuto un violino per questo, ma non so se è possibile utilizzare $ http in un violino perché è una risorsa esterna. Ecco cosa ho Fiddle Spiacente che in realtà non funziona. è stato attraverso un sacco. Penso che il mio problema sia il tempismo. Ho bisogno che il filtro attenda la risposta http o semplicemente non "imponga" stesso.

L'errore che ottengo ora è "le voci non sono definite" perché è dove viene applicato il filtro. Ho avuto questo lavoro prima ho provato a schiacciare la chiamata http in un servizio. Ma mi sembra che sia il modo angolare e "voglio solo essere conforme".

Quando il mio controller spara si effettua la chiamata per recuperare i dati:

eventApi.async().then(function() { 
    $scope.eventCollection = eventApi.data(); 
}); 

ma prima che torni il filtro viene applicato nel codice HTML:

<tr ng:repeat="event in events | myEventFilter:ddlFilter | 
     orderBy:sort.column:sort.descending"> 

Fiddle

Answer 1

Ecco un fork del tuo violino aggiornato che corregge un paio di dipendenze perse (eventApi non iniettate nel controller, $timeout non inserito nel servizio eventApi). I miei commenti si baseranno su questo codice: http://jsfiddle.net/BinaryMuse/zww7e/1/

Questo violino ci porta correttamente al problema che hai postato su: "Impossibile leggere la proprietà 'lunghezza' di undefined" nel tuo filtro. In generale, i filtri dovrebbero essere in grado di gestire valori null/non definiti per impostazione predefinita. Vorrei semplicemente modificare il filtro per leggere qualcosa del genere:

return function (items, eventFilterType) { 
    var arrayToReturn = []; 
    if (items === undefined) return arrayToReturn; 
    // ... 
} 

Questo dovrebbe risolvere il problema di root; il violino ora funziona senza errori, anche se non sembra funzionare correttamente; per quanto posso dire, è perché si sta impostando $scope.eventCollection invece di $scope.events nella sezione if (live) del controller. Effettuare questa modifica fa sì che i dati vengano effettivamente visualizzati nella vista.

Tuttavia, potrebbe essere interessato a un'altra proprietà di Angolare: quando si utilizza una promessa costruito con $q, è possibile associare la vista direttamente alla promessa, e la vista sarà trattare come se tenuti al ha risolto il valore della promessa.Così, per esempio, è possibile effettuare le seguenti operazioni:

// in the service 
$timeout(function() { 
    deffered.resolve(fakeEvents); // <-- resolve with the data 
}, 2000); 
return deffered.promise; 

// in the controller 
if (live) { 
    $scope.events = eventApi.async(); 
} 

Ecco una versione aggiornata del violino che dimostra questa tecnica: http://jsfiddle.net/BinaryMuse/zww7e/2/

[Update]

Come sottolineato da Jeff in i commenti, Angular sta deprecando la promessa automatica di scartare; è possibile see the commit here, ma qui è il messaggio:

fix ($ parse): deprecate promessa unwrapping e renderlo un opt-in

Questo impegnano disabili promettono scartare e aggiunge $ parseProvider.unwrapPromises() getter/setter api che consente agli sviluppatori di di riattivare la funzione, se necessario. Promessa scartare supporto verrà rimosso dal angolare in futuro e questa impostazione consente solo per l'attivazione durante periodo di transizione.

Se lo scartare è abilitata, angolare registrerà un avvertimento su ciascun espressione che scarta una promessa (per ridurre il rumore, ogni espressione viene registrato onces solo). Per disabilitare questa registrazione utilizzare $parseProvider.logPromiseWarnings(false).

In precedenza le promesse si trovavano in qualsiasi punto dell'espressione durante l'espressione valutazione passata a non definita mentre non risolta e al valore di evasione se soddisfatta.

Questa è una caratteristica che non ha dimostrato di essere selvaggiamente utile o popolare, principalmente a causa della dicotomia tra l'accesso ai dati nei modelli (accessibile come valori grezzi) e il codice di controllo (accessibile come promesse).

Nella maggior parte del codice abbiamo risolto manualmente le promesse nei controller o tramite il routing e unificando l'accesso al modello in questo modo.

Altri aspetti negativi di Scartare automatica promessa:

• quando si costruisce componenti E 'spesso desiderabile per ricevere le promesse prime
• aggiunge complessità e rallenta la valutazione dell'espressione
• rende il codice espressione pre-generazione poco attraente a causa di la quantità di codice che deve essere generata
• rende il completamento automatico dell'IDE e il supporto degli strumenti difficile
• aggiunge troppa magia

CAMBIO INTERRUZIONE: $ parse e modelli in genere non saranno più disponibili promemoria. Questa funzione è stata deprecata e se assolutamente necessario, può essere riattivato durante il periodo di transizione tramite $parseProvider.unwrapPromises(true) api.