Подробно о внутренней кухне AngularJS

в 19:36, , рубрики: AngularJS, javascript, Программирование, метки:

У фреймворка AngularJS есть несколько интересных решений в коде. Сегодня мы рассмотрим два из них – как работают области видимости и директивы.

Первое, чему обучают всех в AngularJS – директивы должны взаимодействовать с DOM. А больше всего новичка запутывает процесс взаимодействия между областями видимости, директивами и контроллерами. В этой статье мы рассмотрим подробности работы областей видимости и жизненный цикл Angular-приложения.

Если в следующей картинке вам что-то непонятно – эта статья для вас.

image

(В статье рассматривается AngularJS 1.3.0)

AngularJS использует области видимости, чтобы абстрагировать общение директив и DOM. Области видимости есть и на уровне контроллеров. Области видимости – это простые объекты JavaScript (plain old JavaScript objects, POJO). Они добавляют кучку «внутренних» свойств, которые предваряются одним или двумя символами $. Те, у которых стоит префикс $$, не нужно использовать в коде слишком часто – обычно их использование говорит о непонимании работы приложения.

Так что это за области видимости такие?

На жаргоне AngularJS область видимости означает не то, что под этим подразумевается в коде JS. Обычно под областью видимости понимают блок кода, которая содержит контекст, разные переменные и т.п. К примеру:

function eat (thing) {
   console.log('Кушаю ' + thing);
}

function nuts (peanut) {
   var hazelnut = 'hazelnut'; // фундук

   function seeds () {
      var almond = 'almond'; // миндаль
      eat(hazelnut); // Отсюда я могу залезть в мешок!
   }

   // Миндаль здесь недоступен.
}

Однако это не те области видимости, про которые идёт речь в AngularJS.

Наследование областей видимости в AngularJS

Область видимости в AngularJS также является контекстом, но только в понимании AngularJS. В AngularJS область видимости связана с элементом и всеми его дочерними элементами, при этом элемент не обязательно прямо связан с областью видимости. Элементам назначаются области видимости одним из трёх способов.

Первый – если область видимости создаётся у элемента контроллером или директивой.

<nav ng-controller='menuCtrl'>

Второй – если у элемента нет области видимости, он наследует её от родителя

<nav ng-controller='menuCtrl'>
   <a ng-click='navigate()'>Жми меня!</a> <!-- also <nav>'s scope -->
</nav>

Третий – если элемент не является частью ng-app, то он не принадлежит ни к одной области видимости

<head>
   <h1>Приложение</h1>
</head>
<main ng-app='PonyDeli'>
   <nav ng-controller='menuCtrl'>
      <a ng-click='navigate()'>Жми меня!</a>
   </nav>
</main>

Чтобы понять, к какой области видимости принадлежит элемент, пройдитесь по дереву элементов изнутри наружу, используя три правила. Создаёт ли он новую область видимости? Тогда он связан именно с ней. Есть ли у него родитель? Проверяем родителя. Если он не входит в ng-app – тогда никакой области видимости.

Вызываем внутренние свойства областей видимости AngularJS

Пройдёмся по некоторым типичным свойствам. Для этого я открою Chrome и перейду к приложению, над которым работаю. Затем я открою Developer tools для просмотра свойств элемента. Знаете ли вы, что $0 даёт доступ к последнему выбранному элементу в панели «Elements»? $1 – предыдущий выбранный элемент, и т.д. $0 мы будем использовать чаще всего.

angular.element обёртывает каждый элемент DOM либо в jQuery, либо в jqLite. После этого у вас появляется доступ к функции scope(), возвращающей область видимости элемента. Скомбинируем это с $0 и получим часто используемую команду:

angular.element($0).scope()

Раз уж используется jQuery, то $($0).scope() тоже сработает. Теперь посмотрим, какие же свойства доступны в типичной области видимости – те, которые записываются начиная с $.

for(o in $($0).scope())o[0]=='$'&&console.log(o)

