Я новичок в AngularJS, совсем недавно решил его использовать в своем хобби-проекте. Довольно быстро передо мной встала задача настроить раутинг по определенным условиям, самое простое и очевидное из таких условий — авторизован пользователь или нет. Приложение содержит страницы, открытые любому пользователю, и страницы, куда можно зайти только авторизовавшись. Если авторизации нет, нужно попробовать ее получить прозрачно для пользователя, если это не удалось — средиректить на страницу логина.

На сколько я понимаю, это задача достаточно распространенная, тем не менее я не нашел простого готового способа сделать это из коробки. Потратив изрядное количество времени на гугление, чтение документации и эксперименты, я в итоге нашел достаточно элегантное решение для моего случая. Спешу поделиться своим велосипедом, надеюсь, это поможет сэкономить время таким же начинающим пользователям AngularJS. Возможно, найдется гуру, который укажет на то самое стандартное решение, которое я почему-то не нашел. Я, например, не разбирался с ui-router.

Задача

Стоит чуть подробнее написать про мою задачу. Имеется одностраничное веб-приложение (Single Page Application). Для простоты будем считать, что есть одна общедоступная «главная» страница по пути "/", то есть в корне сайта. На ней пользователь может пройти регистрацию или залогиниться. При успешном логине, приложение получает авторизационный токен и пользовательский профиль. Профиль представляет собой развесистую структуру данных и, для снижения нагрузки на сервер, я хочу загружать его один раз при логине, а не по частям на каждой странице. Авторизационный токен может храниться достаточно долго в локальном хранилище браузера, но данные профиля загружаются заново при каждом обновлении страницы. Получив токен один раз, я могу свободно ходить по всем закрытым страницам, перезагружать любую из них, добавлять в закладки и т.д. профиль при этом подгружается прозрачно для меня. Но если токен протухнет или я дам ссылку на закрытую страницу сайта другу, сайт должен отправить меня (или друга) на главную страницу.

Поиски решения

Единственное полезное, что выдал гугл на запрос «Angularjs conditional routing» — вот этот вопрос на stackoverflow. Там предлагалось два решения:

Первое — посылать с сервера статус 401 и перехватывать его через сервис $http — предполагается запрос на сервер с каждой защищенной страницы. Может, кому-то подойдет, но не мне — я загружаю данные один раз и допиливать сервер ради раутинга на клиенте не хотелось бы.

Второе — перехватывать сообщение $routeChangeStart, проверять, куда идем, есть ли авторизация и, если нет, редиректить. Как вариант — слушать изменения пути через $scope.$watch(function() { return $location.path(); }. Недостатки этого решения:

1. В случае с $routeChangeStart объект next не предоставляет пути раутинга, понимать куда идем не очень удобно; сообщение это будет кидаться и на редиректах с несуществующих страниц, в итоге выражения в условиях раутинга будут не слишком красивые, завязаны на названия темплейтов, имена контроллеров и прочие странные вещи.
2. Если нужно подгрузить данные, как в моем случае, нет способа задержать раутинг до конца загрузки. При этом раутинг может зависеть от самих данных в профиле пользователя — к примеру, у него новое супер-предложение и нужно все бросать и срочно идти на страницу этого предложения.

У меня была мысль при отсутствующих данных редиректить на отдельную «страницу загрузки», там догружать данные и редиректить по результатам, но во-первых логика раутинга размазывается по двум местам — в одном смотрим путь, в другом данные; во-вторых у пользователя в истории останется эта промежуточная страница. Историю можно затирать с помощью $location.replace(), но если загрузка по каким-то причинам задержится и пользователь успеет нажать Назад, затрется не та страница, а его еще и средиректит уже с другой страницы, нужно как-то обрабатывать еще и этот случай, что простоты решению не добавляет. В-третьих нужно где-то запоминать, куда мы шли, чтобы правильно средиректить, с учетом ситуации из «во-вторых». Это решение меня не вдохновило и я продолжил поиски.

Решение

AngularJS предоставляет сервис со интересным названием $q. В документации можно прочитать почему q и спецификацию defered/promise — достаточно простая и интересная концепция. Вкратце, мы просим сервис изготовить специальный объект

var defered = $q.defer();

Из этого объекта получаем объект-promise и отдаем клиенту нашего кода

return defered.promise;

Клиент вешает на promise коллбэки успеха и неудачи операции

promise.then(function (result) {...}, function (reason) {...});

Теперь когда мы мы сделаем на нашем объекте

defered.resolve(result);

или

defered.reject();

у клиента вызовется соответствующий коллбэк. Чем это лучше обычных коллбэков? promise’ы можно объединять в цепочки (за подробностями — в документацию) и, что важно для моей задачи, многие сервисы AngularJS умеют работать с ними, в том числе в $routerProvider в конфигурации раута можно указать поле resolve и передать туда promise. При этом если передать объект, который не является promise, он будет интерпретирован как уже зарезолвленный promise. Раут будет ждать, пока promise не зарезолвится, а если произойдет reject, то и вовсе отменится. Дальше все просто — пишем функцию, которая загружает данные, если нужно, делает все проверки и редиректы. Если нужно подгрузить данные — возвращается promise, если нужно сделать редирект — перед ним promise реджектится, чтобы старый раут не ждал зря.

Код решения:

'use strict';  var app = angular.module('app', [])     .config(['$routeProvider', function($routeProvider) {         $routeProvider             .when('/', {                 templateUrl: "login.html",                 controller: LoginController             })             .when('/private', {                 templateUrl: "private.html",                 controller: PrivateController,                 resolve: {                     factory: checkRouting                 }             })             .when('/private/anotherpage', {                 templateUrl:"another-private.html",                 controller: AnotherPriveController,                 resolve: {                     factory: checkRouting                 }             })             .otherwise({ redirectTo: '/' });     }]);  var checkRouting= function ($q, $rootScope, $location) {     if ($rootScope.userProfile) {         return true;     } else {         var defered = $q.defer();         $http.post("/loadUserProfile", { userToken: "blah" })             .success(function (response) {                 $rootScope.userProfile = response.userProfile;                 defered.resolve(true);             })             .error(function () {                 defered.reject();                 $location.path("/");              });         return defered.promise;     } }; 

В итоге получилось достаточно просто и прозрачно, даже странно почему этого решения не было в сети (теперь будет). Из недостатков можно отметить то, что в каждом рауте нужно прописывать resolve, но в другой стороны это дает явность конфигурации и гибкость — можно написать еще пару таких же check* функций (если логика для разных страниц совершенно разная) и использовать где нужно.