Если вы не читали мою первую статью о моем шаблоне стартового набора Angular Dashboard, я предлагаю сначала прочитать ее:
В качестве побочного проекта я также создал репозиторий с урезанной версией моего Starterkit. Также можно применить большинство шаблонов из этой статьи:
Так ты готов? Ой, небольшое предупреждение, это может быть очень долгое чтение :) # извинитеNotSoSorry
Теперь, когда мы нашли «аутентификацию», что мы будем с ней делать…?
Когда я запустил свой стартовый набор, моей основной задачей было продемонстрировать некоторые шаблоны кодирования в Angular при аутентификации (вход в систему, выход из системы, проверка). Но потом я понял, что теперь, когда я продемонстрировал, как создать простую панель мониторинга, вы также захотите совершить эпическое дерьмо в защищенной среде панели мониторинга.
Поэтому я придумал функцию под названием «Предметы». По сути, это просто коллекции элементов, каждый из которых имеет следующие свойства:
- заглавие
- описание
В этой статье демонстрируется шаблон CRUD (создание / чтение / обновление / удаление), а также структурирование некоторых компонентов.
Все дело в компонентах
Когда я переходил с AngularJS на Angular, я все время спрашивал других разработчиков: «чем отличается AngularJS от Angular?». И всегда возникают одни и те же ответы: «все дело в компонентах». Компоненты многоразовые. А с Angular вы должны мыслить как компонент.
Но когда я начал с простого списка, я, конечно же, начал гуглить, как создать список с элементами. Этот список заполняется массивом объектов, и список отображается в представлении с помощью * ngFor. Вот типичный пример:
Это создаст список с элементами. Ничего особенного, это просто работает. Но помните ... все дело в компонентах! Итак, давайте разделим это на 2 компонента:
- ItemsListComponent (в котором будет массив со всеми элементами), вы также можете увидеть его как родительский.
- ItemsListItemComponent (компонент только с одним элементом, полученный из родительского компонента), вы можете видеть его как дочерний.
ItemsListItemComponent (дочерний)
Сначала мы создаем компонент элемента:
Обратите внимание на строку @Input () item: ItemModel;. Декоратор @Input предоставит переменную внешнему миру (за пределами этого компонента), поэтому родительский компонент может привязаться к нему и передавать данные. Так что давай сделаем это.
ItemsListComponent (родительский)
ItemsListComponent по-прежнему будет содержать массив с элементами и будет выполнять * ngFor, но вместо того, чтобы повторять элементы ‹li›, он будет повторять компонент app-items-list-item и передавать элемент из массива в app- Компонент items-list-item (ну .. он привязывается к нему через привязку свойств).
Почему этот узор?
Таким образом, у вас будет лучший контроль (логика и макет) на
- список (родительский)
- элемент в списке (дочерний)
и вы можете повторно использовать компоненты.
В довершение всего, теперь вы можете повторно использовать компонент ItemsList в других компонентах, например
Компоненты CRUD
Итак, теперь мы можем создавать компоненты, похожие на стратегию CRUD:
- ItemAddEditComponent (Создать или обновить)
- ItemsList (Читать)
- ItemEditComponent (Обновление)
- ItemsListItem (Удалить, ну там есть кнопка удаления для удаления элемента)
ItemAddEditComponent
Итак, этот компонент - хороший пример повторного использования компонентов. Этот компонент выполняет 2 функции:
- Обновлять
- Создавать
Эти компоненты могут принимать объект ItemModel (через декоратор @Input ()). Когда присутствует ItemModel, внутренняя кнопка сохранения становится обновлением, а если нет, то кнопкой создать.
В моем стартовом наборе вы увидите это в действии в ItemEditComponent (это передаст ItemModel в ItemAddEditComponent) и в ItemsComponent (который просто будет включать ItemAddComponent без объекта ItemModel).
Добавление логики обслуживания
Итак, теперь нам нужна реальная логика. Я создал службу элементов для хранения данных и взаимодействия с (поддельным) серверным API. Здесь вы также можете увидеть шаблон CRUD, используемый в вызовах API.
Методы HTTP-запроса
На самом деле отправка / получение, мы полагаемся на Методы HTTP-запроса. Наиболее распространены методы GET и POST. Но есть и другие методы, которые мы можем использовать и даже отразить стратегию CRUD:
- POST (Создать), this.http.post
- GET (читать), this.http.get
- PUT (Обновить), this.http.put
- УДАЛИТЬ (Удалить), this.http.delete
POST и PUT немного похожи. Некоторые используют POST для создания и PUT для обновления, а некоторые используют его наоборот.
Так как же это отражает реальный код?
Создавать
Вот фрагмент создания / добавления элемента. Как видите, мы используем метод POST (this.http.post).
Читать
Обновлять
Удалить
Использование TAP как побочного эффекта
Вы могли заметить, что я использовал функцию TAP в своих HTTP-запросах. Tap будет выполнять действия / побочные эффекты, которые не являются частью наблюдаемого потока. Он получит результат (-ы) функции MAP, но не сможет изменить поток. Затем вы можете выполнять действия, которые не имеют прямого воздействия на поток Observable. В моем случае я буду обновлять / удалять / вставлять элементы во внутреннее хранилище сервиса.
Использование хранилища BehaviourSubject
В моем проекте я использую BehaviourSubject для хранения массива моих элементов. BehaviourSubject похож на обычный Subject с некоторыми дополнительными функциями:
- Он может содержать любое зафиксированное значение.
- Может иметь начальное значение
- Любые подписчики, которые подпишутся на BehaviourSubject, получат текущее значение, которое содержит BehaviourSubject.
Таким образом, любые изменения в локальной службе будут проходить через BehaviourSubject, и все подписчики получат новые обновленные данные.
Я написал сообщение на Medium по этому поводу:
Ну вот и все. Еще есть что написать, еда, чтобы поесть, код для отладки :)
Вы можете найти меня на:
- linkedin: https://www.linkedin.com/in/fransjoleihitu/
- GitHub: https://github.com/fransyozef/ последняя
- Instagram: «https://www.instagram.com/thehangrycoder/
- Twitter: https://twitter.com/thehangrycoder
