Учебник по правильному созданию реальных приложений с компонентами Angular 1.5.

В предыдущем посте я представил компоненты Angular 1.5 как новые строительные блоки для приложений Angular. Компоненты имеют значительные преимущества по сравнению с директивами или маршрутами с контроллерами, страдающими от проблем с наследованием области видимости.

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

Идея компонентов настолько хороша, что они стали строительными блоками многих современных веб-фреймворков, включая Angular2, React, Vue.js, а теперь и Angular 1.5.

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

Шаг первый: все, что вы видите, - это компонент

Для построения с вашими компонентами вы просто разбиваете свою страницу на логические разделы и превращаете их в компоненты.

Это ничем не отличается от того, что предписывают React, Vue.js или Angular 2. Фактически, вот изображение из учебника Vue.js о том, как создавать с помощью компонентов. Обратите внимание на форму дерева, она обычно определяет пути взаимодействия между компонентами: родительский-дочерний, дочерний-родительский и братья и сестры.

Так как же нам использовать эти компоненты?

Просто сделайте все как компонент! В этом примере кода я создаю один компонент root или app для размещения всего приложения и разделяю три общих или общих в отдельные компоненты.

  • app-header вверху заголовка страницы с логотипом, строкой поиска и ссылками на профиль.
  • app-nav боковая панель навигации между разделами нашего приложения или страницы.
  • app-footer нижний колонтитул страницы с информацией об авторских правах, условиях использования, конфиденциальности, о нас, карьере и т. д.
  • ui-view маршрутизируемый контент, мы увидим, как маршрутизировать напрямую к компонентам с помощью ui-router.

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

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

Разумность: наличие одного компонента ‹app-header›, описывающего заголовок, является преимуществом. У него будет свой каталог / модуль и свои тесты. При необходимости его можно разбить на бизнес-компоненты и презентационные компоненты, и любой новый разработчик, входящий в код, может сразу предположить, что app-header - это компонент, содержащий заголовок.

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

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

"Дьявол кроется в деталях." Мы знаем, как создавать структурные компоненты, но насколько вложенными должны быть деревья компонентов? Как мы трассируем компоненты? И как мы отправляем данные от одного компонента к другому? Сначала давайте посмотрим на базовую парадигму дизайна, которую выявил мир React: управление состоянием путем разделения задач между презентационной и бизнес-логикой или компонентами контейнера.

Шаг второй: маршрутизация к компонентам

Сторонняя бета-версия ui-router сделала маршрутизацию к компонентам невероятно простой. Вот синтаксис:

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

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

Мы разделили задачи получения данных и обработки. - @learnreact https://medium.com/@learnreact/container-components-c0e67432e005#.leyjwxg4w

Шаг третий: разделение проблем

Дэн Абрамов, автор React Hot Loader и Redux, написал замечательную ссылку для разделения проблем компонентов в своей статье Компоненты представления и контейнеры. Его стоит прочитать, и его нельзя обобщить без репликации, но в целом подход состоит в том, чтобы сохранить состояние, выборку данных и обработку действий в рамках компонента контейнера, а также DOM и состояние мутаций в презентационных компонентах.

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

Например, если вы вводите текст в новый объект Todo в компоненте формы Todo, то вы изменяете состояние значения элемента ввода формы, но компонент формы Todo не должен обновлять состояние приложения с новым Todo, когда пользователь нажимает кнопку Добавить. Todo From должен просто запустить обратный вызов события. Вот пример этого Тодда Мотто в его Руководстве по стилю Angular 1.x.

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

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

В обзоре

  1. Пользовательские компоненты повсюду
  2. Маршрутизируйте напрямую к компонентам и позвольте маршрутизатору разрешить их выборку данных
  3. Отделяйте презентационные компоненты от компонентов-контейнеров (или компонентов с отслеживанием состояния)

Сноски

* Более крупное приложение React, вероятно, будет использовать Redux, MobX, Relay или какую-либо другую реализацию Flux для управления асинхронными запросами на выборку данных для компонентов. В этом случае может возникнуть необходимость в компоненте контейнера, отвечающем за выборку данных, а может и не возникать.

дальнейшее чтение