Pull to refresh
289.47
TINKOFF
IT’s Tinkoff — просто о сложном

5 вещей, которые я бы хотел знать, когда начинал использовать Angular

Reading time 14 min
Views 39K

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


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



Dependency Injection (DI)


Первое время я заходил в компонент и видел, что в конструкторе класса есть какие-то аргументы. Я провел небольшой анализ работы методов класса, и стало понятно, что это какие-то внешние зависимости. Но как они попали в класс? В каком месте вызвали конструктор?


Предлагаю сразу разобраться на примере, а для этого нам понадобится класс. Если в «обычном» JavaScript ООП присутствует с определенными «хаками», то вместе с ES6 появился и «настоящий» синтаксис. В Angular прямо из коробки используется TypeScript, в котором синтаксис примерно такой же. Поэтому далее предлагаю использовать его.


Представим, что в нашем приложении существует класс JokerService, который управляет шутками. Метод getJokes() возвращает список шуток. Допустим, мы его используем в трех местах. Как получить шутки в трех разных местах в коде? Есть несколько способов:


  1. Создавать экземпляр класса в каждом месте. Но зачем нам засорять память и создавать столько одинаковых сервисов? А если мест будет 100?
  2. Сделать метод статическим и получать данные с помощью JokerService.getJokes().
  3. Реализовать один из паттернов проектирования. Если нам нужно, чтобы сервис был один на все приложение, то это будет Singleton. Но для этого нужно написать новую логику в классе.

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


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


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


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


Если вы подумали, что можно просто создать объект и по ключу брать нужный сервис, то могу вас поздравить: вы только что поняли, как в целом работает Dependency Injection. Но давайте немного углубимся.


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


Dependency Injection в Angular


Как гласит документация, DI — важный паттерн дизайна приложения. Angular имеет собственный фреймворк для зависимостей, который используется в самом Angular для повышения эффективности и модульности.


Если говорить в общих понятиях, то Dependency Injection — это мощный механизм, при котором класс получает необходимые зависимости откуда-то извне, а не создает экземпляры самостоятельно.


Пусть синтаксис и файлы с расширением html вас не путают. Каждый компонент в Angular — это обычный объект JavaScript, экземпляр класса. Если говорить общими словами: когда вы вставляете компонент в шаблон — создается экземпляр класса компонента. Соответственно, в этот момент можно передать в конструктор нужные зависимости. А теперь рассмотрим пример:


@Component({
    selector: 'jokes',
    template: './jokes.template.html',
})
export class JokesComponent {
    private jokes: Observable<IJoke[]>;

    constructor(private jokerService: JokerService) {
        this.jokes = this.jokerService.getJokes();
    }
}

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


Providers


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


@Injectable({
    providedIn: 'root', // Здесь мы указываем, куда будет «подставлен» сервис
})
export class JokerService {
    getJokes(): Observable<IJoke[]> {
        // Наша логика получения шуток
    }
}

Когда сервис один на все приложение, будет достаточно этого варианта. Но что делать, если у нас есть, допустим, две реализации JokerService? Или просто по какой-то причине в определенном компоненте нужен свой экземпляр сервиса? Ответ прост: provider.


Для удобства дальше я буду называть provider провайдером, а сам процесс подстановки значения в класс — запровайдить. Так вот, мы можем запровайдить сервис разными способами и в разных местах. Начнем с последнего. Всего существует три доступных варианта:


  • Во все приложение — указываем provideIn: ‘root’ в самом декораторе сервиса.
  • В модуль — указываем провайдер в декораторе сервиса как provideIn: JokesModule или в декораторе модуля @NgModule как providers: [JokerService].
  • В компонент — указываем провайдер в декораторе компонента, как в модуле.

Место выбирается в зависимости от ваших потребностей. С местом разобрались, перейдем к самому механизму. Если мы просто указали provideIn: root в сервисе, это будет эквивалентно следующей записи в модуле:


@NgModule({
    // ... здесь другие свойства модуля
    providers: [{provide: JokerService, useClass: JokerService}],
})
// Рутовый модуль

Это можно прочитать примерно так: «Если запрашивается JokerService, то отдай экземпляр класса JokerService». Отсюда можно получить определенный экземпляр различными способами:


  • По токену — нужно указать InjectionToken и получать сервис по нему. Обратите внимание, что в примерах ниже в provide можно передать этот же токен:


    const JOKER_SERVICE_TOKEN = new InjectionToken<string>('JokerService');
    
    // ... Здесь модуль или компонент
    
    [{provide: JOKER_SERVICE_TOKEN, useClass: JokerService}];

  • По классу — можно подменить класс. Например, мы будем просить JokerService, а отдавать — JokerHappyService:


    [{provide: JokerService, useClass: JokerHappyService}];

  • По значению — можно сразу вернуть нужный экземпляр:


    [{provide: JokerService, useValue: jokerService}];

  • По фабрике — можно подменить класс фабрикой, которая будет создавать нужный экземпляр при обращении:


    [{provide: JokerService, useFactory: jokerServiceFactory}];


