Анатомия большого углового приложения

На уровне служб запрос обрабатывается, необходимые данные изменяются, и все директивы получают новые данные (потому что они уже были связаны с директивами). Это работает благодаря циклу дайджеста. Большинство происходящих событий запускают цикл дайджеста, который затем обновляет представления. Если у вас есть событие , которое не запускает цикл дайджеста (например, слайдер слайда — событие), вы можете вызвать дайджест цикла вручную.

Держите это течет

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

Управление состоянием пользовательского интерфейса с использованием данных

Большее приложение Angular, вероятно, будет иметь различные состояния, в которых оно может оказаться. Нажатие на переключатель может привести к изменению вкладки, выбору продукта и выделению строки в таблице одновременно. Делать это на уровне DOM (например, манипуляции с jQuery) было бы плохой идеей, потому что вы теряете связь между вашими данными и представлением.

Поскольку мы уже создали хорошую архитектуру, давайте использовать ее для управления состоянием пользовательского интерфейса. Вы бы создали UIStateService на уровне сервисов . Эта служба будет хранить все соответствующие данные пользовательского интерфейса и изменять их при необходимости. Как уже объяснялось, эта служба будет предоставлять эти данные, но также будет отвечать за их изменение. Фасад слой затем передать все необходимые изменения в правильном обслуживании (ов).

Важно отметить, что UIStateService может не понадобиться. Поскольку представления зависят от данных, большую часть времени можно просто использовать эти данные и контролировать состояние представлений. Отдельная служба состояний имеет смысл, когда вам нужно управлять состоянием пользовательского интерфейса, которое полностью отделено от вашей модели.

Прозрачный код

Из языка в JavaScript есть много преимуществ. Несколько очевидных из них:

• Использование функций, которые появятся в более новых версиях ECMAScript
• Абстракция причуд JavaScript
• Ошибки времени компиляции
• Лучший инструмент

Вы можете перейти из будущих версий ECMAScript с помощью Babel или даже добавить поддержку ввода с помощью TypeScript или Flow . Вы не можете ошибиться ни с одним из этих вариантов, потому что, в конце концов, вы получите пригодный для использования JavaScript. Если какого-либо из инструментов больше не существует, вы можете продолжить работу с сгенерированным JavaScript.

Машинопись

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

Помимо обеспечения безопасности типов, TypeScript имеет действительно хорошую поддержку инструментов с такими редакторами, как Sublime, Visual Studio Code или WebStorm, которые предлагают автозаполнение, встроенную документацию, рефакторинг и т. Д. Большинство из них также имеют встроенный компилятор TypeScript, так что вы можете найти компиляцию ошибки при кодировании. Отличное автозаполнение и встроенная документация возможны благодаря файлам определения типа. Обычно вы получаете файл определения типа, помещаете его в свой проект и ссылаетесь на него — упомянутые функции работают сразу из коробки. Зайдите на DefinitiveTyped, чтобы увидеть, какие библиотеки и фреймворки поддерживаются (подсказка: шансы, вы найдете все библиотеки или фреймворки, которые вы там используете), а затем используйте tsd, чтобы легко установить их из CLI.

Команда Angular предлагает концепцию, в которой библиотеки напрямую включают файлы определения типа. Преимущества такого подхода двояки: нет необходимости искать файлы определения типа, а файл определения типа, который вы получаете с версией библиотеки, всегда соответствует API этой версии.

Чтобы быстро ознакомиться со всеми преимуществами разработки с использованием TypeScript, вы можете посмотреть это видео из Angular Connect .

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

Говоря о процессе сборки …

Наличие процесса сборки на месте

У вас есть процесс сборки, не так ли?

Если нет, выберите Grunt , Gulp , Webpack или любой другой инструмент для сборки / упаковки, с которым вы хотели бы работать, и приступайте к работе. В репозитории, сопровождающем эту статью, используется Gulp, так что вы можете получить представление о том, как код передается, упаковывается для Интернета и тестируется. Я не буду вдаваться в подробности об инструментах сборки, потому что есть много статей, детализирующих их.

тестирование

Вы должны протестировать все части вашего приложения.

Я часто вижу, что люди отказываются от тестирования шаблонов HTML, потому что у них есть интеграционные тесты. К сожалению, Angular не сообщит вам, если у вас есть опечатка где-то в вашем шаблоне, и интеграционные тесты могут стать большими и медленными очень быстро, но при этом не охватывают достаточно места (не говоря уже о времени, необходимом для их обслуживания).

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

Вероятно, для всех ваших тестовых случаев будет достаточно сочетать Karma в качестве тестового прогонщика и Jasmine в качестве тестового фреймворка. Тестирование в процессе сборки (между переносом и упаковкой) также позволит убедиться, что вы не представляете ошибки регрессии.

