Руководство по обеспечению качества компонентов Angular 1.5

 controller: function() { var vm = this; vm.$onDestroy = function() { // Reset or remove any event listeners or watchers } } 

Компоненты должны иметь четко определенный API

Чтобы настроить и инициализировать компонент с набором данных, компонент должен использовать привязки для принятия этих значений. Иногда это рассматривается как API-компонент, который представляет собой просто другой способ описания того, как компонент принимает входные данные.

Задача состоит в том, чтобы дать привязки краткие, но четкие имена. Иногда разработчики пытаются сократить имена, чтобы они были очень краткими, но это опасно для использования компонента. Представьте, что у нас есть компонент, который принимает символ акций в качестве входных данных, какой из этих двух лучше?

 bindings: { smb: '<', symbol: '<' } 

Надеюсь, вы думали, что symbol был лучше. Иногда разработчики также предпочитают добавлять префиксы компонентов и привязок, чтобы избежать конфликтов имен. Префикс компонентов имеет смысл, например, md-toolbar — это панель инструментов Material, но префикс всех привязок становится многословным и его следует избегать.

Компоненты должны испускать события

Для взаимодействия с другими компонентами компоненты должны генерировать пользовательские события. Существует много примеров использования службы и двусторонней привязки данных для синхронизации данных между компонентами, но события являются лучшим выбором при проектировании. События гораздо более эффективны в качестве средства связи со страницей (и основополагающей частью языка JavaScript и способа его работы в Angular 2, что не является совпадением).

События в Angular могут использовать $emit (вверх по дереву областей) или $broadcast (вниз по дереву областей). Вот краткий пример событий в действии.

 controller: function($scope, $rootScope) { var vm = this; vm.$onInit = function() { // Emits an event up to parents $scope.$emit('componentOnInit'); }; vm.$onDestroy = function() { // Emits an down child tree, from root $rootScope.$broadcast('componentOnDestroy'); }; } 

Существует две основные ситуации, в которых вам нужно будет общаться между компонентами: между компонентами, о которых вы знаете, и компонентами, о которых вы не знаете. Чтобы проиллюстрировать разницу, давайте представим, что у нас есть набор компонентов, которые помогают управлять вкладками на странице, и панель инструментов, которая имеет ссылку на соответствующую страницу справки.

 <my-toolbar></my-toolbar> <my-tabs> <my-tab title="Description"></my-tab> <my-tab title="Reviews"></my-tab> <my-tab title="Support"></my-tab> </my-tabs> 

В этой ситуации компоненты my-tabs и my-tab , вероятно, знают друг о друге, потому что они работают вместе, чтобы создать набор из трех разных вкладок. Однако компонент my-toolbar находится за пределами их понимания.

Всякий раз, когда выбирается другая вкладка (которая будет четной на экземпляре компонента my-tab ), компонент my-tabs должен знать об этом, чтобы он мог настроить отображение вкладок для отображения этого экземпляра. Компонент my-tab может отправлять событие до родительского компонента my-tabs . Этот тип связи похож на внутреннюю связь между двумя компонентами, которые работают вместе для создания единой возможности (интерфейс с вкладками).

Однако что, если my-toolbar хочет знать, какая вкладка выбрана в данный момент, чтобы она могла менять кнопку справки в зависимости от того, что видно? Событие my-tab никогда не достигнет my-toolbar потому что оно не является родительским. Поэтому другой вариант — использовать $rootScope для $rootScope события по всему дереву компонентов, что позволяет любому компоненту прослушивать и реагировать. Потенциальным недостатком здесь является то, что ваше событие теперь достигает каждого контроллера, и если другой компонент использует то же имя события, вы можете вызвать непреднамеренные эффекты.

Решите, какой из этих подходов имеет смысл для вашего варианта использования, но каждый раз, когда другому компоненту может понадобиться узнать о событии, вы, вероятно, захотите использовать второй вариант для отправки во все дерево компонентов.

Резюме

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

• Изолируйте свою логику. Сохраняйте как можно большую часть логики компонента как можно дальше от других аспектов приложения, чтобы обеспечить согласованность и качество.
• Держите компоненты простыми и ориентированными на одну роль. Они могут быть сложными компонентами, но различные задачи одного компонента должны быть логически связаны как единое целое.
• Используйте события жизненного цикла. Подключившись к жизненному циклу компонента, вы можете убедиться, что данные готовы в нужное время и что вы можете их очистить.
• Используйте односторонние и одноразовые привязки. По возможности односторонние привязки более эффективны и способствуют хорошему дизайну, а одноразовые привязки могут ускорить работу вашего приложения. Вы всегда можете использовать событие $onChanges жизненного цикла для просмотра изменений.
• Используйте события для общения. Компоненты могут взаимодействовать с помощью пользовательских событий, что соответствует принципам работы Angular 2 и лучшему дизайну.
• Иметь четко определенный API. Убедитесь, что ваши компоненты четко названы и просты для понимания.

Используете ли вы компоненты в своих приложениях Angular 1.x? Или вы собираетесь подождать, пока не совершите прыжок на Angular 2? Я хотел бы услышать о вашем опыте в комментариях ниже.