Лучшие Лрактики в Angular

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

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

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

Если да, то как сделать код более читабельным?

Простой! Вам нужно только следовать некоторым советам, которые вам даст эта статья. Опять же, я так работаю, и мне это нравится. Вы можете иметь иное мнение, чем я, и при этом быть полностью правдивым. Итак, давайте начнем в этот раз. 😊

Angular CLI

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

В CLI есть инструменты для создания каркасов (иначе говоря, схемы) для создания новых проектов и генерации нового кода для вас. Однако не это главное преимущество. Основным преимуществом интерфейса командной строки является то, как он автоматизирует конвейер сборки как для разработки в реальном времени с ng serve, так и для производственного кода, который вы отправляете в браузеры с ng build -prod.

ЛИФТ Принцип

Давайте посмотрим на принцип LIFT.

Этот принцип помогает быстро находить код. Итак, если вы не используете этот принцип, спросите себя: как быстро вы сможете открывать и работать со всеми файлами, которые вам нужны для создания функции? Мой совет: уважайте и пользуйтесь LIFT.

Значимые имена

Очень важно давать хорошие имена методам, переменным и параметрам.

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

Правило 5 секунд

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

Организация для удобства чтения

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

• Один элемент на файл
  → Один файл должен иметь только один компонент, и то же самое верно для служб или директив.
• Ответственность за один принцип
  → Один класс или модуль должен иметь только одну ответственность.
• Именование символов
  → Свойства и методы должны быть в верблюжьем регистре (например, currentUser).
  → Классы (компоненты, службы, директивы ...) должны быть в верхнем регистре, называемом регистром Паскаля ( например, UserComponent).
  → Компоненты и сервисы должны иметь соответствующий суффикс в названии.

UserComponent

UserService

→ Импорт

Сначала идет внешний импорт

Оставьте пустую строку перед импортом файлов из собственного приложения

Это дает нам простой способ идентифицировать внешние файлы и файлы приложений

• Маленькие функции
  → Маленькие функции лучше читать и быстрее понимать цель. Если ваша функция имеет более 10 строк, вам нужно спросить себя, не лучше ли разбить ее на более мелкие функции. Это может быть сложно сделать, но, к сожалению, в реальном мире мы видим множество огромных функций, которые трудно читать из-за размера и сложности. На мой взгляд, это важная практика, которой должен следовать каждый.

Сначала внесите ясность в код

• Код с самоописанием
• Замена магических строк константами (повторное использование кода)
• Объясняйте в коде, а не в комментариях
• Комментарии должны быть удобочитаемыми и сохраняться
• Избегайте комментариев, когда:
  → объясняет, «что» делает код.
  → Устаревшие и некорректные (неправильные комментарии хуже, чем отсутствие комментариев).
  → Вместо этого используйте хорошо названную функцию.
  → КОД НИКОГДА НЕ ЛЖИТ, ИНОГДА КОММЕНТАРИИ.
• Используйте комментарии, когда:
  → объясните «зачем» вы это делаете.
  → Объясняем последствия.
  → API Docs.

Рекомендации по использованию компонентов Angular

• Рекомендуется использовать префикс для ваших компонентов. Если вы используете Angular CLI для создания компонента, по умолчанию CLI будет префикс вашего компонента следующим образом: selector: ‘app-component-name’. Вы можете решить, оставить ли «приложение» в качестве префикса или изменить его на название проекта. Если вы используете раздел функционального модуля, вы можете использовать имя каждого функционального модуля, чтобы различать каждый компонент по префиксу. Например, если название вашего проекта - «DIGITALSTORE», вы можете поставить «ds» в качестве префикса. (‘Ds-component-name’).
• Разделение файлов HTML, CSS и TypeScript также является хорошей практикой. Это позволяет нам иметь более организованные и читаемые файлы.
• Входы
  → Вы можете объявить декоратор ввода внутри декоратора компонентов, рядом с селектором, шаблоном и т. Д. Но это не рекомендуется. Лучше всего объявить его внутри класса и в начале вот так.

→ Для декоратора вывода правило точно такое же.

• Делегирование сложной логики службам
  → Мы хотим, чтобы наши компоненты были максимально простыми. Это означает, что если нашему компоненту нужно выполнять какую-то сложную логику, нам нужно решить, принадлежит ли эта логика компоненту или нет. Если мы говорим об одной или двух логических линиях, возможно, лучше оставить ее в компоненте. На мой взгляд, компоненты не несут ответственности за выполнение сложной логики. Мы можем оставить это службе, чтобы наш компонент работал как почтальон, который получает пакет и знает, что он должен отправить его кому-то без необходимости знать содержимое пакета. Это окончательное решение, которое вам нужно принять в собственном приложении.
• Компонентная последовательность элементов
  → Открытые методы должны быть объявлены перед частными. Это легче читать или находить, потому что таким образом мы можем предотвратить потерю частных методов среди множества общедоступных методов. Обратите внимание, что по умолчанию все методы являются общедоступными, поэтому для объявления частных методов вам необходимо написать ключевое слово private перед именем метода.

• Реализация интерфейса ловушки жизненного цикла
  → Мы должны объявить интерфейсы ловушки жизненного цикла, чтобы предупредить нас, если мы не используем объявленный интерфейс. Например, когда мы используем ngOnInit, если мы объявляем реализацию следующим образом:

тогда, если мы не создадим это, мы получим предупреждение о том, что нам не хватает ngOnInit:

Рекомендации по использованию сервисов Angular

• Сделать сервисы инъекционными
  → Это необходимо только тогда, когда сервис внедряет другой сервис, но рекомендуется использовать каждый раз, потому что вы никогда не знаете, когда сервису нужно будет внедрить еще один (зависимость инъекция) и будет трудно вспомнить, что мы решили не использовать инъекционный декоратор.

→ Мы можем использовать @Inject внутри конструктора и удалить глобальный @Injectable, но это не рекомендуется, если в этом нет необходимости. Например, если внедряемая вами служба не использует тип данных service в качестве этой службы. Это требование встречается редко, и обычно оно нам не нужно. Рекомендуется всегда использовать @Injectable. Кроме того, нам понадобится больше кода, потому что нам нужно будет сделать это для всех параметров.

• Использование сервисов для поиска данных
  → Как мы уже говорили выше, вы должны использовать единый принцип ответственности. Наш компонент должен вызвать службу, чтобы получить некоторые данные. Например, мы можем напрямую вызвать API в компоненте ... хорошо, код прост, но для соблюдения этого принципа лучше всего поместить эту логику в службу. Служба может вызывать API, localStorage или фиктивную структуру, которая помогает нам во время разработки, но для нашего компонента это должно быть прозрачным. Если нам нужно обновить вызов в нашем сервисе, компонент останется прежним. Компоненту не нужно думать, как получить данные, и ему не нужно знать, поступают ли данные из API или из localStorage. Ответственность компонента заключается только в том, чтобы знать, что у него была необходимость позвонить в службу. Служба обязана знать, где и как получить данные. Поэтому, пожалуйста, избегайте соблазна вызывать API непосредственно на вашем компоненте.

Заключение

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