Вот и все. То есть для решения примера со специальным экземпляром можно использовать любой из перечисленных выше способов. Выбирайте наиболее подходящий под ваши потребности.


Кстати, DI работает не только для сервисов, а вообще для любой сущности, которую вы получаете в конструкторе компонента. Это очень мощный механизм, который следует использовать на полную.


Небольшой итог


Для полного понимания предлагаю рассмотреть упрощенный механизм Dependency Injection в Angular по шагам на примере сервиса:


  1. При инициализации приложения у сервиса есть токен. Если мы не указали его специально в провайдере, то это JokerService.
  2. При запросе сервиса в компоненте механизм DI проверяет, существует ли переданный токен.
  3. Если токена не существует, то DI кинет ошибку. В нашем случае токен существует и по нему находится JokerService.
  4. В момент создания компонента в конструктор в качестве аргумента передается экземпляр JokerService.

Change Detection


Мы часто слышим в качестве аргумента для использования фреймворков что-то вроде «Фреймворк все сделает за вас — быстрее и эффективнее. Вам не нужно ни о чем думать. Просто управляйте данными». Возможно, это действительно так в отношении очень простого приложения. Но если приходится работать с пользовательским вводом и постоянно оперировать данными, то знать, как работает процесс обнаружения изменений и рендеринга, просто необходимо.


В Angular за проверку изменений отвечает механизм Change Detection. В результате различных операций — изменение значения свойства класса, завершение асинхронной операции, ответ на HTTP-запрос и так далее — запускается процесс проверки по всему дереву компонентов.


Так как главная цель процесса — понять, как перерендерить компонент, то суть заключается в проверке данных, используемых в шаблонах. Если они разные, то шаблон помечается как «измененный» и будет перерисован.


Zone.js


Понять, как Angular следит за свойствами класса и синхронными операциями, довольно просто. Но как он отслеживает асинхронные? За это отвечает библиотека Zone.js, созданная одним из разработчиков Angular.


Вот что это такое. Зона сама по себе — это «контекст выполнения», если выражаться грубо — место и состояние, в котором выполняется код. После выполнения асинхронной операции функция обратного вызова (callback) выполняется в той же зоне, где была зарегистрирована. Так Angular узнает, в каком месте произошло изменение и что следует проверить.


Zone.js заменяет своими реализациями практически все нативные асинхронные функции и методы. Поэтому она может отследить момент, когда будет вызван callback асинхронной функции. То есть Zone сообщает Angular, когда и где нужно запустить процесс проверки изменений.


Стратегии обнаружения изменений


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


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


Всего на выбор два варианта:


  • Default — как можно догадаться из названия, это стратегия по умолчанию, когда на каждое действие запускается CD.
  • OnPush — стратегия, при которой CD запускается лишь в нескольких случаях:
    • если изменилось значение @Input();
    • если произошло событие внутри компонента или его потомков;
    • если проверка была запущена вручную;
    • если в Async Pipe приходит новое событие.

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


  • Четкое понимание, как работает процесс CD.
  • Аккуратная работа с @Input() свойствами.
  • Прирост производительности.

Работа с @Input()


Как и в других популярных фреймворках, в Angular используется нисходящий поток данных. Компонент принимает входные параметры, которые помечаются декоратором @Input(). Рассмотрим на примере:


interface IJoke {
    author: string;
    text: string;
}

@Component({
    selector: 'joke',
    template: './joke.template.html',
})
export class JokeComponent {
    @Input() joke: IJoke;
}

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


setAuthorNameOnly() {
    const name = this.joke.author.split(' ')[0];

    this.joke.author = name;
}

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


@Component({
    selector: 'joke',
    template: './joke.template.html',
    changeDetection: ChangeDetectionStrategy.OnPush,
})
export class JokeComponent {
    @Input() readonly joke: IJoke;
    @Output() updateName = new EventEmitter<string>();

    setAuthorNameOnly() {
        const name = this.joke.author.split(' ')[0];

        this.updateName.emit(name);
    }
}

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


RxJS


