Как обычно используется DI в Angular

1. Получить сущности Angular из дерева зависимостей: ChangeDetectorRef, ElementRef и проч.
2. Получить сервис, чтобы использовать его в компоненте.
3. Получить какой-нибудь глобальный конфиг по токену, который объявлен где-то наверху. Например, задать токен API_URL в рутовом модуле и получать его из DI в любом месте приложения при необходимости.

import {DOCUMENT} from '@angular/common';import {inject, InjectionToken} from '@angular/core';export const WINDOW = new InjectionToken<Window>(    'An abstraction over global window object',    {        factory: () => {            const {defaultView} = inject(DOCUMENT);            if (!defaultView) {                throw new Error('Window is not available');            }            return defaultView;        },    },);

Частные провайдеры

@Component({   selector: 'organization',   templateUrl: 'organization.template.html',   styleUrls: ['organization.style.less'],   changeDetection: ChangeDetectionStrategy.OnPush,})export class OrganizationComponent implements OnInit {   organization: Organization;   constructor(       private readonly activatedRoute: ActivatedRoute,       private readonly organizationService: OrganizationService,   ) {}   ngOnInit() {       this.activatedRoute.params           .pipe(               switchMap(params => {                   const id = params.get('orgId');                   return this.organizationService.getOrganizationById$(id);               }),           )           .subscribe(organization => {               this.organization = organization;           });   }}

<p *ngIf="organization">   {{organization.name}} from {{organization.city}}</p>

@Component({   selector: 'organization',   templateUrl: 'organization.template.html',   styleUrls: ['organization.style.less'],   changeDetection: ChangeDetectionStrategy.OnPush,})export class OrganizationComponent {   readonly organization$: Observable<Organization> = this.activatedRoute.params.pipe(       switchMap(params => {           const id = params.get('orgId');           return this.organizationService.getOrganizationById$(id);       }),   );   constructor(       private readonly activatedRoute: ActivatedRoute,       private readonly organizationService: OrganizationService,   ) {}}

<p *ngIf="organization$ | async as organization">   {{organization.name}} from {{organization.city}}</p>

Сделаем еще круче: частные провайдеры

export const ORGANIZATION_INFO = new InjectionToken<Observable<Organization>>(   'A stream with current organization information',);По этому токену будет идти стрим с необходимой компоненту информацией:export const ORGANIZATION_PROVIDERS: Provider[] = [   {       provide: ORGANIZATION_INFO,       deps: [ActivatedRoute, OrganizationService],       useFactory: organizationFactory,   },];export function organizationFactory(   {params}: ActivatedRoute,   organizationService: OrganizationService,): Observable<Organization> {   return params.pipe(       switchMap(params => {           const id = params.get('orgId');           return organizationService.getOrganizationById$(id);       }),   );}

{       provide: ACTIVE_TAB,       deps: [           [new Optional(), new Self(), RouterLinkActive],       ],       useFactory: activeTabFactory,}

@Component({   ..   providers: [ORGANIZATION_PROVIDERS],})

@Component({   selector: 'organization',   templateUrl: 'organization.template.html',   styleUrls: ['organization.style.less'],   changeDetection: ChangeDetectionStrategy.OnPush,   providers: [ORGANIZATION_PROVIDERS],})export class OrganizationComponent {   constructor(       @Inject(ORGANIZATION_INFO) readonly organization$: Observable<Organization>,   ) {}}

<p *ngIf="organization$ | async as organization">   {{organization.name}} from {{organization.city}}</p>

1. Чистые зависимости: компонент не внедряет в себя и не хранит лишних сущностей. Он работает только с теми данными, которые ему нужны, при этом сам остается чистым и содержит только логику для отображения данных.
   
2. Простота тестирования: мы можем легко протестировать сам провайдер, потому что его фабрика обычная функция. Нам легче тестировать компонент: в тестах нам не нужно будет собирать дерево зависимостей и подменять много сущностей мы просто передадим по токену ORGANIZATION_INFO стрим с мокаными данными.
   
3. Готовность к изменению и расширению: если компонент будет работать с другим типом данных, мы поменяем лишь одну строчку. Если нужно будет изменить преобразование поменяем фабрику. Если потребуется добавить новых данных, то добавим еще один токен мы можем сложить сколько угодно токенов в наш массив провайдеров.
   

Заключение

• Распил приложения на более мелкие продукты со своими релизными циклами.
  
• Покрытие продукта тестами в соответствии с тестовой пирамидой.
  

Пирамида тестирования

1. Очень подробная документация.
   
2. Легкий debugging тестов (у Cypress для этого сделан специальный GUI с time-travel по шагам в тесте).
   

Начало пути

1. В index.html были зашиты некоторые скрипты, которые не нужны в интеграционных тестах.
   
2. Для запуска интеграционных тестов необходимо было убедиться, что сервер с приложением запущен.
   

