Аутентификация на основе JSON Web Token в Django и AngularJS: часть вторая

[funca]

Автор сильно переусердствовал с модульностью, в приложении практически нечего нет, а файлов и модулей уже...

Кстати, на ангуляре часто так и пишут: один файл — одна сущность. Это снимает часть вопросов, связанных с поддержкой кода, его тестируемостью и повторным использованием. Например, недавно была статья habrahabr.ru/post/243565/. У автора тоже что-то подобное, только все вручную. Все-таки JS менее выразительный язык, чем питон, потому код имеет тенденцию скатываться в состояние неподдерживаемого «говнокода» быстрее. Отсюда, приходится строже относится к таким вещам, как модульность.

Так же считаю излишним выносить js в отдельный шаблон и потом его подключать. В оригинале автор использует для этого templates/javascripts.html.

Мы в коммерческой разработке используем не только bower, но и много — gulp для «компиляции» статики, пост-процесснига django-шаблонов, и т.п… С одной стороны, тащить в проект уровня «hello world!» инфраструктуру кажется перебором, но с другой — к хорошему быстро привыкаешь, так что потом сложно отказываться. :) Могу предположить, что в реальных проектах у них больше одного django-шаблона, куда подключается один и тот же набор скриптов. Отсюда такое решение.

[d06pbiy_kot]

Кстати, на ангуляре часто так и пишут: один файл — одна сущность. Это снимает часть вопросов, связанных с поддержкой кода, его тестируемостью и повторным использованием. Например, недавно была статья 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. Если Я не прав в каких то моментах, буду рад выслушать критику.

[Zippovich]

И еще, в оригинале автор использовал глобальный объект window (window.angular.module('application.auth.services')) хотя в репозитории уже лежит довольно красивый код.

ну там и $q лишнее, $http уже промис возвращает