Первый проект

Создаём новый проект и разбираемся что там и для чего

Для демонстрации примеров я буду пользоваться сервисом https://stackblitz.com/, на котором можно создать приложение на Angular, тут же отредактировать и посмотреть результат, кроме того, можно открыть как проект любой открытый репозиторий с гитхаба. Для локальной разработки потребуется установить утилиту @angular/cli. Весь код выложен в репозитории https://github.com/vporoshok/angular-tutorial.

Итак, после установки командной утилиты @angular/cli в удобной для нас директории создадим новый проект, набрав в командной строке:

ng new angular-tutorial

где angular-tutorial это название нашего проекта, а заодно и папки, которая будет создана. Эта команда развернёт каркас нового проекта и установит необходимые для дальнейшей работы пакеты. Вот что мы получим в итоге:

Свежесозданный проект

Давайте разбираться что же за файлы были созданы, и что с ними можно делать. Начнём с корня проекта, и первый файл, который вы видите:

.angular-cli.json

Это файл конфигурации сборки приложения (или приложений, как мы увидим в следующих статьях). В данный момент он не представляет для нас особого интереса. Подробную информацию о нём можно найти на странице вики: https://github.com/angular/angular-cli/wiki/angular-cli.

.editorconfig

Это файл настройки оформления исходного кода, который поддерживается сейчас практически всеми редакторами. Подробнее про него можно почитать на официальной страничке: http://editorconfig.org.

Этот файл не относится к ангуляру от слова совсем, однако, в него мы внесём изменения, потому что я воспитан на pep8 и от вида отступов в 2 пробела у меня начинает болеть голова. К сожалению, как я уже упомянул, сами разработчики @angular/cli всячески открещиваются от существования этого файла (правда тогда совсем непонятно — зачем же они его добавили?), но надежда живёт.

karma.conf.js

Karma — это утилита для запуска тестов. По умолчанию для выполнения кода используется Chrome, что делает практически невозможным запуск тестов на CI. Вообще из существующих фреймворков тестирования мне больше всего нравится Jest, а для выполнения кода, конечно, Puppeteer. Но о тестах и их настройках в другой раз.

package.json

Ну, тут нет ничего необычного, за исключением разве что подготовленных скриптов для стандартных действий: start, build, test, lint и e2e.

protractor.conf.js

Protractor — это ещё один «запускатель» тестов. «Подожди, — скажете вы, — у нас же уже есть запускалка, эта, как её там… Karma!» Да, есть karma, а есть protractor. Они для разных тестов. Karma для unit-тестов, а protractor для так называемых end-to-end тестов, а если говорить по-русски, тестирования пользовательских сценариев. То есть когда мы собираем всё приложение, а потом начинаем имитировать поведение пользователя. Так вот protractor не обычный «запускатель», его написали разработчики ангуляра, специально для тестирования ангуляра. И он имеет из коробки глубокую интеграцию с фреймворком. Но об этом точно в другой статье.

tsconfig.json

Вас ведь предупреждали, что ангуляр не для слабых духом? Самая сильная на мой взгляд черта ангуляра — это TypeScript. Это надмножество javascript со строгой типизацией (по крайней мере так он позиционировался в начале своего пути, однако, уже давно стал большим, чем просто javascript с типами). Файл tsconfig.json, как следует из названия содержит настройки компилятора typescript. Тут стоит с самого старта проекта прописать 2 правила: "strictNullChecks": true и “noImplicitAny”: true. Первая настройка заставляет проверять nullable-переменные на null, а вторая — запрещает объявлять переменные и параметры без типа. Подробнее про все настройки можно почитать тут: http://www.typescriptlang.org/docs/handbook/tsconfig-json.html

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

tslint.json

Это настройки утилиты tslint статической проверки кода. Незаменимая вещь, когда над проектом работают несколько человек, хотя я использую её и в личных проектах. Самое классное в ней это хорошая интеграция с Visual Studio Code, а также возможность автоматического устранения многих проблем с помощью ng lint --fix.

С корнем покончили, пойдём по папкам, их у нас 3:

• e2e — папка для end-to-end тестов;
• node_modules — сюда ставятся все пакеты, необходимые для нашего проекта;
• src — собственно исходный код нашего проекта!

Исходный код

Здесь тоже всё не просто… ну, то есть не плоско. В корне директории исходного кода помимо favicon.ico лежат следующие файлы:

index.html

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

main.ts

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

polyfills.ts

Файл для подключения полифилов. Тут стоит оговориться: проект собирается при помощи webpack, который конфигурируется на основе .angular-cli.json, с помощью Angular DevKit.

Для любопытствующих, кое-какие обломки конфигов webpack, на основе которых собирается конфиг, который собирает ваше приложение, можно найти вот тут: https://github.com/angular/devkit/tree/master/packages/angular_devkit/build_angular/src/angular-cli-files/models/webpack-configs, но эта ссылка может устареть очень быстро, потому как devkit сейчас очень быстро развивается и изменяется.

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

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

styles.css

Как написано внутри файла, здесь вы можете объявить глобальные стили своего проекта. Вообще, в названии и местоположении этого файла нет никакой магии, он прописан в .angular-cli.json в настройках приложения, в списке styles, так что его легко можно переместить (требуется для сборки нескольких приложений из одного проекта) или, например, поменять ему расширение на .scss, если вы используете этот препроцессор. В @angular/cli подключены многие базовые загрузчики webpack.

test.ts

Входная точка для unit-тестов. По сути здесь создаётся базовый тестовый модуль ангуляра, после чего отыскиваются все файлы с названием, заканчивающимся на .spec.ts и выполняются. Подробнее поговорим об этом в статье про тестирование.

tsconfig.(app|spec).json

Дополнительные настройки для сборки приложения и тестов, которые наследуются от базовых настроек из файла tsconfig.json, лежащего в корне проекта. В основном они настраивают исключение из сборки приложения тестовых файлов, а к сборке тестовых фалов подключают определения типов (definitions type script или .d.ts-файлы) тестового фреймворка Jasmine.

typings.d.ts

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

Typings reference file, you can add your own global typings here
https://www.typescriptlang.org/docs/handbook/writing-declaration-files.html

Однако, в следствии достаточно активного развития проекта @types, он стал фактически не нужен. Теперь в нём содержится описание странного интерфейса какого-то NodeModule. Это наследие старых времён, когда для правильной линковки относительных путей до фалов шаблонов и стилей требовалось прописывать идентификаторы файлов в файловой системе вручную. Теперь же для этого используется специальный загрузчик, который нормально обрабатывает относительные пути.

environments

Папка содержит конфигурации различных окружений для сборки, которые можно выбирать флагом -e <название окружения> при сборке проекта, а значения переменных можно вытаскивать примерно как это делается в main.ts:

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

assets

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

app

Это последняя папка, которую мы ещё не обсудили. Это по сути и есть наше приложение. Но о ней в следующий раз.

Собираем, запускаем

Ну, вот наконец-то мы разобрали все файлы, не относящиеся к бизнес-логике нашего приложения. Можно смело набирать в командной строке ng test или ng lint, или ng build. Для всех частых команд в package.json прописаны алиасы для использования локальной утилиты ng.

Кстати, можете обратить внимание на то, что npm start и npm run build соберут разный набор бандлов. Это всё потому что во время сборки для разработки (npm start) ваш код отделяется от кода библиотек, для того чтобы пересборка была максимально быстрой. Это образует бандл vendor.