Изучаем внутренности области видимости AngularJS

Перечислю свойства, которые вывела эта команда, сгруппировав их по функциональности. Начнём с простых.

    $id
    идентификатор области видимости
    $root
    корневая область видимости
    $parent
    родительская область видимости, или null, если scope == scope.$root
    $$childHead
    область видимости первого дочернего узла, или null
    $$childTail
    область видимости последнего дочернего узла, или null
    $$prevSibling
    область видимости предыдущего узла этого же уровня, или null
    $$nextSibling
    область видимости следующего узла этого же уровня, или null

Навигация при помощи этих свойств – неудобная. Может иногда пригодиться $parent, но всегда есть более удобные способы обращаться к родительским элементам. Например, использование событий, которые мы рассмотрим в следующей части списка.

Событийная модель в области видимости AngularJS

Следующие свойства помогают определять события и подписываться на них.

    $$listeners
    обработчики событий, зарегистрированные в области видимости
    $on(evt, fn)
    присоединяет обработчик fn на событие evt
    $emit(evt, args)
    запускает событие evt, проходящее вверх по цепочке областей видимости, начиная с
текущего и заканчивая всеми родительскими $parent, включая $rootScope
    $broadcast(evt, args)
    запускает событие evt, проходящее вниз по цепочке областей видимости, начиная с
текущего и заканчивая всеми дочерними

При запуске, обработчики событий получают объект события и любые аргументы, переданные в $emit или $broadcast. Как же можно использовать события?

Директива может использовать их для сообщения о важном событии. В примере событие запускается по нажатию кнопки.

angular.module('PonyDeli').directive('food', function () {
   return {
      scope: { // К области видимости директив я ещё вернусь
         type: '=type'
      },
      template: '<button ng-click="eat()">Хочу поесть немножко {{type}}!</button>',
      link: function (scope, element, attrs) {
         scope.eat = function () {
            letThemHaveIt();
            scope.$emit('food.order, scope.type, element);
         };

         function letThemHaveIt () {
            // Возня с UI 
         }
      }
   };
});

Я задаю событиям пространства имён. Это предотвращает пересечение имён, и помогает понять, откуда приходят события или на какое событие вы подписываетесь. Предположим, вас интересует аналитика и вы хотите отследить все нажатия food через Mixpanel. Вместо замусоривания контроллера или директивы, вы можете сделать отдельную директиву для отслеживания нажатий, которая будет отдельной вещью в себе.

angular.module('PonyDeli').directive('foodTracker', function (mixpanelService) {
   return {
      link: function (scope, element, attrs) {
         scope.$on('food.order, function (e, type) {
            mixpanelService.track('food-eater', type);
         });
      }
   };
});

Реализация сервиса здесь не важна – она просто служила бы обёрткой клиентского API от Mixpanel. HTML выглядел бы так, как указано ниже, и я бы добавил ещё контроллер, содержащий все нужные типы еды. Для завершения примера я добавлю ng-repeat, чтобы можно было выводить списки еды, не копируя код. Просто выведем их циклом по foodTypes, который доступен в области видимости foodCtrl.

<ul ng-app='PonyDeli' ng-controller='foodCtrl' food-tracker>
   <li food type='type' ng-repeat='type in foodTypes'></li>
</ul>

angular.module('PonyDeli').controller('foodCtrl', function ($scope) {
   $scope.foodTypes = ['лучок', 'огурчик', 'орешек'];
});

Работающий пример смотрите на CodePen.

Но нужно ли вам событие, к которому сможет подключиться что угодно? Не будет ли достаточно сервиса? В этом случае можно сделать и так. Можно возразить, что события нужны, поскольку вы не знаете заранее, кто ещё будет подписываться на food.order, а значит, использование событий – более дальновидно с точки зрения развития приложения. Также можно сказать, что директива отслеживания еды не нужна, поскольку она не взаимодействует с DOM, а только ждёт события, поэтому её можно заменить на сервис.