Тестирование директив означает отдельное тестирование определения директивы с сопровождающим ее шаблоном и контроллерами.
Контроллеры просты в тестировании, потому что они просто создаются с удалением всех их зависимостей, и вы можете сразу приступить к тестированию его внутренних компонентов. Большую часть времени вы будете просто проверять, делегированы ли ваши контроллеры правильному сервису на уровне фасада .
Создание директив и удаление их контроллера также легко, поскольку контроллер присутствует в скомпилированном элементе после компиляции Angular. Чтобы проверить, что происходит в шаблоне, измените макет контроллера или области действия и запустите цикл дайджеста. Новые значения должны присутствовать.

Тестирование сервисов на уровне фасадов или сервисов так же просто, потому что вы можете удалить каждую зависимость и действительно протестировать только тот код, который присутствует.

Это также основной вывод — тестовый код, который присутствует в компоненте, который вы тестируете. Тесты должны провалиться, если вы изменяете открытые методы компонента, но только тесты, связанные с этим компонентом, а не половину всех ваших тестов. Если написание тестов затруднительно, вы либо слишком много тестируете (и не занимаетесь имитацией), либо испытываете проблемы с архитектурой вашего приложения.

Пример из реального мира

Heroes of Warcraft является товарным знаком, а Hearthstone является товарным знаком или зарегистрированным товарным знаком Blizzard Entertainment, Inc. в США и / или других странах.

В рамках этой статьи вы можете ознакомиться с демонстрационным приложением и поиграть здесь .

Это приложение для управления колодами для карточных игр. В таких играх, как Hearthstone, Magic the Gathering и им подобных, игроки собирают колоды из постоянно растущей коллекции карт и сражаются друг против друга. Вы можете создавать колоды и управлять ими с помощью готового набора карт, изготовленных по заказу HearthCards .

Исходный репозиторий

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

Для начала клонируйте репозиторий и следуйте инструкциям README. Это собирается запустить ваш сервер и обслуживать скомпилированные модули Angular.

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

Вертикальное разделение

Приложение разделено на три вертикали: общая , колода менеджеров и колода . Каждая из этих вертикалей является угловым модулем. Общий модуль представляет собой утилиту модуль и получает вводит в другие модули.

Горизонтальное разделение

All verticals feature a similar structure which follows what we’ve already discussed here in the article. You’ll find the directories components and services where the components directory contains directives, controllers and templates making it the components layer and the services directory where you’ll find the facade and services layer.

Let’s explore the layers.

Services Layer

The deckmanager vertical is a good candidate because it features a data managing service and a UI state managing service. Each of these services has its own model consisting of objects that they’ll manage and provide.

DataService, further more, gets LocalStorageService from the common module. This is where separation of concerns pays off — the data (decks and cards in the decks) are going to be stored into local storage. Because our layers are decoupled, it’s easy to replace that storage service with something completely different.

If you take a look at the DataService in the deckbuilder vertical, you’ll see that we’re also injecting a PageValueExtractorService. That service allows us to have pre-populated data in HTML that gets parsed and used right away. This is a powerful technique that can make application startup much faster. Once again, it’s easy to see how trivial it is to combine data storage strategies and, if we decide to change the concept completely, our components won’t notice it. They just care about getting the right data, not how it got there.

Facade Layer

Let’s look at the facade layer and see how it works in practice.

// ... imports

export default class FacadeService implements IFacadeService {
    private dataService:IDataService;
    private uiStateService:IUIStateService;

    constructor(dataService:IDataService, uiStateService:IUIStateService) {
        this.dataService = dataService;
        this.uiStateService = uiStateService;
    }

    public getDecks():IDeck[] {
    return this.dataService.getDecks();
}

public createNewDeck(name:string):void {
    this.dataService.createNewDeck(name);
this.uiStateService.setShowNewDeckForm(false);
}

// ... rest of service
}

FacadeService.$inject = ['DataService', 'UIStateService'];

// ... imports

export default class DeckController {
    private facadeService:IFacadeService;

    constructor(facadeService:IFacadeService) {
        this.facadeService = facadeService;
    }

    public getDecks():IDeck[] {
        return this.facadeService.getDecks();
    }

    public addDeck():void {
        this.facadeService.setShowNewDeckForm(true);
    }

    public editDeck(deck:IDeck):void {
        this.facadeService.editDeck(deck);
    }

    public deleteDeck(deck:IDeck):void {
        this.facadeService.deleteDeck(deck);
    }
}

DeckController.$inject = ['FacadeService'];