AngularJS style guide to coś, czego brakowało mi zaczynając pracę z AngularJS. Jest to dokument zwięźle opisujący najlepsze praktyki, które powinno stosować się w aplikacjach opartych o AngularJS. Lektura obowiązkowa!
Posty oznaczone etykietą angularjs
AngularJS style guide to coś, czego brakowało mi zaczynając pracę z AngularJS. Jest to dokument zwięźle opisujący najlepsze praktyki, które powinno stosować się w aplikacjach opartych o AngularJS. Lektura obowiązkowa!
Nie mam słów i jestem zażenowany poziomem tzw. webdeveloperów portujących pluginy pod Angulara. Zdecydowana większość tego syfu to wrappery na ścierwo pisane pod jQuery. Tak, ścierwo, bo ta biblioteka sama w sobie jest jak lep na muchy, który przez swoją tandetną prostotę przyciąga tabuny amatorów przykładających swoje uszczerbione i ufajdane cegiełki do dziurawej budowli wznoszonej od lat przez nadęte i oderwane od rzeczywistości community open source. I mimo, że są perły pod jQuery, to tworząc soft pod Angulara używanie jQuery jest nadmiarem, naroślą, wrzodem na dupie i opuchlizną dręczącą i tak nie najlżejszy framework.
Jedyny sens jest portować tak, aby nie miały zależności od jQuery czy innych wynalazków tworzonych jako dodatek do HTML-a. Dlatego ciśną mi się na klawiaturę słowa: ludzie, przestańcie do cholery robić syf - albo robicie coś porządnie, albo nie róbcie tego wcale. Później mamy taki sektor IT, jaki sobie tworzymy. Poczytajta też Stack Overflow w tym temacie.
Czołem.
Kolejny wypadek Django przy pracy, który powinien przekonać niedowiarków i wyznawców Django, że ten framework nadaje się do stawiania blogasków, ale niespecjalnie jako server side dla aplikacji.
Przy włączonym DEBUG handlery 403,404 i 500 nie są używane. Do akcji wkraczają tzw. technical responses, które generują specjalny output dla poszczególnych błędów. Z reguły są one bardzo przydatne, ale pisząc server pod klienta w AngularJS w response otrzymujemy... piękny html ze stylami i css. Przeczytanie błędu graniczy z cudem, a zdevelopowanie poprawnej obsługi błędu w kliencie jest niemożliwe w trybie DEBUG. Niemożliwe, bo nie da się podmienić technical responses. Są one wołane w core handlerze, więc nie ma na to szans.
Możemy w konfiguracji podmienić exception filter, ale on jest używany przez exeption reporter a to na jego wymianie lub rozszerzeniu nam zależy, jeśli chcemy cokolwiek sensownego zrobić z obsługą błędów 403,404,500 w trybie DEBUG!
Implementacja is_ajax()
opiera się na jakiejś konwencji. Po pierwsze - skoro to konwencja, to powinno dać się ją zmienić na potrzeby projektu. Oczywiście nie da się, podobnie jak nie da się prosto wymienić klasy HttpRequest
, w której podmieniłbym is_ajax
(trzeba grzebać low-level na poziomie handlerów wsgi). Monkey patching mnie nie interesuje - readability counts.
Natomiast można skonfigurować AngularJS do współpracy ze zmaszczonym niespecjalnie rozsądnymi rozwiązaniami Django, wystarczy skonfigurować nagłówek:
angular.module('myApp').config(function($httpProvider) {
$httpProvider.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest';
});
Ano dodali kiedyś takiego paszkwila w odpowiedzi na zgłoszenie:
if request.is_ajax():
text = reporter.get_traceback_text()
return HttpResponseServerError(text, content_type='text/plain')
Świetnie, ale to nie rozwiązuje problemu, bo:
HTTP_ACCEPT
mam application/json
i chcę mieć w response JSON z błędem (!!!)Django developers są szczęśliwi i dumni ze swojego podejścia znanego jako "Django ethos". Sukcesów życzę i omijania Django w dużych projektach.
Zapisuję w formie notatki, aby nikogo (w tym mnie) nie kusiło użycie csrf_exempt
;)
Dodanie obsługi CSRF w AngularJS 1.1.5+ polega na skonfigurowaniu nazw nagłówka i cookie:
.config(function($httpProvider) {
$httpProvider.defaults.xsrfHeaderName = 'X-CSRFToken';
$httpProvider.defaults.xsrfCookieName = 'csrftoken';
})