И это верные замечания, в данном случае. Но когда и другим компонентам нужно будет общаться с food.order, станет ясна необходимость в событиях. В реальной жизни события наиболее полезны, когда вам надо соединить несколько областей видимости.

У элементов, находящихся на одном уровне, обычно общение друг с другом затруднено, и они обычно делают это через своего родителя. В результате это выливается в броадкастинг из $rootScope, который слушают все, кому это нужно:

<body ng-app='PonyDeli'>
   <div ng-controller='foodCtrl'>
      <ul food-tracker>
         <li food type='type' ng-repeat='type in foodTypes'></li>
      </ul>
      <button ng-click='deliver()'>Я хочу это съесть!</button>
   </div>
   <div ng-controller='deliveryCtrl'>
      <span ng-show='received'>
         Обезьяна уже выслана, скоро вы поедите.
      </span>
   </div>
</body>

angular.module('PonyDeli').controller('foodCtrl', function ($rootScope) {
   $scope.foodTypes = ['лучок', 'огурчик', 'орешек'];
   $scope.deliver = function (req) {
      $rootScope.$broadcast('delivery.request', req);
   };
});

angular.module('PonyDeli').controller('deliveryCtrl', function ($scope) {
   $scope.$on('delivery.request', function (e, req) {
      $scope.received = true; // обработка запроса
   });
});

Также можно посмотреть работу на CodePen.

Я бы сказал, что события нужно использовать, когда вы ожидаете изменения Вида в ответ на событие, а сервисы – когда Виды не меняются.

Если у вас две компоненты общаются через $rootScope, то лучше использовать $rootScope.$emit и $rootScope.$on вместо $broadcast. Тогда событие распространяется только среди $rootScope.$$listeners, и не будет терять время на проход всех дочерних узлов $rootScope, у которых нет обработчиков этого события. В примере сервис использует $rootScope для событий, не ограничиваясь определённой областью видимости. Он предоставляет метод subscribe для подписки на прослушивание событий.

angular.module('PonyDeli').factory("notificationService", function ($rootScope) {
   function notify (data) {
      $rootScope.$emit("notificationService.update", data);
   }

   function listen (fn) {
      $rootScope.$on("notificationService.update", function (e, data) {
         fn(data);
      });
   }

   // Всё, у чего есть смысл для создания событий в будущем
   function load () {
      setInterval(notify.bind(null, 'Что-то случилось!'), 1000);
   }

   return {
      subscribe: listen,
      load: load
   };
});

И это тоже есть на CodePen.

Digest

Привязка к данным у AngularJS работает посредством цикла, который отслеживает изменения и запускает события. В цикле $digest есть несколько методов. По-первых, это scope.$digest, рекурсивно переваривающий изменения в текущей области видимости и дочерних областях.

    $digest()
    исполняет цикл 
    $$phase
    текущая фаза цикла – один из вариантов [null, '$apply', '$digest']

Не стоит запускать digest, если вы уже находитесь в фазе digest – это приведёт к непредсказуемым последствиям. Что говорится по поводу digest в документации:

Запускает всех наблюдателей (watcher) в текущей области видимости и её дочерних областях. Поскольку слушатель (listener) наблюдателя может менять модель, $digest() вызывает наблюдателей до тех пор, пока их слушатели не перестанут выполняться. Это может привести к попаданию в бесконечный цикл. Поэтому функция выбросит ошибку 'Достигнуто максимальное количество итераций', если их количество превысит 10.

Обычно $digest() не вызывается напрямую из контроллеров или директив. Нужно вызывать $apply() (обычно это делают изнутри директив), который сам уже вызовет $digest().

Значит, $digest обрабатывает всех наблюдателей, и затем всех тех наблюдателей, которые вызываются предыдущими наблюдателями, до тех пор, пока они не перестанут выполняться. Остаётся два вопроса:

— кто такие наблюдатели?
— что вызывает $digest?

