Angular 1 против Angular 2 — Сравнение высокого уровня

Больше не нужно $scope.applyили $scope.digestвсе прозрачно работает. Вероятно, в большинстве случаев нам не придется рассуждать о зонах в целом, и все равно будет возможно запускать код за пределами угловой зоны, используя VmTurnZone .

Цель: повышение производительности

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

Но неясно, что эти улучшения производительности могут пойти гораздо дальше, одной из причин этого является возможность существования циклов обнаружения изменений.

Чтобы лучше понять, как достигается прирост производительности (в 5-10 раз быстрее, чем в Angular 1), лучше обратиться к этому подкасту и  сообщению в блоге . Я постараюсь обобщить две основные причины, по которым Angular 2 намного быстрее:

Быстрая проверка одиночной привязки

Механизм проверки одиночной привязки был оптимизирован, чтобы позволить виртуальной машине Javascript оптимизировать этот код в нативный код путем своевременной компиляции. Вместо рекурсивного сканирования дерева объектов при запуске Angular создается функция, чтобы увидеть, изменилась ли привязка.

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

Избегайте сканирования частей дерева компонентов

Angular 2 позволит разработчику предоставить некоторые гарантии механизму обнаружения изменений, чтобы избежать сканирования частей дерева компонентов. В основном у разработчика будет два варианта:

• сделайте модель наблюдаемой: Angular обнаружит это и зарегистрирует себя, чтобы наблюдать за моделью. Таким образом, если модель изменится / останется такой же, Angular узнает об этом через наблюдаемый механизм, и поэтому не нужно запускать обнаружение изменений для этого объекта.
• сделать модель неизменной, используя, например, файл immutable.js от Facebook  . Опять же, идея заключается в том, что Angular обнаружит это и избежит запуска обнаружения изменений на неизменяемых объектах.

Цель: улучшенная модульность

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

Эти модули, например, не загружаются асинхронно на основе их списков зависимостей при первой необходимости зависимости, как, например, модули AMD.

Угловой 1 и модуль Lazy-loading

Ленивая загрузка в Angular 1 все еще возможна с помощью решения, подобного ocLazyLoad , но в идеале это должно быть что-то родное для фреймворка и более прозрачное, и в соответствии с этим подкастом кажется, что в Angular 2 это будет иметь место (см. В 13:06) ,

Улучшения в npm в качестве менеджера пакетов Frontend

Также в целом команда Angular стремится улучшить npm, чтобы сделать его более дружественным для внешнего интерфейса, не только для Angular, но и для любой библиотеки внешнего интерфейса в целом.

Angular 2 не форсирует это, но если мы решим сделать это, мы сможем воспользоваться новым загрузчиком модулей ES6, который является стандартным асинхронным загрузчиком модулей, который уже может быть использован через pollyfill es6-module-loader  .

Цель: улучшенная инъекция зависимостей

Внедрение зависимостей Angular 1 — это скачок в создании более модульных приложений, но у него есть пара угловых случаев, которые невозможно исправить без серьезных серьезных изменений.

Angular 1 имеет глобальный пул объектов

Один из ключевых моментов DI в Angular 1 состоит в том, что в приложении имеется только один глобальный пул объектов. Это означает, что если, например, основной маршрут загружается, backendServiceи мы переходим к маршруту B, мы можем там лениво загружать другие службы, специфичные для этого маршрута.

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

Angular 1 перезаписывает модули, если они имеют одинаковое имя

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

В Angular 1 есть несколько механизмов DI

В Angular 1 мы можем вводить зависимости в разных местах разными способами:

• в функции связи по позиции
• в определении директивы по имени
• в функции контроллера по имени и т. д.

В Angular 2 есть цель объединить эти механизмы в единый механизм, чтобы уменьшить кривую обучения и улучшить читаемость.

Как Angular 2 DI улучшит ситуацию

В Angular 2 будет только один механизм DI: инжекция конструктора по типу.

    constructor(keyUtils: KeyboardUtils) {
        this.keyUtils = keyUtils;
    }
});

<ng1-component>
     <web-component-widget setting="{{angularExpresssion}}"></web-component-widget> 
</ng1-component>

<ng2-component>  
     <web-component-widget [setting]="angularExpresssion"></web-component-widget>
</ng2-component>