Jak obsługiwać 404 danych Ember w trasie?

Question

W mojej trasie mam metodę, która próbuje zwrócić listę modeli z serwera

model: -> 
    App.MyModel.find 
     projectId: (@modelFor "project").id 

Teraz oczywiście czasami to może powrócić do 404.

w chwili, gdy to się stanie, po prostu przestaje Ember robić cokolwiek. Żaden widok nie jest renderowany, żaden kontroler nie jest skonfigurowany.

Jak zatem prawidłowo obsłużyć 404 (tj. Pokazać widok błędu)?

Answer 1

Złe wieści: w tej chwili ember-data nic nie robi, gdy 404 zostanie znalezione(). W ogóle. Model znajduje się w stanie "ładowanie" na zawsze.

W mojej opinii nie ma tu opcji, które nie są całkowicie głupie. To, co prawdopodobnie zrobiłbym w ostateczności, to dodanie atrybutu notFound w moim DS.Model i zamiast zwracania 404, zwróć JSON z notFound ustawionym na true. To bolesne, wiem ...

--- Pierwotnie zaproponowałem rozwiązanie polegające na przesłonięciu find w podklasie RESTAdapter. Wtedy zauważyłem, że find NIE przechodziło przez rekordową instancję, którą podobno ładuje. Tak więc, nie kontynuuj obsługi 404, wprowadzając rekord w stan błędu.

[UWAGA: Ember-data zmieniła się dramatycznie od marca 2013 roku, informacje zawarte w tej odpowiedzi nie może już być używany]

Answer 2

Nawiasem mówiąc, „nowy” BasicAdapter został właśnie wydany teraz. Pytanie brzmiało: czy to ułatwi obsługę 404 błędów.

Podejście nr 1

Moje pierwsze podejście - podobny do tego, co Christopher sugerował - było dodać dodatkowe pole zawierający status HTTP.

status: DS.attr("number"); 

A potem użyłem tego AJAX połączenia:

$.getJSON(url, data).then(null, function(xhr) { 
    return { 
    id: id, 
    statusCode: xhr.status 
    }; 
}).always(function(data) { 
    return process(data).load(); 
}); 

Co to robi jest przekształcenie odpowiedź błędu (XHR) do mieszania zawierającego żądany identyfikator i kod stanu. Ostatecznie wynik pomyślny lub nieudany hash są przekazywane do sklepu.

Ten rodzaj prac, ale nie jest zbyt praktyczny: Po wyświetleniu listy wszystkich instancji modelu te "fałszywe" wystąpienia muszą zostać odfiltrowane ręcznie.

---

Podejście nr 2

Innym pomysłem było stworzenie specjalnego modelu błędzie.

App.Error = App.Model.extend({ 
    status: DS.attr("number") 
}); 

a zapytanie według:

$.getJSON(url, data).then(null, function(xhr) { 
    return App.store.load(App.Error, {}, { 
    id: 0, 
    status: xhr.status 
    }); 
}).done(function(data) { 
    return process(data).load(); 
}); 

To będzie ładować i utworzyć nową instancję modelu błędu i umieścić go w sklepie.

Problem polega na tym, że Ember tak naprawdę "nie akceptował" tego. Aplikacja przestała routować, nic już nie robiąc. Tak więc wydaje się to ślepy zaułek, a także :(

Answer 3

uderzę tego problemu, a także dzisiaj.

Jednak po spojrzeniu na źródła, wydaje się, że model jest właściwie ustawiony tak, aby wykorzystać Ember.Evented, a my . można dodać własne programy obsługi dla tych przypadkach

te dwa wydarzenia, które wpadła mi w oko były becameError i didLoad

W moim przypadku udało mi się zrobić coś jak następuje:.

// Grab a user by id. 
var user_rec = App.User.find(user.id); 

// Oh no! Error! 
user_rec.on('becameError', function() { 
    alert('I could not find you!'); 
}); 

// We should be good! Proceed! 
user_rec.on('didLoad', function() { 
    alert('Your email: '+this.get('email')); 
}); 

Oto źródło na github: https://github.com/emberjs/data/blob/master/packages/ember-data/lib/system/model/model.js

Mamy nadzieję, że jeśli rzeczywiście jest to sposób, w jaki powinniśmy postępować, w niedalekiej przyszłości pojawi się dodatkowa dokumentacja w przewodnikach.