Возможно, вы уже знаете, что такое «наблюдатель» и использовали scope.$watch, а может даже и scope.$watchCollection. Свойство $$watchers содержит всех наблюдателей из области видимости.

    $watch(watchExp, listener, objectEquality)
    добавляет слушателя в область видимости
    $watchCollection
    наблюдает за элементами массива или свойствами объекта
    $$watchers
    содержит всех наблюдателей из области видимости

Наблюдатели – самый важный аспект AngularJS, но их вызов нужно инициировать, чтобы привязка данных отработала правильно. Пример:

<body ng-app='PonyDeli'>
   <ul ng-controller='foodCtrl'>
      <li ng-bind='prop'></li>
      <li ng-bind='dependency'></li>
   </ul>
</body>

angular.module('PonyDeli').controller('foodCtrl', function ($scope) {
   $scope.prop = 'начальное значение';
   $scope.dependency = 'пока ничего!';

   $scope.$watch('prop', function (value) {
      $scope.dependency = 'prop содержит "' + value + '"! ну ничего ж себе';
   });

   setTimeout(function () {
      $scope.prop = 'другое значение';
   }, 1000);
});

Значит, у нас есть 'начальное значение', и мы ожидаем, что вторая строка HTML поменяется на 'prop содержит «другое значение»! ну ничего ж себе', не так ли? И можно было бы ожидать, что первая строка поменяется на 'другое значение'. Почему она не меняется?

Многое из того, что вы создаёте в HTML, в результате создаёт наблюдателя. В нашем случае, каждая директива ng-bind создаёт наблюдателя для свойства. Она обновляет в HTML , когда prop и dependency меняются. Поэтому, в нашем коде есть три наблюдателя – по одному на каждый ng-bind, и один для контроллера. Откуда AngularJS узнает, что свойство обновилось после таймаута? Можно напомнить ему об этом, добавив вызов digest на обратный вызов таймера:

setTimeout(function () {
   $scope.prop = 'другое значение';
   $scope.$digest();
}, 1000);

Я сохранил два примера на CodePen – один без $digest, а второй – с ним. Но более правильный способ – использовать сервис $timeout вместо setTimeout. Он даёт возможность обработки ошибок и выполняет $apply().

$timeout(function () {
   $scope.prop = 'другое значение';
}, 1000);
    $apply(expr)
    разбирает и вычисляет выражение, и выполняет цикл $digest по $rootScope

Теперь по поводу того, кто вызывает $digest. Эти функции вызываются самим AngularJS в стратегических местах кода. Их можно вызвать напрямую, или через вызов $apply(). Большинство директив фреймворка вызывают эти функции. Они вызывают наблюдателей, а наблюдатели обновляют интефейс.

Посмотрим на список свойств, связанных с циклом $digest, которые можно обнаружить в области видимости.

    $eval(expression, locals)
    разбор и немедленное выполнение выражения
    $evalAsync(expression)
    разбор и отложенное выполнение выражения
    $$asyncQueue
    асинхронная очередь задач, обрабатывается на каждом цикле digest
    $$postDigest(fn)
    выполняет fn после следующего цикла digest 
    $$postDigestQueue
    зарегистрированные при помощи $$postDigest(fn) методы

Вот ещё несколько свойств области видимости, имеющие дело с её жизненным циклом и обычно используемые для внутренних целей. Но в некоторых случаях может потребоваться создание новых областей видимости через $new.

    $$isolateBindings
    изоляция привязок области видимости (к примеру, { options: '@megaOptions' } 
    $new(isolate)
    создаёт дочернюю область видимости или изолированную область, которая не будет наследником родителя
    $destroy
    удаляет область видимости из цепочки областей. её дочерние области не будут получать информацию о событиях и их наблюдатели не будут выполняться
    $$destroyed
    была ли область видимости удалена

Во второй части статьи мы рассмотрим директивы, изолированные области видимости, трансклюзии, привязанные функции, компиляторы, контроллеры директив и другое.

Автор: SLY_G

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js