Конечно, я могу ошибаться, но складывается ощущение, что ReactiveX и реактивное программирование в целом — это новый тренд. Angular поддался этому тренду (а может, и создал его) и использует RxJS по умолчанию. Базовая логика всего фреймворка работает на данной библиотеке, поэтому очень важно понимать принципы реактивного программирования.


Но что такое RxJS? Он объединяет три идеи, которые я раскрою довольно простым языком с некоторыми упущениями:


  • Паттерн «Наблюдатель» — сущность, которая производит события, и есть слушатель, который получает информацию об этих событиях.
  • Паттерн «Итератор» — позволяет получить последовательный доступ к элементам объекта, не раскрывая его внутренней структуры.
  • Функциональное программирование с коллекциями — паттерн, при котором логика бьется на маленькие и очень простые составные части, каждая из которых решает только одну задачу.

Объединение этих паттернов позволяет нам очень просто описывать сложные с первого взгляда алгоритмы, например:


private loadUnreadJokes() {
    this.showLoader(); // Ставим лоадер

    fromEvent(document, 'load')
        .pipe(
            switchMap(
                () =>
                    this.http
                        .get('/api/v1/jokes') // Запрашиваем шутки
                        .pipe(map((jokes: any[]) => jokes.filter(joke => joke.unread))), // Фильтруем непрочитанные
            ),
        )
        .subscribe(
            (jokes: any[]) => (this.jokes = jokes), // Ставим шутки
            error => {
                /* Обработка ошибки */
            },
            () => this.hideLoader(), // Скрываем лоадер вне зависимости от результата
        );
}

Всего 18 строк со всеми красивыми отступами. А теперь попробуйте переписать этот пример на Vanilla или хотя бы на jQuery. Почти 100% у вас это займет как минимум в два раза больше места и будет не так выразительно. Здесь же вы можете просто идти глазами по строке и читать код как книгу.


Observable


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


const observable = [];
let counter = 0;

const intervalId = setInterval(() => {
    observable.push(counter++);
}, 1000);

setTimeout(() => {
    clearInterval(intervalId);
}, 6000);

Мы будем считать актуальным последнее значение в массиве. Каждую секунду в массив будет добавляться число. Как мы можем узнать в другом месте приложения, что в массив был добавлен элемент? В обычной ситуации мы вызывали бы какой-нибудь callback и по нему обновляли значение массива, а затем просто брали бы последний элемент.


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


document.addEventListener('click', event => {});

Вы можете поставить много EventListener'ов во всем приложении, и они все будут отрабатывать, если вы, конечно, не позаботились об обратном специально.


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


Теперь давайте посмотрим на реальный пример:


export class JokesListComponent implements OnInit {
    jokes$: Observable<IJoke>;
    authors$ = new Subject<string[]>();
    unread$ = new Subject<number>();

    constructor(private jokerService: JokerService) {}

    ngOnInit() {
        // Обратите внимание, я не использую subscribe() в этом месте
        this.jokes$ = this.jokerService.getJokes();

        this.jokes$.subscribe(jokes => {
            this.authors$.next(jokes.map(joke => joke.author));
            this.unread$.next(jokes.filter(joke => joke.unread).length);
        });
    }
}

Благодаря такой логике при изменении данных в jokes у нас автоматически обновятся данные по количеству непрочитанных шуток и список авторов. Если у вас есть еще пара компонентов, один из которых собирает статистику по количеству прочитанных шуток одного автора, а второй вычисляет среднюю длину шуток, то преимущества становятся очевидными.


TestBed


Рано или поздно разработчик понимает, что если проект — не MVP, то нужно писать тесты. И чем больше тестов будет написано, чем понятнее и подробнее у них описание, тем проще, быстрее и надежнее вносить изменения и реализовывать новый функционал.


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


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


Как мы уже выяснили, благодаря DI зависимости берутся вне компонента. С одной стороны, это немного усложняет всю систему, с другой — дает нам большие возможности для настройки тестов и проверки множества кейсов. Предлагаю разобраться на примере компонента:


@Component({
    selector: 'app-joker',
    template: '<some-dependency></some-dependency>',
    styleUrls: ['./joker.component.less'],
})
export class JokerComponent {
    constructor(
        private jokesService: JokesService,
        @Inject(PARTY_TOKEN) private partyService: PartyService,
        @Optional() private sleepService: SleepService,
    ) {}

