Я только начал с Angular и прочитал много руководств. Теперь бесплатный в CodeSchool, который был моей отправной точкой $scope , вообще не упоминается.

Из того, что я собрал, controllerAs синтаксис относительно новый (1.2.0), но, похоже, он позволяет вам обойтись без $scope прямого использования.

В некоторых статьях говорится «использовать controllerAs » с объяснением, но большинство просто используют $scope . Но я не смог найти никакого объяснения, почему они выбрали это.

Это сейчас в основном случай предпочтения одного над другим или все еще есть причины для использования $scope ?

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

редактировать: чтобы уточнить, я хочу знать, когда использовать $scope , а не причины не использовать его 🙂

В документации Angular для ngController объясняются преимущества использования ‘controller as’ по сравнению с введением $scope . Вот что он говорит:

• Использование controller as делает очевидным, к какому контроллеру вы обращаетесь в шаблоне, когда к элементу применяются несколько контроллеров.
• Если вы пишете свои контроллеры как классы, вам будет проще получить доступ к свойствам и методам, которые будут отображаться в области видимости, изнутри кода контроллера.
• Поскольку всегда есть . в привязках вам не нужно беспокоиться о маскирующих примитивах прототипного наследования.

Со своей стороны, я обнаружил, что использование ‘controller as’ весьма полезно, поскольку это заставляет меня задуматься, будет ли код, который я добавляю в контроллер, более уместно добавлять в сервис или директиву.

Например: часы. Часы — это то, чего вам следует избегать в контроллерах, но легкий доступ к $scope позволяет вам легко их настраивать. Использование ‘controller as’ заставило меня более тщательно подумать о том, действительно ли мне нужно выполнять watch. Обычно наблюдение может быть выполнено с помощью директивы. Это привело меня к созданию контроллеров меньшего размера, которые только настраивают начальное состояние и взаимодействуют со службами, шаблон, который я нашел гораздо более производительным и удобным в обслуживании.

Лучший ответ, который я могу вам дать, это:

Короткое:

• Всякий раз, когда вы хотите предоставить логику шаблону, используйте Scope .
• Всякий раз, когда вы хотите сохранить логику для элемента, используйте ngController .
• Если вы хотите предоставить значения вашего контроллера непосредственно в шаблоне (через область видимости), используйте «контроллер как синтаксис».

Длинный:

Объяснение

Scope или $scope , как вы выразились, это место, где мы поддерживаем значения (независимо от типа: функция, объект, строка и т.д.), Которые могут быть доступны шаблону в этой области. Например, рассмотрим следующее:

HTML-код:

 <div ng-controller="MyCtrl">
  <div>{{ message }}</div>
</div>

<div ng-controller="MyCtrl as ctrl">
  <div>{{ ctrl.message }}</div>
</div>
  

Видите эти интерполяции? Ну, угадайте, что? Они оба получают доступ Scope . «Контроллер как синтаксис» создает псевдоним для MyCtrl и публикует его в локальной области. Как только элемент будет связан, если вы посмотрите $scope , вы действительно найдете свойство ctrl , которое предоставляет доступ к контроллеру.

Javascript

 function MyCtrl($scope) {
  $scope.message = "controller MyCtrl";
  this.message = "controller as syntax";
}
  

Где бы я ни использовал MyCtrl , эти два сообщения доступны. Но для быстрого доступа к значению на самом контроллере мы используем синтаксис «контроллер как псевдоним».

Честно говоря, это две разные методологии. Синтаксис контроллера как * позволяет разработчику поместить контроллер в область видимости и упростить доступ к указанному контроллеру. Итак, в конце концов, все заканчивается в области видимости. В противном случае, скажем, через функцию ссылки директивы, вы должны получить доступ к контроллеру к require свойству. Методы и свойства контроллера не обязательно должны быть доступны шаблону, а просто использоваться в логике.(Кроме того, вы также можете получить доступ к контроллеру через функцию data() jqLite).

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

Область действия против Контроллер

Главное, что следует учитывать, это то, что дочерний контроллер может наследовать область его родительского. Самое интересное, что дочерняя область будет наследовать этот бит свойств родительского контроллера от родительского.

 <!-- ctrl1 -->
<div ng-controller="MyCtrl as ctrl1">
  <div>{{ ctrl1.message }}</div>
  <!-- ctrl2 -->
  <div ng-controller="MyCtrl as ctrl2">
    <div>{{ ctrl2.message }}</div>
  </div>
</div>
  

Обратите внимание, что оба используют один и тот же контроллер, но у них разные псевдонимы. Теперь свойства контроллера передаются дочерним элементам через Scope . Таким образом, дочерний элемент может получить доступ к родительскому элементу через его псевдоним. Итак, с помощью этого синтаксиса вы можете четко видеть разделение двух экземпляров MyCtrl . Они оба имеют message свойство в своих областях, но их легко отличить, не копаясь в родителях, дочерних элементах, братьях и сестрах и т. Д.

В заключение

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

Как указано в документации Angular, преимущества

• Использование controller as делает очевидным, к какому контроллеру вы обращаетесь в шаблоне, когда к элементу применяются несколько контроллеров.
• Если вы пишете свои контроллеры как классы, вам будет проще получить доступ к свойствам и методам, которые будут отображаться в области видимости, изнутри кода контроллера.
• Поскольку всегда есть . в привязках вам не нужно беспокоиться о маскирующих примитивах прототипного наследования.

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

Я прочитал несколько блогов и пришел к выводу, что для целей использования не следует смешивать $ scope и this. Для этого есть причина, «this» и $scope могут отличаться, они не всегда одинаковы, например, если я определил контроллер для «this» и вызываю в нем другой контроллер, тогда $scope будет установлен на контроллер, который я вызвал, но «this» всегда будетбыть текущим контекстом, который является контроллером, в котором я вызвал другой контроллер. Таким образом, в этом случае $scope и «this» не будут одинаковыми, и их взаимозаменяемое использование здесь может привести к некоторому непредсказуемому поведению.

Пожалуйста, поправьте меня, если я ошибаюсь.