Comments 3
Автор сильно переусердствовал с модульностью, в приложении практически нечего нет, а файлов и модулей уже...
Кстати, на ангуляре часто так и пишут: один файл — одна сущность. Это снимает часть вопросов, связанных с поддержкой кода, его тестируемостью и повторным использованием. Например, недавно была статья habrahabr.ru/post/243565/. У автора тоже что-то подобное, только все вручную. Все-таки JS менее выразительный язык, чем питон, потому код имеет тенденцию скатываться в состояние неподдерживаемого «говнокода» быстрее. Отсюда, приходится строже относится к таким вещам, как модульность.
Так же считаю излишним выносить js в отдельный шаблон и потом его подключать. В оригинале автор использует для этого templates/javascripts.html.
Мы в коммерческой разработке используем не только bower, но и много — gulp для «компиляции» статики, пост-процесснига django-шаблонов, и т.п… С одной стороны, тащить в проект уровня «hello world!» инфраструктуру кажется перебором, но с другой — к хорошему быстро привыкаешь, так что потом сложно отказываться. :) Могу предположить, что в реальных проектах у них больше одного django-шаблона, куда подключается один и тот же набор скриптов. Отсюда такое решение.
Кстати, на ангуляре часто так и пишут: один файл — одна сущность. Это снимает часть вопросов, связанных с поддержкой кода, его тестируемостью и повторным использованием. Например, недавно была статья habrahabr.ru/post/243565/. У автора тоже что-то подобное, только все вручную.
Полностью согласен, но во всем должно быть понимание, когда это нужно, а когда нет. Есть рекомендации и каждый выбирает для себя. IMHO в данном случае, поскольку этот проект не претендует на шаблон для angular генератора, можно было сделать структуру и попроще.
Все-таки JS менее выразительный язык, чем питон, потому код имеет тенденцию скатываться в состояние неподдерживаемого «говнокода» быстрее. Отсюда, приходится строже относится к таким вещам, как модульность.
Что то Я про выразительность не особо понял, причем тут она вообще. Да в JS нет модульности, но мы то здесь не на чистом JS пишем, а используем angular и этого хватает. (единственное чего действительно не хватает так это загрузки по требованию) А если захотеть, то и на python можно такое наго****ть. И что, неужели есть необходимость помещать RegisterController и LoginController в отдельные файлы, когда можно использовать один файл:
controllers.js
(function () {
'use strict';
angular
.module('application.auth.controllers')
.controller('LoginController', ['Auth', function (Auth) {
var vm = this;
vm.user = {};
vm.login = function () {
Auth.login(vm.username, vm.password);
}
}])
.controller('RegisterController', ['Auth', function (Auth) {
var vm = this;
vm.register = function () {
Auth.register(vm.username, vm.password, vm.email);
}
}
]);
})();
Мы в коммерческой разработке используем не только bower, но и много — gulp для «компиляции» статики, пост-процесснига django-шаблонов, и т.п… С одной стороны, тащить в проект уровня «hello world!» инфраструктуру кажется перебором, но с другой — к хорошему быстро привыкаешь, так что потом сложно отказываться. :) Могу предположить, что в реальных проектах у них больше одного django-шаблона, куда подключается один и тот же набор скриптов. Отсюда такое решение.
А зачем мешать backend с fronten' ом? Если frontend с rest api, то он ну никак не должен зависеть от backend' a. И что будите делать со своим frontend' ом если по каким то причинам нужно будет поменять backend?
А как вы тестируете frontend?
P. S. Если Я не прав в каких то моментах, буду рад выслушать критику.
И еще, в оригинале автор использовал глобальный объект window (window.angular.module('application.auth.services')) хотя в репозитории уже лежит довольно красивый код.
ну там и $q лишнее, $http уже промис возвращает
Sign up to leave a comment.
Аутентификация на основе JSON Web Token в Django и AngularJS: часть вторая