    makeNewFriend(): IFriend {
        if (this.sleepService && this.sleepService.isSleeping) {
            this.sleepService.wakeUp();
        }

        const joke = this.jokesService.generateNewJoke();

        this.partyService.goToParty('Pacha');
        this.partyService.toSay(joke.text);

        const laughingPeople = this.partyService.getPeopleByReaction('laughing');
        const girl = laughingPeople.find(human => human.sex === 'female');
        const friend = this.partyService.makeFriend(girl);

        return friend;
    }
}

Итак, в текущем примере есть три сервиса. Один импортится обычным способом, один — по токену и еще один сервис опционален. Как мы сконфигурируем тестовый модуль? Я покажу сразу готовый вид:


beforeEach(async(() => {
    TestBed.configureTestingModule({
        imports: [SomeDependencyModule],
        declarations: [JokerComponent], // Самое главное, что необходимо указать
        providers: [{provide: PARTY_TOKEN, useClass: PartyService}],
    }).compileComponents();

    fixture = TestBed.createComponent(JokerComponent);
    component = fixture.componentInstance;
    fixture.detectChanges(); // Необходимо только в случае, если вы проверяете верстку
}));

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


Можно избегать лишних зависимостей


Приложение на Angular состоит из модулей, которые могут включать в себя другие модули, сервисы, директивы и прочее. В тесте нам необходимо, по сути, воссоздать работу модуля. Если в нашем примере мы используем в шаблоне <some-dependency></some-dependency>, это значит, что мы должны импортировать SomeDependencyModule и в тест. А если там есть свои зависимости? Значит, и их тоже нужно импортировать.
Если приложение сложное, таких зависимостей будет масса. Импорт всех зависимостей приведет к тому, что в каждом тесте будет находиться вообще все приложение и будут вызываться все методы. Наверное, нам такое не подходит.


Существует как минимум один способ избавиться от нужных зависимостей — просто переписать шаблон. Допустим, у вас есть скриншот-тестирование или интеграционные тесты и нет необходимости тестировать внешний вид компонента. Тогда достаточно просто проверить работу методов. В этом случае можно написать конфигурацию следующим образом:


TestBed.configureTestingModule({
    declarations: [JokerComponent],
    providers: [{provide: PARTY_TOKEN, useClass: PartyService}],
})
    .overrideTemplate(JokerComponent, '') // Шаблон теперь пустой, без зависимостей
    .compileComponents();

Да, это подойдет не всем. Внутри Тинькофф мы договорились использовать такой подход только в тех случаях, когда нет необходимости проверять отображение компонента. Например, когда ведется только работа с данными или общение со стором. Если есть необходимость проверять, как передаются данные в дочерние компоненты или, например, как обрабатывается пользовательский ввод, то этот вариант не подойдет. Если у вас как раз такой случай — переходим к следующему пункту.


Можно мокировать все зависимости из конструктора


Мы уже ознакомились с Injection Token, поэтому предлагаю сразу перейти к делу. В примере выше я уже запровайдил в тест сервис по токену. Если вы пишете не интеграционный тест, то смысла вызывать методы реального сервиса нет, просто сделайте мок.


Для этого можно использовать специальные библиотеки вроде ts-mockito, которые существенно облегчат вам жизнь, но это не обязательно. Angular предоставляет массу возможностей «из коробки».


// Создаем моковый сервис
export class MockPartyService extends PartyService {
    meetFriend(): IFriend {
        return {} as IFriend;
    }

    goToParty() {}

    toSay(some: string) {
        console.log(some);
    }
}

// ...

TestBed.configureTestingModule({
    declarations: [JokerComponent, MockComponent],
    providers: [{provide: PARTY_TOKEN, useClass: MockPartyService}], // Просто провайдим его
}).compileComponents();

Вот и все. Так же можно поступить с любой зависимостью из конструктора.


Множество кейсов


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


  • Как будет работать логика при наличии и отсутствии опционального сервиса.
  • Если сервис импортируется по токену — следовательно, могут быть использованы разные его версии. Если тест интеграционный — нужно учесть все варианты.

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


Итог


Мы ознакомились с некоторыми базовыми механизмами Angular, знаний о которых мне не хватало в самом начале моего пути. Чтобы подробно раскрыть каждый механизм, нужна отдельная статья, которые есть в том числе и на «Хабре».


В отличие от других современных фреймворков, Angular часто предлагает уже готовые способы реализации какого-либо механизма. Это могут быть HTTP-запросы, роутинг, lazy-loading и прочее. Поэтому я призываю всех прочитать или хотя бы пробежать глазами официальную документацию Angular.

Tags:
Hubs:
+41
Comments 68
Comments Comments 68

Articles

Information

Website
www.tinkoff.ru
Registered
Founded
Employees
over 10,000 employees
Location
Россия