"build": {..."configurations": { // Другие конфигурации"cypress": {"aot": true,"index": "projects/main-app-integrations/src/fixtures/index.html","fileReplacements": [{"replace": "projects/main-app/src/environments/environment.ts","with": "projects/main-app/src/environments/environment.prod.ts"}]}}}

"serve": {..."configurations": { // Другие конфигурации"cypress": {"browserTarget": "main-app:build:cypress"}}}

"main-app:cy:run": "cypress run","main-app:cy:open": "cypress open","main-app:integrations": "start-server-and-test main-app:serve:cypress http://localhost:8808/app/user/ main-app:cy:run","main-app:integrations:open": "start-server-and-test main-app:serve:cypress http://localhost:8808/app/user/ main-app:cy:open"

Монорепозиторий

1. У вас есть приложение, например main-app, рядом с ним создается приложение main-app-e2e.
   
2. Переименуйте main-app-e2e в main-app-integrations вы восхитительны.
   

1. Создаем рядом с вашим приложением папку main-app-integrations.
   
2. Создаем в ней папку src и заносим в нее содержимое папки cypress.
   
3. Не забываем перенести cypress.json (изначально он появится в корне) в папку main-app-integrations.
   
4. Правим cypress.json, указывая пути до новых папок с тестами, плагинами и вспомогательными командами (параметры integrationFolder, pluginsFile и supportFile).
   
5. Cypress умеет работать с тестами в любых папках, для указания папки используется параметр
   project, поэтому меняем команду с cypress run/open на cypress run/open -project ./projects/main-app-integrations/src.
   

Visual Regressing

Cypress.Commands.overwrite('matchImageSnapshot',(originalFn, subject, fileName, options) => {if (Cypress.env('ci')) {return originalFn(subject, fileName, options);}return subject;},);

Шрифты

Неправильное решение

Правильное решение

FROM cypress:included:4.3.0COPY package.json /app/COPY package-lock.json app/WORKDIR /appRUN npm ciCOPY / /app/ENTRYPOINT []

docker build -t integrations -f integration-tests.Dockerfile .docker run --rm -v $PWD/projects/main-app-integrations/src:/app/projects/main-app-integrations/src integrations:latest npm run main-app:integrations

Снова шрифты

Неправильное решение

Правильное решение

<linkrel="preload"href="...."as="font"type="font/woff2"crossorigin="anonymous"/>

Анимации

Первое решение

Второе решение

Cypress.Commands.add('waitStableState', () => {return cy.window().then(window => {const [testability]: [Testability] = window.getAllAngularTestabilities();return new Cypress.Promise(resolve => {testability.whenStable(() => {resolve();}, 3000);});});});

Текущее решение

export function waitAnimation(element: Chainable<JQuery>): Chainable<JQuery> { return element.should('be.visible').should('not.have.class', 'ng-animating');}

Размер скриншотов

1. Не для NX делаем с помощью аргумента --browser chrome при запуске команды cypress open/run и для run-команды указываем параметр --headless.
   
2. Для NX в конфигурации проекта в angular.json с тестами указываем параметр browser: chrome, и для конфигурации, которая будет запускаться в CI, указываем headless: true.
   

module.exports = (on, config) => {on('before:browser:launch', (browser, launchOptions) => {if (browser.name === 'chrome' && browser.isHeadless) {launchOptions.args.push('--disable-dev-shm-usage');launchOptions.args.push('--window-size=1440,1200');return launchOptions;}return launchOptions;});};

Даты

cy.clock(new Date(2025, 11, 22, 0).getTime(), ['Date']);

cy.matchImageSnapshot('salary_signing-several-payments', {blackout: ['.timer'],});

Flaky-тесты

Прокачиваем CI

1. Команда npm ci.
2. Поднятие приложения в aot-режиме.
3. Запуск интеграционных тестов.

Сервер со статикой

const express = require('express');const appStaticPathFolder = './dist';const appBaseHref = './my/app';const port = 4200;const app = express();app.use((req, res, next) => {const accept = req.accepts().join().replace('*/*', '');if (accept.includes('text/html')) {req.url = baseHref;}next();});app.use(appBaseHref, express.static(appStaticPathFolder));app.listen(port);

const proxy = require('express-http-proxy');app.use('/common',proxy('https://qa-stand.ru', {proxyReqPathResolver: req => '/common' + req.url,}),);

1. appStaticForlderPath папка, где находится статика вашего приложения.
2. appBaseHref возможно, у вашего приложения есть baseHref, если нет можно указать /.

Кастомизация index.html

const fs = require('fs');const appStaticPathFolder = './dist';fs.copyFileSync(appStaticPathFolder + '/index.modern.html', appStaticPathFolder + '/index.html');fs.readFile(appStaticPathFolder + '/index.html', 'utf-8', (err, data) => {const newValue = data.replace('<script type="text/javascript" src="http://personeltest.ru/aways/habr.com/auth.js"></script>','',).replace('<script type="text/javascript" src="http://personeltest.ru/aways/habr.com/analytics.js"></script>','',);fs.writeFileSync(appStaticPathFolder + '/index.html', newValue, 'utf-8');});

Скрипты

{"name": "cypress-tests","version": "0.0.0","private": true,"scripts": {"create-index": "node ./create-index.js","main-app:serve": "node ./server.js","main-app:cy:run": "cypress run --project ./projects/main-app-integrations ","main-app:integrations": "npm run create-index && start-server-and-test main-app:serve http://localhost:4200/my/app/ main-app:cy:run"},"devDependencies": {"@cypress/webpack-preprocessor": "4.1.0","@types/express": "4.17.2","@types/mocha": "5.2.7","@types/node": "8.9.5","cypress": "4.1.0","cypress-image-snapshot": "3.1.1","express": "4.17.1","express-http-proxy": "^1.6.0","start-server-and-test": "1.10.8","ts-loader": "6.2.1","typescript": "3.8.3","webpack": "4.41.6"}}

Запуск

FROM cypress/included:4.3.0COPY integration-tests-scripts /app/WORKDIR /appRUN npm ciCOPY projects/main-app-integrations /app/projects/main-app-integrationsCOPY dist /app/distCOPY tsconfig.json /app/ENTRYPOINT []

docker build -t integrations -f integration-tests-ci.Dockerfile .docker run --rm -v $PWD/projects/main-app-integrations/src:/app/projects/main-app-integrations/src integrations:latest npm run main-app:integrations

Итог

1. Ставим зависимость для Cypress.
2. Подготавливаем папку с тестами:
   
   1. Angular Single Application оставляем все в папке cypress.
   2. Angular Workspace создаем папку имя приложения-integrations рядом с приложением, на которое будут гоняться тесты, и переносим в нее все из папки cypress.
   3. NX переименовываем проект из имя приложения-e2e в имя-приложения-integrations.
   
   
3. Кастомная cypress-сборка для поднятия приложения делаем в build-разделе конфигурацию Cypress, указываем там aot, подмену на свой отдельный index.html, подмену файла environment на prod-файл и указываем в serve-разделе сборку Cypress (данный пункт необходим, если вам нужны какие-то отличия от prod-сборки, в противном случае можно пропустить).
4. Скрипты по запуску и прогону тестов:
   
   1. Angular Single Application готовим скрипт с serve-ом cypress-сборки и запуску тестов, комбинируем все это с помощью start-server-and-test.
   2. Angular Workspace аналогично с Angular Single Application, только указываем путь до тестов при запуске cypress run/open.
   3. NX запускаем тесты с помощью команд ng e2e.
   
   
5. Подмешиваем скриншот-тестирование:
   
   1. Добавляем зависимость cypress-image-snapshot.
   2. Переопределяем стандартную команду по сравнению скриншотов для запуска ее только в CI.
   3. В тестах не делаем скриншотов на рандоме. Если скриншоту предшествует анимация, обязательно ждем ее например, добавляем Cypress Assertion на анимируемый элемент.
   4. Дату мокируем через cy.clock либо используем опцию blackout при снятии скриншота.
   5. Любую подгружаемую статику в runtime ожидаем через кастомную команду cy.waitForResource (картинки, шрифты и т. д.).
   
   
6. Оборачиваем все это в Docker:
   
   1. Готовим Dockerfile.
   2. Создаем bash-файл.
   
   

1. В CI учимся прокидывать между билдами артефакты собранного приложения (остается на вас).
2. Готовим папку integration-tests-scripts:
   
   1. Скрипт по поднятию сервера вашего приложения.
   2. Скрипт по изменению вашего index.html (если вас устраивает изначальный index.html можно скипать).
   3. Добавляем в папку package.json с необходимыми скриптами и зависимостями.
   4. Готовим новый Dockerfile.
   5. Создаем bash-файл.
   
   

Полезные ссылки

1. Angular Workspace + Cypress + CI в данном примере я создал базу для Angular Workspace приложения с накрученным CI на основе скриптов, описанных в статье (без поддержки typescript).
   
2. Cypress обратите внимание на раздел trade-offs.
   
3. Start-server-and-test запуск сервера, ожидание ответа и запуск тестов.
   
4. Cypress-image-snapshot библиотека для скриншот-тестирования.
   
5. Cypress recipes готовые наработки по Cypress, чтобы не изобретать свои велосипеды.
   
6. Flaky Tests статья про нестабильные тесты, в конце есть ссылка на статью от Google.
   
7. Github Action Cypress дает возможность использовать предустановленные конфиги для GitHub Action, в README куча примеров, из интересного встроенная поддержка wait-on. Также есть пример с docker.
   

Web MIDI API интересный зверь. Хоть он и существует уже почти пять лет, его все еще поддерживает только Chromium. Но это не помешает нам создать полноценный синтезатор в Angular. Пора поднять Web Audio API на новый уровень!

Ранее я рассказывал про декларативную работу с Web Audio API в Angular.

Программировать музыку, конечно, весело, но что если мы хотим ее играть? В 80-е годы появился стандарт обмена сообщениями между электронными инструментами MIDI. Он активно используется и по сей день, и Chrome поддерживает его на нативном уровне. Это значит, что, если у вас есть синтезатор или MIDI-клавиатура, вы можете подключить их к компьютеру и считывать то, что вы играете. Можно даже управлять устройствами с компьютера, посылая исходящие сообщения. Давайте разберемся, как это сделать по-хорошему в Angular.

Web MIDI API

В интернете не так много документации на тему этого API, не считая спецификации. Вы запрашиваете доступ к MIDI-устройствам через navigator и получаете Promise со всеми входами и выходами. Эти входы и выходы еще их называют портами являются нативными EventTargetами. Обмен данными осуществляется через MIDIMessageEventы, которые содержат Uint8Array сообщения. В каждом сообщении не более 3 байт. Первый элемент массива называется status byte. Каждое число означает конкретную роль сообщения, например нажатие клавиши или движение ползунка параметра. В случае нажатой клавиши второй байт отвечает за то, какая клавиша нажата, а третий как громко нота была сыграна. Полное описание сообщений можно подсмотреть на официальном сайте MIDI. В Angular мы работаем с событиями через Observable, так что первым шагом станет приведение Web MIDI API к RxJs.

Dependency Injection

Чтобы подписаться на события, мы сначала должны получить MIDIAccess-объект, чтобы добраться до портов. navigator вернет нам Promise, а RxJs превратит его для нас в Observable. Мы можем создать для этого InjectionToken, используя NAVIGATOR из @ng-web-apis/common. Так мы не обращается к глобальному объекту напрямую:

export const MIDI_ACCESS = new InjectionToken<Promise<MIDIAccess>>(   'Promise for MIDIAccess object',   {       factory: () => {           const navigatorRef = inject(NAVIGATOR);           return navigatorRef.requestMIDIAccess               ? navigatorRef.requestMIDIAccess()               : Promise.reject(new Error('Web MIDI API is not supported'));       },   },);

Теперь мы можем подписаться на все MIDI-события. Можно создать Observable одним из двух способов:

1. Создать сервис, который наследуется от Observable, как мы делали в Geolocation API
2. Создать токен с фабрикой, который будет транслировать этот Promise в Observable событий

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

export const MIDI_MESSAGES = new InjectionToken<Observable<MIDIMessageEvent>>(   'All incoming MIDI messages stream',   {       factory: () =>           from(inject(MIDI_ACCESS).catch((e: Error) => e)).pipe(               switchMap(access =>                   access instanceof Error                       ? throwError(access)                       : merge(                             ...Array.from(access.inputs).map(([_, input]) =>                                 fromEvent(                                     input as FromEventTarget<MIDIMessageEvent>,                                     'midimessage',                                 ),                             ),                         ),               ),               share(),           ),   },);

Если нам нужен какой-то конкретный порт, например если мы хотим отправить исходящее сообщение, достанем его из MIDIAccess. Для этого добавим еще один токен и подготовим фабрику для удобного использования:

export function outputById(id: string): Provider[] {   return [       {           provide: MIDI_OUTPUT_QUERY,           useValue: id,       },       {           provide: MIDI_OUTPUT,           deps: [MIDI_ACCESS, MIDI_OUTPUT_QUERY],           useFactory: outputByIdFactory,       },   ];}export function outputByIdFactory(   midiAccess: Promise<MIDIAccess>,   id: string,): Promise<MIDIOutput | undefined> {   return midiAccess.then(access => access.outputs.get(id));}

Кстати, вы знали, что нет необходимости спрэдить массив Provider[], когда добавляете его в метаданные? Поле providers декоратора @Directive поддерживает многомерные массивы, так что можно писать просто:

providers: [  outputById(someId),  ANOTHER_TOKEN,  SomeService,]

Если вам интересны подобные практичные мелочи про Angular приглашаю почитать нашу серию твитов с полезными советами.

Аналогичным образом можно добывать и входные порты, а также запрашивать их по имени.

Операторы

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

• Фильтрующие. Они отсеивает события, которые нас не интересуют. Например, если мы хотим слушать только сыгранные клавиши или ползунок громкости.
• Преобразующие. Они будут преобразовывать значения для нас. Например, оставлять только массив данных сообщения, отбрасывая остальные поля события.

Вот так мы можем слушать события с определенного канала:

export function filterByChannel(   channel: MidiChannel,): MonoTypeOperatorFunction<MIDIMessageEvent> {   return source => source.pipe(filter(({data}) => data[0] % 16 === channel));}

Status byte организован группами по 16: 128143 отвечают за нажатые клавиши (noteOn) на каждом из 16 каналов. 144159 за отпускание зажатых клавиш (noteOff). Таким образом, если мы возьмем остаток от деления этого байта на 16 получим номер канала.

Если нас интересуют только сыгранные ноты, поможет такой оператор:

export function notes(): MonoTypeOperatorFunction<MIDIMessageEvent> {   return source =>       source.pipe(           filter(({data}) => between(data[0], 128, 159)),           map(event => {               if (between(event.data[0], 128, 143)) {                   event.data[0] += 16;                   event.data[2] = 0;               }               return event;           }),       );}

Некоторые MIDI-устройства отправляют явные noteOff-сообщения, когда вы отпускаете клавишу. Но некоторые вместо этого отправляют noteOn сообщение с нулевой громкостью. Этот оператор нормализует такое поведение, приводя все сообщения к noteOn. Мы просто смещаем status byte на 16, чтобы noteOff-сообщения перешли на территорию noteOn, и задаем нулевую громкость.

Теперь можно строить цепочки операторов, чтобы получить стрим, который нам нужен:

readonly notes$ = this.messages$.pipe(  catchError(() => EMPTY),  notes(),  toData(),);constructor(  @Inject(MIDI_MESSAGES)  private readonly messages$: Observable<MIDIMessageEvent>,) {}

Пора применить все это на практике!

Создаем синтезатор

С небольшой помощью библиотеки для Web Audio API, которую мы обсуждали ранеесоздадим приятно звучащий синтезатор всего за пару директив. Затем мы скормим ему ноты, которые играем через описанный выше стрим.

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

readonly notes$ = this.messages$.pipe(  catchError(() => EMPTY),  notes(),  toData(),  scan(    (map, [_, note, volume]) => map.set(note, volume), new Map()  ),);

Чтобы звук не прерывался резко и не звучал всегда на одной громкости, создадим полноценный ADSR-пайп. В прошлой статье была его упрощенная версия. Напомню, идея ADSR менять громкость звука следующим образом:

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

@Pipe({    name: 'adsr',})export class AdsrPipe implements PipeTransform {    transform(        value: number,        attack: number,        decay: number,        sustain: number,        release: number,    ): AudioParamInput {        return value            ? [                  {                      value: 0,                      duration: 0,                      mode: 'instant',                  },                  {                      value,                      duration: attack,                      mode: 'linear',                  },                  {                      value: sustain,                      duration: decay,                      mode: 'linear',                  },              ]            : {                  value: 0,                  duration: release,                  mode: 'linear',              };    }}

Теперь, когда мы нажимаем клавишу, громкость будет линейно нарастать за время attack. Затем она убавится до уровня sustain за время decay. А когда мы отпустим клавишу, громкость упадет до нуля за время release.

С таким пайпом мы можем набросать синтезатор в шаблоне:

<ng-container  *ngFor="let note of notes | keyvalue; trackBy: noteKey">  <ng-container    waOscillatorNode    detune="5"    autoplay    [frequency]="toFrequency(note.key)"   >    <ng-container       waGainNode       gain="0"      [gain]="note.value | adsr: 0:0.1:0.02:1"    >      <ng-container waAudioDestinationNode></ng-container>    </ng-container>  </ng-container>   <ng-container    waOscillatorNode    type="sawtooth"    autoplay     [frequency]="toFrequency(note.key)"  >    <ng-container       waGainNode      gain="0"      [gain]="note.value | adsr: 0:0.1:0.02:1"    >      <ng-container waAudioDestinationNode></ng-container>      <ng-container [waOutput]="convolver"></ng-container>    </ng-container>  </ng-container></ng-container><ng-container  #convolver="AudioNode"  waConvolverNode  buffer="assets/audio/response.wav">  <ng-container waAudioDestinationNode></ng-container></ng-container>

Мы перебираем собранные ноты с помощью встроенного keyvalue пайпа, отслеживая их по номеру сыгранной клавиши. Затем у нас есть два осциллятора, играющих нужные частоты. А в конце эффект реверберации с помощью ConvolverNode. Довольно нехитрая конструкция и совсем немного кода, но мы получим хорошо звучащий, готовый к использованию инструмент. Попробуйте демо в Chrome:

https://ng-web-apis.github.io/midi

Если у вас нет MIDI клавиатуры можете понажимать на ноты мышкой.

Живое демо доступно тут, однако браузер не позволит получить доступ к MIDI в iframe: https://stackblitz.com/edit/angular-midi

Заключение

В Angular мы привыкли работать с событиями с помощью RxJs. И Web MIDI API не сильно отличается от привычных DOM событий. С помощью пары токенов и архитектурных решений мы смогли с легкостью добавить поддержку MIDI в наше Angular приложение. Описанное решение доступно в виде open-source библиотеки @ng-web-apis/midi. Она является частью большого проекта, под названием Web APIs for Angular. Наша цель создание легковесных качественных оберток для использования нативного API в Angular приложениях. Так что если вам нужен, к примеру, Payment Request API или Intersection Observer посмотрите все наши релизы.

Если вам любопытно, что же такого интересного можно сделать на Angular при помощи Web MIDI API приглашаю вас научиться играть на клавишах в личном проекте Jamigo.app

Всем привет! Меня зовут Игорь, я фронтэндер в Tinkoff.ru. И, как ни странно, я давно и безнадежно прикипел к Angular и ко всему, что с ним связано.

Очень хорошо помню свои первые проблемы со сборкой приложения на Angular: как передать в приложение переменные окружения или изменить алгоритмы сборки стилей? Я так к этому привык при работе с React. И сначала это решали с помощью ng eject: конфигурация webpack просто извлекалась из недр Angular CLI и изменялась как душе разработчика угодно. Выглядело это как костыль webpack.config.js был раздутым и сложным. Но, когда Angular CLI v8.0.0 принес нам стабильный CLI Builders API, который позволяет кастомизировать, заменять или даже создавать новые CLI команды, все стало проще.

Сейчас самый популярный билдер для кастомизации конфигурации webpack @angular-builders/custom-webpack. Если заглянуть в исходники всех билдеров, поставляемых пакетом, можно увидеть очень компактные решения, не превышающие и 30 строк кода.
Го тогда запилим свой? Challenge Accepted!

Данный материал подразумевает, что вы уже знакомы с Angular и Angular CLI, знаете, что такое rxjs и как с ним жить, а также готовы прочитать 50 строк кода.

Так что же такое эти билдеры?

Билдер это всего лишь функция, которая может быть вызвана с помощью Angular CLI. Она вызывается с двумя параметрами:

1. JSON-подобный объект-конфигурация
2. BuilderContext объект, обеспечивающий доступ, например, к логгеру.

Функция может быть как синхронной, так и асинхронной. Ну и бонусом можно вернуть Observable. Но в любом случае и Promise, и Observable должны испускать BuilderOutput.

Упакованная в npm-пакет определенным образом эта функция может использоваться при настройке таких CLI команд как build, test, lint, deploy и любых других из секции architect конфигурационного файла angular.json.

Опять будет просто пример из документации?

Нет. Конечно же я сначала сделал пример, максимально похожий на пример из документации. Такой билдер я использовал, например, при работе с NX и деплоем только измененных приложений. Но мне внезапно понадобился билдер, который умеет запускать команды из angular.json в определенном порядке и в зависимости друг от друга.

Более реальный пример: вам вдруг понадобился запущенный dev-server вашего приложения в тестах. Есть разные консольные утилиты и npm-пакеты для запуска и ожидания старта сервера, но почему бы не сделать билдер, которые сможет запускать dev-server в watch-режиме перед запуском тестов и убивать dev-server, как только тесты отработают?

С чего начать?

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

npx create-nx-workspace ng-builderscd ./ng-buildersnpx ng g @nrwl/node:library build

Для автоматизации релизов и версионирования был подключен semantic-release. В роли CI был использован Github Actions.

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

Конфигурация билдера

Вот так я видел конфигурацию, которая решала мою проблему:

// angular.json{  "version": 1,  "projects": {    "app": {      "architect": {        "stepper": {          "builder": "@ng-builders/build:stepper",          "options": {            "targets": { // описание целей              "jest": { // название цели и его конфигурация                "target": "app:jest", // существующая в angular.json задача                 "deps": ["server"] // зависимые цели, которые нужно запустить перед основной              },              "server": {                "target": "app:serve",                "watch": true // watch-режим              }            },            "steps": ["jest"] // список целей для выполнения          }        }      }    }  }}

В теории, такую задачу в angular.json можно выполнить с помощью команды:

ng run app:stepper

Немного поработав над спецификацией я пришел к таким интерфейсам:

export interface Target {  /**   * Список targetId, которые необходимо выполнить перед запуском задачи   *   * Отличается от Schema#steps тем, что задача не ждет полного    * выполнения зависимых задач   */  deps?: string[];  /**   * Цель для выполнения   */  target: string;  /**   * Включение watch-режима   */  watch?: boolean;  /**   * Переопределение конфигурационных параметров цели   */  overrides?: { [key: string]: any };}export interface Targets {  // targetId - имя задачи  [targetId: string]: Target;}export interface Schema {  /**   * Строгая последовательность выполнения задач, в массиве    * указываются targetId из Targets   *   * Следующая задача запускается только после завершения предыдущей   */  steps: string[];  targets: Targets;}

Из основного вроде все. Конечно, схему можно еще расширить и, например, добавить выбор конфигурации (production, dev и т.д.), но для v1.0 этого будет достаточно.

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

Let's code

Итак, у нас есть интерфейс конфигурации. При запуске задачи через Angular CLI все чудесным образом должно работать.

Для начала напишем функцию runStepper и создадим StepperBuilder.

// index.tsexport function runStepper(  input: Schema,  context: BuilderContext): BuilderOutputLike {  return buildSteps(input, context).pipe(    map(() => ({      success: true    })),    catchError(error => {      return of({ error: error.toString(), success: false });    })  );}export const StepperBuilder = createBuilder(runStepper);export default StepperBuilder;

Обратите внимание, что тип первого аргумента функции runStepper это та самая Schema из спецификации конфигурации выше. Функция возвращает Observable<BuilderOutput> .

Дальше мы реализуем функцию buildSteps, которая будет отвечать за выполнение шагов

// index.tsfunction buildSteps(config: Schema, context: BuilderContext): Observable<any> {  return concat(    config.steps.map(step => buildStep(step, config.targets, context))  );}

Кажется ничего сложного. Каждый следующий шаг выполняется после завершения предыдущего.

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

// index.tsfunction buildStep(  stepName: string,  targets: Targets,  context: BuilderContext): Observable<any> {  const { deps = [], overrides, target, watch }: Target = targets[stepName];  const deps$ = deps.length    ? combineLatest(deps.map(depName => buildStep(depName, targets, context)))    : of(null);  return deps$.pipe(    concatMap(() => {      return scheduleTargetAndForget(context, targetFromTargetString(target), {        watch,        ...overrides      });    }),    watch ? tap(noop) : take(1)  );}

В этой функции есть несколько интересных моментов:

1. Зависимости шага запускаются параллельно, а главная задача шага только после того, как каждая из зависимостей испустит хотя бы одно событие. Это дает нам гарантию, что dev-server (если задача на его запуск в списке зависимостей текущего шага) запуститься перед запуском тестов (если это главная задача шага).
2. Функция scheduleTargetAndForget, импортируемая из @angular-devkit/architect. Эта функция позволяет запускать цели из angular.json и оверрайдить их настройки. Возвращает эта функция Observable, отписка от которого останавливает выполняемую задачу.
3. Если параметр watch имеет положительное значение, то главная задача шага не завершится после первого испущенного события, следовательно текущая задача будет жить вечно, пока не завершится сама, либо пока не произойдет отписка от вернувшегося Observable, либо не будет завершен процесс.

Собственно это все, что касается самого билдера. Полный вариант можно посмотреть тут. Уложились в 56 строк кода. Неплохо, правда?

Последний интересующий и важный для нас момент это файл builders.json

{  "$schema": "../../@angular-devkit/architect/src/builders-schema.json",  "builders": {    "stepper": {      "implementation": "./stepper",      "schema": "./stepper-schema.json",      "description": "Stepper"    }  }}

Как вы видите, в этом файле указывается список билдеров с параметрами implementation (входная точка для импорта билдера), schema (схема валидации) и description (описание).

Затем ищем package.json и добавляем свойство builders с относительным путем до файла builders.json

{    "name": "@ng-builders/build",    "builders": "./builders.json",    }

Осталось только собрать пакет:

npm run build

Закидываем все в коммит и пушим всю эту красоту на Github.

И это все?

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

Билдер можно неспокойно (как только появятся тесты обязательно уберу не) использовать в своих проектах.

npm i @ng-builders/build -D

Итоги

CLI Builders API это мощный инструмент для расширения и кастомизации Angular CLI. Билдер, созданный нами, решает не самые популярные проблемы, но на создание всего пакета ушел всего лишь 1 час. Что нам это говорит? А то что создать кастомный билдер для решения частных проблем не такая уж и сложная задача. По этому дерзайте, фантазируйте и создавайте. И помните, что тесты сами себя не напишут!

P.S.:

Angular CLI Builders прекрасно используются и работают в NX Workspace даже без Angular. Пример этого чуда я обязательно покажу вам в будущем. А пока можете читать меня в Twitter, писать мне в Telegram и говорить обо мне только хорошее.

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

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

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

Введение

Перво-наперво хочется совершить виртуальный каминг-аут и признаться, что я большой фанат паттерна MVVM. Для меня он не ограничивается сплошной стрелочкой, направленной от View к ViewModel и пунктирной в обратном направлении. Правильно приготовленный MVVM, как мне кажется, это инфраструктура, если хотите фреймворк, включающий в себя, кроме реализации самого паттерна, решение для управления зависимостями, реализацию роутинга и ряд вспомогательных компонентов для упрощения жизни, здоровья и долголетия.

Именно этим и занимались первые MVVM-фреймворки, с которыми я работал в незапамятные времена, когда мобильных платформ было больше двух. Именно этим я планирую заниматься ближайшие три статьи. А начнем мы с управления зависимостями, потому что это фундамент, на котором держится весь увлекательный мир вашего iOS-приложения.

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

Хорошее содержание

• Статья 1. Бюджетный DI на антипаттернах
  
  • Введение <= вы находитесь здесь
  • Принципы
  • Проблема управления зависимостями
  • Решение
  • Пример использования
  • Критика
  • Автоматическое внедрение зависимостей через обертки свойств
  • Unit-тесты, раздел под звездочкой
  • Заключение
• Статья 2. Доступный MVVM на хакнутых экстеншенах
• Статья 3. Легковесный роутинг на микросервисах

Принципы

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

1. Не выпендривайся. Тупой и понятный код в большинстве случаев лучше умного и непонятного.
2. Будь краток. Кода должно быть настолько мало, чтобы его не жалко было в любой момент выкинуть и написать заново за один день.
3. Удобство превыше правил. Если можно облегчить себе жизнь, пожертвовав принципами SOLID, пожертвуй принципами SOLID.
4. Получай удовольствие. Если есть разные варианты решения проблемы, выбирай более веселый.

Иметь такой список принципов очень удобно: это оправдывает все странные решения, которые я собираюсь принимать на протяжении трех статей.

Проблема управления зависимостями

Проблема управления зависимостями довольно типичная в программировании. Мало какая сущность в коде может похвастаться независимостью как твоя бывшая. Обычно все от кого-нибудь зависят. В MVVM, например, вью-контроллер зависит от вью-модели, которая подготавливает для него данные. Вью-модель зависит от сервиса, который за этими данными ходит в сеть. Сервис зависит от другого сервиса низкоуровневой реализации сети, и так далее. Все эти сущности, которых может быть великое множество, нужно где-то создавать и как-то доставлять до потребителей. Для любой типичной проблемы, как правило, есть типичное решение паттерн. В случае с проблемой управления зависимостями таким паттерном является Dependency Injection (DI) контейнер.

У меня нет намерения подробно объяснять, что такое DI-контейнер. Про это классно рассказывают в двух статьях из репозитория Ninject: раз, два (уберите от экрана детей, там код на С#). Еще есть небольшое объяснение в репозитории самого популярного DI-контейнера под iOS Swinject (заметили, что Swinject это Ninject на Swift?). Хардкорщикам могу предложить статью Фаулера от 2004 года.

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

Решение

Существует несколько довольно популярных реализаций DI-контейнеров под iOS (Swinject, Cleanse, Dip, DITranquility, EasyDI), но использовать чужую реализацию, согласитесь, скучно. Гораздо веселее использовать мою.

Готовы немного развлечься и написать DI-контейнер с нуля? Похожую реализацию мне показал однажды один из самых крутых iOS-разработчиков, простой сибирский парень teanet, за что ему огромное спасибо. Я ее немного переосмыслил и готов поделиться с вами. Начнем с протокола IContainer:

protocol IContainer: AnyObject {    func resolve<T: IResolvable>(args: T.Arguments) -> T}

Привычка из прошлой жизни я всегда пишу I перед протоколами. Буква I значит interface. У нашего интерфейса протокола всего один метод resolve(args:), который от нас принимает какие-то аргументы T.Arguments, а взамен возвращает экземпляр типа T. Как видно, не любая сущность может быть Т. Чтобы стать полноправным T, нужно реализовать IResolvable. IResolvable это еще один протокол, о чем нам услужливо подсказывает буква I в начале имени. Он выглядит вот так:

protocol IResolvable: AnyObject {    associatedtype Arguments    static var instanceScope: InstanceScope { get }    init(container: IContainer, args: Arguments)}

Все кролики, которые хотят быть доступны из шляпы, обязаны реализовать IResolvable.

Самое главное здесь инициализатор, принимающий сам контейнер и аргументы. Предполагается, что каждая сущность, реализуя этот инициализатор, сама достанет прямо из контейнера нужные зависимости. А если этому кролику для полноценного существования нужны еще какие-то аргументы, то пожалуйста они тоже есть в инициализаторе.

Свойство instanceScope отвечает за область видимости, в которой будет существовать экземпляр объекта:

enum InstanceScope {    case perRequst    case singleton}

Это довольно стандартная для DI-контейнеров штуковина. Значение perRequest означает, что для каждого вызова resolve(args:) будет создан новый экземпляр T. Значение singleton означает, что экземпляр T будет создан единожды при первом вызове resolve(args:). При последующих вызовах resolve(args:) в случае singleton будет отдаваться закэшированная копия.

С протоколами разобрались, приступаем к реализации:

class Container {    private var singletons: [ObjectIdentifier: AnyObject] = [:]    func makeInstance<T: IResolvable>(args: T.Arguments) -> T {        return T(container: self, args: args)    }}

Тут ничего особенного: кэш синглтонов будем хранить в виде словаря singletons. Ключом словаря нам послужит ObjectIdentifier это стандартный тип, поддерживающий Hashable и представляющий собой уникальный идентификатор объекта ссылочного типа (через него, кстати, реализован оператор === в Swift). Метод makeInstance(args:) умеет на лету создавать любые экземпляры T благодаря тому, что мы обязали все T реализовать один и тот же инициализатор.

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

extension Container: IContainer {    func resolve<T: IResolvable>(args: T.Arguments) -> T {        switch T.instanceScope {        case .perRequst:            return makeInstance(args: args)        case .singleton:            let key = ObjectIdentifier(T.self)            if let cached = singletons[key], let instance = cached as? T {                return instance            } else {                let instance: T = makeInstance(args: args)                singletons[key] = instance                return instance            }        }    }}

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

Вот, собственно, и все. Мы только что написали свой DI-контейнер в 50 строк кода. Но как этой штукой вообще пользоваться? Да очень просто.

Пример использования

Для примера рассмотрим хрестоматийную историю с клиентами и их заказами. Пусть мы хотим отобразить список заказов конкретного клиента на определенную дату. Заведем для наших целей две сущности: OrdersProvider и OrdersVM эти ребята должны быть доступны из контейнера, а значит, им придется реализовать IResolvable.

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

Полезный экстеншен номер раз:

protocol ISingleton: IResolvable where Arguments == Void { }extension ISingleton {    static var instanceScope: InstanceScope {        return .singleton    }}

И второй такой же, но другой:

protocol IPerRequest: IResolvable { }extension IPerRequest {    static var instanceScope: InstanceScope {        return .perRequst    }}

Теперь вместо IResolvable можно конформить более лаконичным ISingleton/IPerRequest и сэкономить тем самым несколько секунд жизни, потратив их на саморазвитие. А вот и реализация OrdersProvider подъехала:

class OrdersProvider: ISingleton {    required init(container: IContainer, args: Void) { }    func loadOrders(for customerId: Int, date: Date) {        print("Loading orders for customer '\(customerId)', date '\(date)'")    }}

Мы предоставили required init, как того требует протокол, но, так как OrdersProvider ни от чего не зависит, этот инициализатор у нас пустой. Каждый раз, когда мы будем доставать OrdersProvider из контейнера, мы будем получать один и тот же экземпляр, потому что такова дефолтная реализация instanceScope для ISingleton.

А вот и модель представления собственной персоной:

final class OrdersVM: IPerRequest {    struct Args {        let customerId: Int        let date: Date    }    private let ordersProvider: OrdersProvider    private let args: Args    required init(container: IContainer, args: Args) {        self.ordersProvider = container.resolve()        self.args = args    }    func loadOrders() {        ordersProvider.loadOrders(for: args.customerId, date: args.date)    }}

Эта вью-модель не может существовать без аргументов OrdersVM.Args, которые мы получаем через required init. В этот инициализатор также попадает сам контейнер, из которого мы без лишней суеты извлекаем экземпляр OrdersProvider посредством вызова resolve().

Вызов метода loadOrders() использует ordersProvider для загрузки заказов, предоставляя ему необходимые для работы аргументы. Каждый раз, когда мы будем доставать OrdersVM из контейнера, мы будем получать новый экземпляр, потому что такова дефолтная реализация instanceScope для IPerRequest.

Финальный штрих. Чтобы получить готовый экземпляр вью-модели, просто достанем его из контейнера, вот так:

let container = Container()let viewModel: OrdersVM = container.resolve(args: .init(customerId: 42, date: Date()))viewModel.loadOrders()

Для справки, на момент написания этих строк, код выше производит следующий консольный вывод:

Loading orders for customer '42', date '2020-04-22 17:41:49 +0000'

Критика

Использовать или не использовать DI-контейнер из этой статьи в вашем проекте решать не мне. Как ответственный автор, я могу всего лишь предлагать варианты и рассказывать о плюсах и минусах одинаково объективно.

Пытливый ум усидчивого читателя заметит, что реализация, представленная выше, если честно, не очень похожа на DI-контейнер. Эта реализация больше похожа на Service Locator, который, откровенно говоря, в приличном обществе принято считать не иначе как антипаттерном.

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

final class OrdersVM {    private let ordersProvider: IOrdersProvider    init(ordersProvider: IOrdersProvider) {       self.ordersProvider = ordersProvider    }}

Если вы осмелились использовать Service Locator, тогда ваша сущность, вероятно, достает зависимости из какого-нибудь сомнительного места типа статической фабрики. Например, вот так:

final class OrdersVM {    private let ordersProvider: IOrdersProvider    init() {        self.ordersProvider = ServiceLocator.shared.resolve()    }}

Программисты недолюбливают Service Locator в первую очередь за то, что он скрывает истинные зависимости сущностей при их создании.

С практической точки зрения это означает, что нет никакой возможности понять, что OrdersVM зависит от IOrdersProvider для этого нужно читать код инициализатора. Кроме того, OrdersVM напрямую зависит от ServiceLocator, что затрудняет переиспользование этого класса в системах, где для DI может быть выбрано другое решение.

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

Все наши сущности, если приглядеться, вообще ни капельки не зависят от абстракций. Напротив, они сами решают, какую конкретную реализацию своих зависимостей следует использовать. Например, OrdersVM достает из контейнера совершенно конкретный OrdersProvider, а не какой-нибудь протокол IOrdersProvider.

С практической точки зрения это затрудняет подмену одной реализации IOrdersProvider на другую реализацию этого протокола. Между тем, такая подмена может вам пригодиться не только в разработке, но и в рамках рефакторинга, а также при написании юнит-тестов.

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

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

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

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

Вот вам смысл этого многословного раздела в виде двух списков.

Короче, минусы

• Зависимости достаем в конструкторе прямо из контейнера (Service Locator).
• Не получится закрыть зависимость протоколом (принцип на букву D).

Короче, плюсы

• Простая и лаконичная реализация (50 строк кода).
• Не надо регистрировать зависимости (вообще не надо).
• Извлечение из контейнера никогда не сломается (совсем никогда).
• Нельзя передать невалидные аргументы (не скомпилируется).

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

One More Thing: автоматическое внедрение зависимостей через обертки свойств

В 2019 году в компании Apple придумали инкапсулировать повторяющуюся логику гетеров и сетеров в переиспользуемые атрибуты и назвали это обертками свойств (property wrappers). С помощью таких оберток ваши свойства волшебным образом могут получить новое поведение: запись значения в Keychain или UserDefaults, потокобезопасность, валидацию, логирование да много чего.

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

Чтобы написать свою обертку свойства в минимальной комплектации, нужно создать класс или структуру, предоставить свойство wrappedValue и пометить все это дело атрибутом @propertyWrapper:

@propertyWrapperstruct Resolvable<T: IResolvable> where T.Arguments == Void {    private var cache: T?    var wrappedValue: T {        mutating get {            if let cache = cache {                return cache            }            let resolved: T = ContainerHolder.container.resolve()            cache = resolved            return resolved        }    }}

Из этого незамысловатого кода мы видим, что наш property wrapper называется Resolvable. Он работает со всеми типами Т, которые реализуют одноименный протокол и не требуют аргументов при инициализации.

Волшебство происходит при обращении к свойству wrappedValue: мы возвращаем закэшированное значение, если таковое имеется. Если нет достаем это значение из контейнера и сохраняем в кэш. Чтобы наша обертка получила доступ к контейнеру, пришлось провернуть грязный трюк поместить контейнер в статическое свойство класса ContainerHolder:

final class ContainerHolder {    static var container: IContainer!}

Имея в своем арсенале обертку Resolvable<T>, мы можем применить ее к какой-нибудь зависимости, например к ordersProvider:

@Resolvableprivate var ordersProvider: OrdersProvider

Это приведет к тому, что компилятор сгенерирует за нас примерно такой код:

private var _ordersProvider = Resolvable<OrdersProvider>()var ordersProvider: OrdersProvider {  get { return _ordersProvider.wrappedValue }}

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

Теперь знакомая нам модель представления может позволить себе не извлекать из контейнера OrdersProvider в инициализаторе, а просто пометить соответствующее свойство атрибутом @Resolvable. Вот так:

final class OrdersVM: IPerRequest {    struct Args {        let customerId: Int        let date: Date    }    @Resolvable    private var ordersProvider: OrdersProvider    private let args: Args    required init(container: IContainer, args: Args) {        self.args = args    }    func loadOrders() {        ordersProvider.loadOrders(for: args.customerId, date: args.date)    }}

Самое время собрать все вместе и порадоваться, что все работает как прежде:

ContainerHolder.container = Container()let viewModel: OrdersVM = ContainerHolder.container.resolve(    args: .init(customerId: 42, date: Date()))viewModel.loadOrders()

Для справки. Этот код производит следующий консольный вывод:

Loading orders for customer '42', date '2020-04-23 18:47:36 +0000'

Unit-тесты, раздел под звездочкой

Думаю, все согласятся, что сложно переоценить важность автоматических тестов в современной разработке. Искренне надеюсь, что вы на постоянной основе используете как минимум unit-тесты и в своих ежедневных рабочих задачах, и в домашних проектах. Лично я нет. Может быть, по этой причине DI-контейнер из этой статьи не очень хорошо подходит для интеграции с unit-тестами. Однако, если вы, будучи в здравом уме и твердой памяти, решили пойти тернистым путем автоматизации, у меня есть для вас пара вариантов.

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

protocol IOrdersProvider {    func loadOrders(for customerId: Int, date: Date)}extension OrdersProvider: IOrdersProvider {}

Теперь во вью-модели можем сделать второй инициализатор, который будет принимать этот протокол:

final class OrdersVM: IPerRequest {    struct Args {        let customerId: Int        let date: Date    }    private let ordersProvider: IOrdersProvider    private let args: Args    required convenience init(container: IContainer, args: Args) {        self.init(            ordersProvider: container.resolve() as OrdersProvider,            args: args)    }    init(ordersProvider: IOrdersProvider, args: Args) {        self.args = args        self.ordersProvider = ordersProvider    }    func loadOrders() {        ordersProvider.loadOrders(for: args.customerId, date: args.date)    }}

Такой подход позволяет в реальном приложении создавать сущности через контейнер, используя required init, а в тестах пользоваться вторым инициализатором и создавать сущности с замоканными зависимостями.

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

Забегая вперед, скажу, что далее от нас потребуется хранить объекты IResolvable в некоторой коллекции. Однако если мы попробуем сделать это, то столкнемся с суровой действительностью в виде ошибки, до боли знакомой каждому iOS-разработчику: protocol 'IResolvable' can only be used as a generic constraint because it has Self or associated type requirements. Типичный способ как-то справиться с этой ситуацией налить себе чего-нибудь покрепче и применить механизм с пугающим названием стирание типов (type erasure).

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

struct AnyResolvable {    private let factory: (IContainer, Any) -> Any?    init<T: IResolvable>(resolvable: T.Type) {        self.factory = { container, args in            guard let args = args as? T.Arguments else { return nil }            return T(container: container, args: args)        }    }    func resolve(container: IContainer, args: Any) -> Any? {        return factory(container, args)    }}

Кода здесь немного, но он хитрый. В инициализатор мы принимаем настоящий живой тип T, который не можем никуда сохранить. Вместо этого мы сохраняем замыкание, обученное создавать экземпляры этого типа. Замыкание впоследствии используется по своему прямому назначению в методе resolve(container:args:), который понадобится нам позже.

Вооружившись AnyResolvable, мы можем написать контейнер для unit-тестов в 20 строк, который позволит нам выборочно мокать часть зависимостей. Вот он:

final class ContainerMock: Container {    private var substitutions: [ObjectIdentifier: AnyResolvable] = [:]    public func replace<Type: IResolvable, SubstitutionType: IResolvable>(        _ type: Type.Type, with substitution: SubstitutionType.Type) {        let key = ObjectIdentifier(type)        substitutions[key] = AnyResolvable(resolvable: substitution)    }    override func makeInstance<T: IResolvable>(args: T.Arguments) -> T {        return makeSubstitution(args: args) ?? super.makeInstance(args: args)    }    private func makeSubstitution<T: IResolvable>(args: T.Arguments) -> T? {        let key = ObjectIdentifier(T.self)        let substitution = substitutions[key]        let instance = substitution?.resolve(container: self, args: args)        return instance as? T    }}

Давайте разбираться.

Класс ContainerMock наследуется от обычного Container, переопределяя метод makeInstance(args:), используемый контейнером для создания сущностей. Новая реализация пытается создать подставную зависимость вместо настоящей. Если ей это не удается, она печально разводит руками и фолбечится на реализацию базового класса.

Метод replace(_:with:) позволяет сконфигурировать моковый контейнер, указав тип зависимости и соответствующий ей тип мока. Эта информация хранится в словаре substitutions, который использует уже знакомый нам ObjectIdentifier для ключа и AnyResolvable для хранения типа мока.

Для создания моков используется метод makeInstance(args:), который по ключу пытается достать нужный AnyResolvable из словаря substitutions и создать соответствующий экземпляр с помощью метода resolve(container:args:).

Использовать все это дело мы будем следующим образом. Создаем моковый OrdersProvider, переопределяя метод loadOrders(for:date:):

final class OrdersProviderMock: OrdersProvider {    override func loadOrders(for customerId: Int, date: Date) {        print("Loading mock orders for customer '\(customerId)', date '\(date)'")    }}

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

let container = ContainerMock()container.replace(OrdersProvider.self, with: OrdersProviderMock.self)let viewModel: OrdersVM = container.resolve(args: .init(customerId: 42, date: Date()))viewModel.loadOrders()

Для справки, этот код производит следующий консольный вывод:

Loading mock orders for customer '42', date '2020-04-24 17:47:40 +0000'

Заключение

Сегодня мы вероломно поступились принципом инверсии зависимостей и в очередной раз изобрели велосипед, реализовав бюджетный DI с помощью анти-паттерна Service Locator. Попутно мы познакомились с парой полезных техник iOS-разработки, таких как type erasure и property wrappers, и не забыли про unit-тесты.

Автор не рекомендует использовать код из этой статьи в приложении для управления ядерным реактором, но если у вас небольшой проект и вы не боитесь экспериментировать свайп вправо, its a match <3

Весь код из этой статьи можно скачать в виде Swift Playground.

Много лет подряд я, помимо всего прочего, занимался настройкой MVVM в своих рабочих и не очень рабочих проектах. Я увлеченно делал это в Windows-проектах, где паттерн является родным. С энтузиазмом, достойным лучшего применения, я делал это в iOS-проектах, где MVVM просто так не приживается.

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

Советую запастись попкорном и кока-колой это вечернее шоу о том, как я ни в чем себе не отказывал, в очередной раз реализуя MVVM в одном из своих домашних проектов. Сегодня вторая серия: про то, как из MVC сделать MVVM и не наступить в реактивщину.

Введение

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

Напомню также, что в коде я стараюсь с переменным успехом придерживаться нескольких простых правил, о которых уже рассказывал:

Для тех, кто не приемлет неожиданностей, вот полное содержание статьи.

Полное содержание

• Статья 1. Бюджетный DI на антипаттернах
• Статья 2. Доступный MVVM на хакнутых экстеншенах
  
  • Введение <= вы находитесь здесь
  • Действующие лица
  • Знакомим представление с его моделью
  • Реализация по умолчанию через расширение протокола
  • Отображение списка заказов (на самом деле нет)
  • Уведомление об изменении модели представления
  • Заново изобретаем события
  • Отображение списка заказов
  • Подписка на изменение отдельных свойств модели представления через обертки свойств
  • Заключение
• Статья 3. Легковесный роутинг на микросервисах

Действующие лица

Я не планирую расшифровывать каждую букву аббревиатуры MVVM и объяснять, как работает паттерн и зачем он вообще нужен. Уверен, все это вы и без меня знаете. Если по какой-то причине MVVM для вас в новинку, советую перестать читать эту статью и поскорее заполнить пробел в знаниях. Невероятно скучная, но познавательная статья из Википедии может послужить неплохим стартом.

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

Вот так все эти ребята уживаются вместе на диаграмме классов.

Стоит отметить, что в мире MVVM нет такого понятия, как контроллер, в то время как в iOS, где безраздельно властвует MVC, без вью-контроллеров никуда. Чтобы разрешить это противоречие, здесь и далее мы будем считать, что контроллер это просто View, тем более что в iOS эти две сущности традиционно очень тесно связаны.

Запомните: все, что я говорю в этой статье о View, можно в равной степени отнести к контроллеру, и наоборот.

Начиная отсюда и до конца статьи мы будем заниматься реализацией этой картинки в коде.

Знакомим представление с его моделью

Сплошная стрелочка, направленная от View к ViewModel, символизирует их абьюзивные отношения: вьюха владеет вью-моделью, держит ее сильной ссылкой и напрямую вызывает ее методы. Узаконим эти отношения с помощью протокола. Может существовать сколько угодно реализаций MVVM, но одна штука в них будет неизменной: у View должно появиться свойство viewModel:

protocol IHaveViewModel: AnyObject {    associatedtype ViewModel    var viewModel: ViewModel? { get set }    func viewModelChanged(_ viewModel: ViewModel)}

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

Заметим, что свойство viewModel доступно для записи извне. В какой-то момент оно обязательно изменится, что неизбежно приведет к вызову метода viewModelChanged(_:), в котором вьюха обязуется проделать работу по синхронизации своего состояния в соответствии со своей моделью представления. Нехитрая реализация протокола IHaveViewModel на примере связки OrderCell OrderVM могла бы выглядеть вот так:

final class OrderCell: UITableViewCell, IHaveViewModel {    var viewModel: OrderVM? {        didSet {            guard let viewModel = viewModel else { return }            viewModelChanged(viewModel)        }    }    func viewModelChanged(_ viewModel: OrderVM) {        textLabel?.text = viewModel.name    }}

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

final class OrderVM {    let order: Order    var name: String {        return "\(order.name) #\(order.id)"    }    init(order: Order) {        self.order = order    }}

Нетерпеливый читатель может задаться вопросом, кто же проставляет свойство viewModel у ячейки и, что более важно, как именно это происходит. На самом деле типичная OrderCell не очень отличается от своих собратьев, и ее жизненный цикл протекает довольно обычным образом:

1. В методе делегата таблицы tableView(_:cellForRowAt:) извлекаем ячейку при помощи вызова dequeueReusableCell(withIdentifier:for:) и получаем экземпляр класса UITableViewCell.
2. Осуществляем приведение типа к протоколу IHaveViewModel, чтобы получить доступ к свойству viewModel и записать туда вью-модель.
3. Грустим оттого, что код, который мы написали на шаге 2, не компилируется.
4. Гуглим ошибку Protocol 'IHaveViewModel' can only be used as a generic constraint because it has Self or associated type requirements.

Чтобы справиться с такой ошибкой, нам придется применить специальную технику с загадочным названием стирание типов (type erasure). Некоторые авторы выделяют несколько разновидностей стирания типов. Для нашего случая подходит вариант, похожий на секретную технику ниндзя теневое стирание типов (shadow type erasure). Кто придумывает эти названия? На практике весь пафос сводится к тому, что надо просто завести еще один протокол:

protocol IHaveAnyViewModel: AnyObject {    var anyViewModel: Any? { get set }}

Этот протокол не обременен ассоциированным типом, поэтому к нему можно будет кастить любые объекты. Протокол IHaveViewModel почти не изменился, найдите одно отличие:

protocol IHaveViewModel: IHaveAnyViewModel {    associatedtype ViewModel    var viewModel: ViewModel? { get set }    func viewModelChanged(_ viewModel: ViewModel)}

Реализация OrderCell теперь будет выглядеть так:

final class OrderCell: UITableViewCell, IHaveViewModel {    typealias ViewModel = OrderVM    var anyViewModel: Any? {        didSet {            guard let viewModel = anyViewModel as? ViewModel else { return }            viewModelChanged(viewModel)        }    }    var viewModel: ViewModel? {        get {            return anyViewModel as? ViewModel        }        set {            anyViewModel = newValue        }    }    func viewModelChanged(_ viewModel: ViewModel) {        textLabel?.text = viewModel.name    }}

Свойство anyViewModel, лишенное информации о типе, удобно использовать снаружи класса. Оно позволяет любую вьюху привести к типу IHaveAnyViewModel и задать ей вью-модель. Свойство viewModel, которое содержит типизированную вью-модель, удобно использовать внутри класса, например для того, чтобы в методе viewModelChanged(_:) обновлять состояние вьюхи.

Удивительно, насколько отвратительную реализацию MVVM мы с вами только что написали: пользоваться ею решительно невозможно. Все потому, что в каждой вьюхе и вью-контроллере мы вынуждены будем писать очень много повторяющегося кода для реализации IHaveViewModel, что, вообще говоря, довольно утомительно и ни капельки не весело. Хорошая новость в том, что этот недостаток можно преодолеть с помощью расширения, обеспечивающего реализацию по умолчанию для протокола IHaveViewModel.

Реализация по умолчанию через расширение протокола

В основе концепции расширений (extensions) лежит очень простая идея: расширения не могут добавлять никаких новых данных к типу. Все свойства и методы, предоставляемые расширением, являются не чем иным, как комбинацией данных, которые уже объявлены в типе.

Таким образом, если мы попробуем написать реализацию по умолчанию для IHaveViewModel, то ожидаемо столкнемся с неизбежными сложностями в виде ошибки extensions must not contain stored properties:

extension IHaveViewModel {    var anyViewModel: Any? // Не компилируется :(}

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

Представьте, в какую анархию погрузилось бы программирование, если бы все могли вот так запросто добавлять новые данные к любым типам. Возможно, с помощью ошибки extensions must not contain stored properties создатели языка нежно заботятся о нас, не позволяя пойти по скользкой дорожке, покатиться под откос, ринуться в бурлящую бездну хаоса. Вопреки их стараниям, именно этим мы сейчас и займемся, предварительно хакнув свифтовые расширения с помощью старого доброго Objective-C-рантайма. Читай дальше, если не боишься, что полиция экстеншенов придет за тобой:

private var viewModelKey: UInt8 = 0extension IHaveViewModel {    var anyViewModel: Any? {        get {            return objc_getAssociatedObject(self, &viewModelKey)        }        set {            let viewModel = newValue as? ViewModel            objc_setAssociatedObject(self,                 &viewModelKey,                 viewModel,                 .OBJC_ASSOCIATION_RETAIN_NONATOMIC)            if let viewModel = viewModel {                viewModelChanged(viewModel)            }    }    var viewModel: ViewModel? {        get {            return anyViewModel as? ViewModel        }        set {            anyViewModel = newValue        }    }    func viewModelChanged(_ viewModel: ViewModel) {    }}

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

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

final class OrderCell: UITableViewCell, IHaveViewModel {    typealias ViewModel = OrderVM    func viewModelChanged(_ viewModel: OrderVM) {        textLabel?.text = viewModel.name    }}

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

Отображение списка заказов (на самом деле нет)

Вооружившись дефолтной реализацией IHaveViewModel можно быстро накидать код связки OrdersVC OrdersVM. Вью-модель выглядит так:

final class OrdersVM {    var orders: [OrderVM] = []    private var ordersProvider: OrdersProvider    init(ordersProvider: OrdersProvider) {        self.ordersProvider = ordersProvider    }    func loadOrders() {        ordersProvider.loadOrders() { [weak self] model in            self?.orders = model.map { OrderVM(order: $0) }        }    }}

OrdersVM использует OrdersProvider для загрузки отзывов. OrdersProvider с умным видом имитирует асинхронный запрос и отвечает списком отзывов через секунду после вызова loadOrders(completion:):

struct Order {    let name: String    let id: Int}final class OrdersProvider {    func loadOrders(completion: @escaping ([Order]) -> Void) {        DispatchQueue.main.asyncAfter(deadline: .now() + 1) {            completion((0...99).map { Order(name: "Order", id: $0) })        }    }}

И, наконец, вью-контроллер:

final class OrdersVC: UIViewController, IHaveViewModel {    typealias ViewModel = OrdersVM    private lazy var tableView = UITableView()    override func viewDidLoad() {        super.viewDidLoad()        tableView.dataSource = self        tableView.register(OrderCell.self, forCellReuseIdentifier: "order")        view.addSubview(tableView)        viewModel?.loadOrders()    }    override func viewDidLayoutSubviews() {        super.viewDidLayoutSubviews()        tableView.frame = view.bounds    }    func viewModelChanged(_ viewModel: OrdersVM) {        tableView.reloadData()    }}

В методе viewDidLoad() посредством вызова loadOrders() мы сообщаем вью-модели, что нам хотелось бы начать загрузку заказов. На изменение вью-модели мы реагируем в методе viewModelChanged(_:), перезагружая таблицу. Работу с источником данных для таблицы мы вынесли в отдельный экстеншен:

extension OrdersVC: UITableViewDataSource {    func tableView(_ tableView: UITableView,         numberOfRowsInSection section: Int) -> Int {        return viewModel?.orders.count ?? 0    }    func tableView(_ tableView: UITableView,         cellForRowAt indexPath: IndexPath) -> UITableViewCell {        let cell = tableView.dequeueReusableCell(withIdentifier: "order",             for: indexPath)        if let cell = cell as? IHaveAnyViewModel {            cell.anyViewModel = viewModel?.orders[indexPath.row]        }        return cell    }}

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

let viewModel = OrdersVM(ordersProvider: OrdersProvider())let viewController = OrdersVC()viewController.viewModel = viewModel

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

Дело в том, что метод loadOrders(completion:) работает асинхронно, список заказов формируется только через секунду после вызова viewDidLoad(), а это значит, что на момент вызова reloadData() массив orders пуст. Для того чтобы все заработало, нам не хватает одной важной детали уведомления об изменениях вью-модели.

Уведомление об изменении модели представления

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

В самобытном мире iOS-разработки сложилась невеселая ситуация: уведомления об изменении свойств модели представления чаще всего реализуют через реактивные сигналы. Этот подход настолько распространен, что некоторые авторы едва ли не ставят знак равенства между MVVM и Rx. Между тем MVVM вовсе не подразумевает использование стороннего реактивного фрэймворка. В том же .NET исторической родине паттерна уведомления работают через интерфейс INotifyPropertyChanged, реализуемый на стороне ViewModel, в связке с декларативными биндингами на стороне View.

Автор этой статьи, мягко говоря, не фанат реактивного подхода. Очень уж непросто бывает разобраться в хитросплетении сигналов, которые стреляют другими сигналами, которые трансформируются в третьи сигналы. Написать запутанный реактивный код слишком просто. Сегодня вы добавляете в проект один маленький сигнальчик, а завтра ваше простое на первый взгляд приложение превращается в неуправляемый реактивный истребитель, несущийся на сверхзвуковой скорости в бездну отчаяния. Да и не хочется в мелкий домашний проект целый RxSwift тащить, а Combine так вообще только с iOS 13.

В общем, мы с вами, как обычно, пойдем скользкой, но интересной дорожкой и напишем под iOS нечто похожее на события из .NET. Наше творение обеспечит нам вечную славу и поддержку уведомлений об изменениях ViewModel.

Заново изобретаем события

События в .NET это реализация известного паттерна Наблюдатель, такой сталкинг от программирования: вьюха очень пристально следит за тем, что происходит c вью-моделью. Для нас критически важно, чтобы событие поддерживало несколько подписчиков, потому что, например, на одно и то же событие вью-модели может подписаться как ViewController, так и его View.

Реализовать такое на Swift можно несколькими способами: через массив делегатов, через массив замыканий, через NotificationCenter. Тот способ, который поджидает читателя ниже по тексту, вынуждает нас для начала написать небольшой вспомогательный класс. Вот такой:

final class Weak<T: AnyObject> {    private let id: ObjectIdentifier?    private(set) weak var value: T?    var isAlive: Bool {        return value != nil    }    init(_ value: T?) {        self.value = value        if let value = value {            id = ObjectIdentifier(value)        } else {            id = nil        }    }}

Это нехитрая обертка, которая держит слабую ссылку на экземпляр ссылочного типа, передаваемый в инициализатор. Если в инициализатор пришло что-то отличное от nil, обертка запоминает ObjectIdentifier этого объекта, который впоследствии используется для реализации Hashable:

extension Weak: Hashable {    static func == (lhs: Weak<T>, rhs: Weak<T>) -> Bool {        return lhs.id == rhs.id    }    func hash(into hasher: inout Hasher) {        if let id = id {            hasher.combine(id)        }    }}

Вооружившись Weak<T>, можно приступить к реализации событий:

final class Event<Args> {    // Тут живут подписчики на событие и обработчики этого события    private var handlers: [Weak<AnyObject>: (Args) -> Void] = [:]    func subscribe<Subscriber: AnyObject>(        _ subscriber: Subscriber,        handler: @escaping (Subscriber, Args) -> Void) {        // Формируем ключ        let key = Weak<AnyObject>(subscriber)        // Почистим массив обработчиков от мертвых объектов, чтобы не засорять память        handlers = handlers.filter { $0.key.isAlive }        // Создаем обработчик события        handlers[key] = {            [weak subscriber] args in            // Захватываем подписчика слабой ссылкой и вызываем обработчик,            // только если подписчик жив            guard let subscriber = subscriber else { return }            handler(subscriber, args)        }    }    func unsubscribe(_ subscriber: AnyObject) {        // Отписываемся от события, удаляя соответствующий обработчик из словаря        let key = Weak<AnyObject>(subscriber)        handlers[key] = nil    }    func raise(_ args: Args) {        // Получаем список обработчиков с живыми подписчиками        let aliveHandlers = handlers.filter { $0.key.isAlive }        // Для всех живых подписчиков выполняем код их обработчиков событий        aliveHandlers.forEach { $0.value(args) }    }}

Этот код не очень сложный, но, чтобы он не казался вам совсем уж примитивным, я написал побольше комментариев. Класс Weak<T>, как оказалось, нужен был для того, чтобы хранить всех подписчиков в словаре и дать им спокойно умереть, если они того желают не держать их сильной ссылкой.

Обработчик события представляет собой замыкание, в аргументы которого попадает живой подписчик и некоторые данные, если таковые актуальны для данного события. Получившийся класс Event<Args> позволяет подписываться на событие с помощью метода subscribe(_:handler:) и отписываться от него с помощью метода unsubscribe(_:). Когда источник события (в нашем случае это вью-модель) захочет уведомить о чем-то свою армию подписчиков, ему следует воспользоваться методом raise(_:).

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

extension Event where Args == Void {    func subscribe<Subscriber: AnyObject>(        _ subscriber: Subscriber,        handler: @escaping (Subscriber) -> Void) {        subscribe(subscriber) { this, _ in            handler(this)        }    }    func raise() {        raise(())    }}

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

let event = Event<Void>()event.raise() // Какой-то момент наступил, стреляем

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

event.subscribe(self) { this in    this.foo() // Тут полезная работа}

Если подписчик более не заинтересован в получении событий, он делает вот так:

event.unsubscribe(self) // Нам лучше расстаться

Ура! Вы прочитали почти всю статью, осталось совсем немного. Чтобы передохнуть, отвлекитесь на минутку и подумайте о том, насколько MVVM прекрасен. Следующий раздел почти последний.

Отображение списка заказов

Чтобы научить OrdersVM уведомлять OrdersVC об изменении списка заказов, необходимо во вью-модель добавить соответствующее событие. Однако, согласитесь, не хочется в каждой вью-модели, которая должна уведомлять о своих изменениях, снова и снова писать код по созданию события. Поэтому мы пойдем уже знакомым путем и обратимся за помощью к запретным техникам Objective-C-рантайма, клятвенно пообещав себе больше никогда так не делать:

private var changedEventKey: UInt8 = 0protocol INotifyOnChanged {    var changed: Event<Void> { get }}extension INotifyOnChanged {    var changed: Event<Void> {        get {            if let event = objc_getAssociatedObject(self,                 &changedEventKey) as? Event<Void> {                return event            } else {                let event = Event<Void>()                objc_setAssociatedObject(self,                     &changedEventKey,                     event,                     .OBJC_ASSOCIATION_RETAIN_NONATOMIC)                return event            }        }    }}

С помощью протокола INotifyOnChanged и его дефолтной реализации любая вью-модель сможет бесплатно получить событие changed. С появлением INotifyOnChanged дефолтная реализация протокола IHaveViewModel вынуждена будет немного эволюционировать: в ней мы захотим подписаться на изменение вью-модели и вызвать viewModelChanged(_:) в обработчике события:

extension IHaveViewModel {    var anyViewModel: Any? {        get {            return objc_getAssociatedObject(self, &viewModelKey)        }        set {            (anyViewModel as? INotifyOnChanged)?.changed.unsubscribe(self)            let viewModel = newValue as? ViewModel            objc_setAssociatedObject(self,                 &viewModelKey,                 viewModel,                 .OBJC_ASSOCIATION_RETAIN_NONATOMIC)            if let viewModel = viewModel {                viewModelChanged(viewModel)            }            (viewModel as? INotifyOnChanged)?.changed.subscribe(self) { this in                if let viewModel = viewModel {                    this.viewModelChanged(viewModel)                }            }        }    }}

И, наконец, финальный штрих:

final class OrdersVM: INotifyOnChanged {    var orders: [OrderVM] = []    private var ordersProvider: OrdersProvider    init(ordersProvider: OrdersProvider) {        self.ordersProvider = ordersProvider    }    func loadOrders() {        ordersProvider.loadOrders() { [weak self] model in            self?.orders = model.map { OrderVM(name: $0.name) }            self?.changed.raise() // Пыщ!        }    }}

Все, что мы делали выше класс Weak<T>, класс Event<Args>, протокол INotifyOnChanged и его дефолтная реализация, было нужно ради того, чтобы мы смогли написать одну единственную строчку кода во вью-модели: changed.raise().

Вызов rise(), произведенный в подходящий момент, после получения всех данных, приводит к тому, что в контроллере вызывается метод viewModelChanged(_:), который перезагружает таблицу, и она успешно отображает список заказов.

One More Thing: подписка на изменение отдельных свойств модели представления через обертки свойств

Протокол INotifyOnChanged и событие changed неплохо справляются с задачей уведомления об обновлении всей вью-модели с последующей перерисовкой всей вьюхи. В большинстве случаев этого вполне достаточно, но что, если мы хотим из соображений производительности или, что более важно, ради развлечения рассказать View об изменении какого-то одного свойства ViewModel? Очевидно, что мы можем для этих целей завести во вью-модели отдельное событие myPropertyChanged, подписаться на него на стороне вьюхи и дело сделано.

Но зачем самим писать код, который за нас могут генерировать инженеры Apple?

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

Чтобы написать свой property wrapper, нужно создать класс или структуру, предоставить свойство wrappedValue и украсить все это дело, как вишенкой на торте, атрибутом @propertyWrapper. Однако обертки свойств не так просты и позволяют манипулировать не только самим свойством, которое они оборачивают, но и его проекцией через специальное свойство projectedValue. Согласитесь, звучит очень непонятно, поэтому, чтобы еще больше вас запутать, рассмотрим такой код:

@propertyWrapperstruct Observable<T> {    let projectedValue = Event<T>()    init(wrappedValue: T) {        self.wrappedValue = wrappedValue    }    var wrappedValue: T {        didSet {            projectedValue.raise(wrappedValue)        }    }}

Мы только что создали обертку свойства и назвали ее Observable. Она умеет работать со свойствами любых типов и может похвастаться наличием projectedValue. Проекция является событием, которое обучено сообщать своим подписчикам о любых изменениях wrappedValue. Это событие, как видно из кода, мы используем по своему прямому назначению в didSet.

Имея в своем арсенале обертку Observable<T>, мы можем применить ее к списку заказов:

@Observablevar orders: [OrderVM] = []

Это приведет к тому, что компилятор сгенерирует за нас примерно такой код:

private var _orders = Observable<[OrderVM]>(wrappedValue: [])var orders: [OrderVM] {  get { _orders.wrappedValue }  set { _orders.wrappedValue = newValue }}var $orders: Event<[OrderVM]> {  get { _orders.projectedValue }}

Видно, что, помимо свойства orders, которое через обертку просто возвращает wrappedValue, компилятор сгенерировал дополнительное свойство $orders, которое возвращает нам projectedValue. В нашем случае projectedValue это экземпляр события, что позволяет на стороне вьюхи подписаться на изменение свойства orders вот таким нехитрым образом:

viewModel.$orders.subscribe(self) { this, orders in    this.update(with: orders)}

Поздравляю! Вы только что в 15 строчках кода написали свой собственный аналог атрибута Published из фрэймворка Combine от Apple, а я только что дописал очередную статью.

Заключение

Сегодня мы вероломно поступились основным принципом работы расширений, хакнув их с помощью Objective-C-рантайма. Это позволило нам, используя протоколы и экстеншены, реализовать паттерн MVVM в одном маленьком приложении под iOS. В процессе у нас возникло непреодолимое желание применить реактивный фреймворк, и мы едва удержались, написав вместо этого свою реализацию событий, вдохновившись дружественной технологией .NET. Попутно познакомились с парой полезных техник iOS-разработки, таких как shadow type erasure и property wrappers с применением projected value.

Весь код из этой статьи можно скачать в виде Swift Playground.

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

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

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

Введение

Спешу сообщить, что у меня для вас две новости: первая и вторая. Начну с первой: прежде чем читать эту статью, придется прочитать предыдущие две (первая, вторая), иначе будет совершенно ничего не понятно. Вторая новость заключается в том, что в этот раз я в самом начале статьи покажу конечный результат. А вот и он:

Весь остаток статьи мы будем разбираться, как работает эта строчка кода и зачем вообще она нужна.

Напомню также, что у меня есть некоторые правила и я стараюсь их придерживаться:

Традиционно в начале статьи будет ее содержание.

Традиционное содержание

• Статья 1. Бюджетный DI на антипаттернах
• Статья 2. Доступный MVVM на хакнутых экстеншенах
• Статья 3. Легковесный роутинг на микросервисах
  
  • Введение <= вы находитесь здесь
  • В чем проблема?
  • Стоп, что за сервисы вообще такие?
  • Обязательно нужен отдельный сервис для роутинга?
  • Окей, автор, как мне реализовать роутер?
  • Не хочу модальные экраны, хочу пушить экраны в стэк. Как быть?
  • Мне не подходит реализация роутинга. Что делать?
  • Заключение

В чем проблема?

В прошлой статье про MVVM мы написали приложение, которое отображает список заказов (с кем не бывает). У нас есть OrdersVC, у которого имеется личная вью-модель OrdersVM. Предположим, что мы хотим при нажатии на ячейку таблицы отображать экран с информацией о деталях соответствующего заказа:

Для тех, кто предпочитает больше конкретики, вот примитивная до неприличия реализация вью-модели нового экрана:

final class OrderDetailsVM: IPerRequest {    typealias Arguments = Order    let title: String    required init(container: IContainer, args: Order) {        self.title = "Details of \(args.name) #\(args.id)"    }}

Модель представления деталей заказа реализует IPerRequest (подробности в статье про DI), а значит, доступна из DI-контейнера. В качестве аргументов она принимает модель заказа и формирует из нее строковый заголовок, пригодный для отображения пользователю. Контроллер этого экрана будет выглядеть не намного сложнее:

final class OrderDetailsVC: UIViewController, IHaveViewModel {    typealias ViewModel = OrderDetailsVM    private lazy var titleLabel = UILabel()    override func viewDidLoad() {        super.viewDidLoad()        view.backgroundColor = .white        view.addSubview(titleLabel)        titleLabel.translatesAutoresizingMaskIntoConstraints = false        titleLabel.centerXAnchor            .constraint(equalTo: view.centerXAnchor)            .isActive = true        titleLabel.topAnchor            .constraint(equalTo: view.topAnchor, constant: 24)            .isActive = true    }    func viewModelChanged(_ viewModel: OrderDetailsVM) {        titleLabel.text = viewModel.title    }}

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

Чтобы научить OrdersVC реагировать на тап по ячейке таблицы, дополним его экстеншеном:

extension OrdersVC: UITableViewDelegate {    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {        viewModel?.showOrderDetails(forOrderIndex: indexPath.row)    }}

Кстати, этот короткий кусок кода наглядно показывает, как паттерн MVC, который безраздельно властвует в мире iOS, уживается с паттерном MVVM на территории одного приложения. Действие пользователя (тап по ячейке таблицы) обрабатывается контроллером, потому что в iOS по-другому быть не может. Однако контроллер ничего самостоятельно не делает, вместо этого он делегирует всю грязную работу своей модели представления, снабдив ее необходимой информацией в виде индекса интересующего нас заказа.

Напомню, что OrdersVM, которую мы реализовывали в прошлой статье, выглядит так:

final class OrdersVM: IPerRequest, INotifyOnChanged {    typealias Arguments = Void    var orders: [OrderVM] = []    private let ordersProvider: OrdersProvider    required init(container: IContainer, args: Void) {        self.ordersProvider = container.resolve()    }    func loadOrders() {        ordersProvider.loadOrders() { [weak self] model in            self?.orders = model.map { OrderVM(order: $0) }            self?.changed.raise()        }    }    func showOrderDetails(forOrderIndex index: Int) {        let order = orders[index].order        // Что было дальше?        // ...    }}

Эта модель представления реализует IPerRequest, а значит, доступна из контейнера. Также из контейнера она извлекает OrdersProvider, с помощью которого осуществляет загрузку заказов. По окончании загрузки список заказов заботливо складывается в массив orders, а вью-контроллер получает соответствующее уведомление посредством вызова changed.raise().

В методе showOrderDetails(forOrderIndex:) мы находим нужный заказ и должны открыть новый экран, который отображает детали этого заказа. Чтобы модально показать экран в iOS, нужно создать контроллер этого экрана и воспользоваться методом present(_:animated:completion:), который следует вызвать на текущем контроллере.

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

Стоп, что за сервисы вообще такие?

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

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

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

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

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

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

1. Декомпозируйте функциональность приложения на (микро)сервисы с четко определенной зоной ответственности.
2. Активно используйте композицию сервисов для повторного использования кода.
3. Используйте DI-контейнер для разрешения зависимостей.

Некоторые сервисы могут заниматься роутингом, помогая вью-моделям осуществлять навигацию на новые экраны приложения.

Обязательно нужен отдельный сервис для роутинга?

Действительно, если действие пользователя, такое как тап в ячейку, прилетает сразу в контроллер, почему бы из этого контроллера не показать новый экран простым вызовом present(_:animated:completion:). Я голосую против, потому что такой подход удобнее только на первый взгляд:

1. Не всегда переход на другой экран результат действия пользователя. Например, мы можем захотеть показать новый VC по окончании какого-то асинхронного запроса, который будет происходить во вью-модели.
2. Решение о том, какой экран показать, не всегда тривиальное. Это может быть результат работы сложной бизнес-логики, поэтому удобнее запустить показ экрана в том месте, где вся эта бизнес-логика происходит.
3. На логику, упомянутую в предыдущем пункте, могут быть написаны тесты. Роутер можно замокать и производить проверки относительно того, какой экран мы собираемся открывать в том или ином случае.
4. В целях отладки кода удобно иметь единую точку входа для всей навигации в приложении роутер. Это позволяет поставить брейкпоинт в нужном месте и проследить, откуда осуществляется тот или иной переход.

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

Окей, автор, как мне реализовать роутер?

Вот три простых шага на пути к модальному открытию нового экрана:

1. Найти экземпляр UIViewController, с которого будет осуществляться переход.
2. Создать вью-контроллер нового экрана и вью-модель для него.
3. Осуществить переход на новый экран.

Начнем с того, что объявим сам класс и сделаем его доступным из контейнера:

final class PresenterService: ISingleton {    private unowned let container: IContainer    public required init(container: IContainer, args: Void) {        self.container = container    }}

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

Первый пункт поиск контроллера можно сделать очень просто с помощью нескольких строк не самого элегантного рекурсивного кода:

var topViewController: UIViewController? {   let keyWindow = UIApplication.shared.windows.first { $0.isKeyWindow }   return findTopViewController(in: keyWindow?.rootViewController)}func findTopViewController(in controller: UIViewController?) -> UIViewController? {   if let navigationController = controller as? UINavigationController {       return findTopViewController(in: navigationController.topViewController)   } else if let tabController = controller as? UITabBarController,       let selected = tabController.selectedViewController {       return findTopViewController(in: selected)   } else if let presented = controller?.presentedViewController {       return findTopViewController(in: presented)   }   return controller}

Метод findTopViewController(in:) врывается в иерархию контроллеров, как товарищ майор с обыском, и пытается найти там контроллер, который в данный момент отображается на экране. Возможно, это не самый универсальный способ решить задачу и, если в вашем приложении используется более запутанная структура экранов, потребуются некоторые правки, но идея, думаю, понятна.

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

func present<VC: UIViewController & IHaveViewModel>(    _ viewController: VC.Type,    args: VC.ViewModel.Arguments) where VC.ViewModel: IResolvable {    let vc = VC()    vc.viewModel = container.resolve(args: args) // Тут вся магия    topViewController?.present(vc, animated: true, completion: nil)}

Давайте разбираться. Этот метод невероятно тесно интегрирован с нашей реализацией MVVM и с DI-контейнером и состоит, как вы наверняка заметили, всего из трех строк.

1. В первой строке мы пользуемся тем, что у любого контроллера есть пустой инициализатор, и создаем экземпляр этого контроллера, зная его тип.
2. Во второй строке мы создаем вью-модель и присваиваем ее соответствующему свойству контроллера. Вью-модель мы можем создать благодаря тому, что обязали ее реализовать IResolvable (про это была статья про DI). Нам всего лишь нужно знать ее тип и аргументы, от которых она зависит. Тип вью-модели известен, потому что все вью-контроллеры предоставляют свойство viewModel в рамках реализации протокола IHaveViewModel (про это была статья про MVVM). Кроме того, у нас имеются необходимые аргументы VC.ViewModel.Arguments и доступ к контейнеру прямо из сервиса. При создании экземпляра вью-модели с помощью магии DI-контейнера самым удобным образом разрешаются все ее зависимости. Прочувствуйте момент: DI-контейнер, MVVM и роутинг сходятся здесь и сейчас в одной точке, и эта точка одна строчка кода. Ух!
3. И, наконец, в третьей строке, вооружившись знанием о том, какой вью-контроллер сейчас отображается на экране, мы осуществляем показ только что созданного контроллера с помощью банального вызова present(_:animated:completion:).

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

final class PresenterService: ISingleton {    private unowned let container: IContainer    private var topViewController: UIViewController? {        let keyWindow = UIApplication.shared.windows.first { $0.isKeyWindow }        return findTopViewController(in: keyWindow?.rootViewController)    }    required init(container: IContainer, args: Void) {        self.container = container    }    func present<VC: UIViewController & IHaveViewModel>(        _ viewController: VC.Type,        args: VC.ViewModel.Arguments) where VC.ViewModel: IResolvable {        let vc = VC()        vc.viewModel = container.resolve(args: args)        topViewController?.present(vc, animated: true, completion: nil)    }    func dismiss() {        topViewController?.dismiss(animated: true, completion: nil)    }    private func findTopViewController(        in controller: UIViewController?) -> UIViewController? {        if let navigationController = controller as? UINavigationController {            return findTopViewController(in: navigationController.topViewController)        } else if let tabController = controller as? UITabBarController,            let selected = tabController.selectedViewController {            return findTopViewController(in: selected)        } else if let presented = controller?.presentedViewController {            return findTopViewController(in: presented)        }        return controller    }}

Единственный незнакомый метод, который здесь добавился, это dismiss(), позволяющий закрыть текущий модальный экран. Окончательная реализация OrdersVM, которая с помощью PresenterService научилась отображать детали заказа, выглядит так:

final class OrdersVM: IPerRequest, INotifyOnChanged {    typealias Arguments = Void    var orders: [OrderVM] = []    private let ordersProvider: OrdersProvider    private let presenter: PresenterService    required init(container: IContainer, args: Void) {        self.ordersProvider = container.resolve()        self.presenter = container.resolve()    }    func loadOrders() {        ordersProvider.loadOrders() { [weak self] model in            self?.orders = model.map { OrderVM(order: $0) }            self?.changed.raise()        }    }    func showOrderDetails(forOrderIndex index: Int) {        let order = orders[index].order        // Открываем экран с деталями заказа        presenter.present(OrderDetailsVC.self, args: order)    }}

Как видно, в инициализаторе мы без лишней суеты достаем из контейнера наш PresenterService и используем его по назначению в методе showOrderDetails(forOrderIndex:).

Не хочу модальные экраны, хочу пушить экраны в стэк. Как быть?

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

1. Найти экземпляр UINavigationController, который сейчас виден на экране.
2. Создать вью-контроллер нового экрана и вью-модель для него.
3. Осуществить переход на новый экран.

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

final class NavigationService: ISingleton {    private unowned let container: IContainer    private var topNavigationController: UINavigationController? {        let keyWindow = UIApplication.shared.windows.first { $0.isKeyWindow }        let root = keyWindow?.rootViewController        let topViewController = findTopViewController(in: root)        return findNavigationController(in: topViewController)    }    required init(container: IContainer, args: Void) {        self.container = container    }    func pushViewController<VC: UIViewController & IHaveViewModel>(        _ viewController: VC.Type,        args: VC.ViewModel.Arguments) where VC.ViewModel: IResolvable {        let vc = VC()        vc.viewModel = container.resolve(args: args)        topNavigationController?.pushViewController(vc, animated: true)    }    func popViewController() {        topNavigationController?.popViewController(animated: true)    }    private func findTopViewController(        in controller: UIViewController?) -> UIViewController? {        if let navigationController = controller as? UINavigationController {            return findTopViewController(in: navigationController.topViewController)        } else if let tabController = controller as? UITabBarController,            let selected = tabController.selectedViewController {            return findTopViewController(in: selected)        } else if let presented = controller?.presentedViewController {            return findTopViewController(in: presented)        }        return controller    }    private func findNavigationController(        in controller: UIViewController?) -> UINavigationController? {        if let navigationController = controller as? UINavigationController {            return navigationController        } else if let navigationController = controller?.navigationController {            return navigationController        } else {            for child in controller?.children ?? [] {                if let navigationController = findNavigationController(in: child) {                    return navigationController                }            }        }        return nil    }}

Сервисы, подобные NavigationService и PresenterService, нужно будет написать для всех контроллеров, которые являются контейнерами для других контроллеров как для стандартных типа UITabBarController, так и для кастомных. Группа таких сервисов образует слой роутинга в вашем приложении.

Мне не подходит реализация роутинга. Что делать?

Весь код в этой и предыдущих статьях очень простой, в нем важна скорее идея, а не реализация. Напишите свою версию MVVM, роутинга, используйте другой DI-контейнер все это категорически неважно. Важны основополагающие принципы, важны прямоугольники со скругленными углами и стрелочки между ними:

Вьюха (контроллер) должна держать вью-модель сильной ссылкой. Вью-модель должна каким-то образом уведомлять вьюху об изменении своего состояния. Вью-модель должна зависеть от многочисленных сервисов, один из которых роутер. Используйте роутер для навигации между экранами. Точка навигации точка большого взрыва, который приводит к созданию нового экрана и всех его зависимостей. Роутер должен уметь создавать пары вьюха вью-модель и все сервисы, от которых они зависят. Для этого он вынужден держать ссылку на DI-контейнер.

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

Заключение

Сегодня мы говорили про роль (микро)сервисов в мобильных приложениях на примере роутинга. Сервисы роутинга мостик между миром MVC и миром MVVM. Они помогают вью-моделям осуществлять навигацию на новые экраны и имеют право напрямую обращаться к DI-контейнеру для создания пар вьюха вью-модель.

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

Весь код из этой статьи можно скачать в виде Swift Playground.

Евгений, преподаватель Python

Евгений Булыгин, студент курса Бэкэнд-разработка на Python (Екатеринбург)

Маша, преподаватель курса QA Engineer

Михаил Волков, студент курса QA Engineer

Антон, преподаватель курса Системный и бизнес-анализ (Рязань)

Артем, студент курса Системный и бизнес-анализ (Рязань)

Азамат, преподаватель курса QA Automation (Екатеринбург)

Эвелина Яметова, студентка курса QA Automation (Екатеринбург)

Сергей, преподаватель курса разработки на Golang

Софья Михайлова, студентка курса разработки на Golang

Боли и радости онлайна

• экономия времени на дорогу;
• комфортные условия дома;
• есть записи лекций;
• можно демонстрировать студентам сам процесс работы и инструменты.

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