Лучшая практика использования нескольких сервисов в одном компоненте - PullRequest
Новая
       26

Лучшая практика использования нескольких сервисов в одном компоненте

0 голосов
/ 19 декабря 2018

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

У меня есть боковое навигационное меню с 7-8 пунктами в нем.Нажатие на них должно открыть компонент для редактирования простой формы и отправить обновленные данные в службу, которая соответствует выбранному элементу навигации . 

// responses-routing..
const responsesRoutes: Routes = [
  {
    path: 'responses',
    component: ResponsesComponent,
    children: [
      {
        path: '',
        component: ResponsesHomeComponent
      },
      {
        path: ':type/:childUrl',                <----- here
        component: ResponsesEditComponent
      }
    ]
  }
];

Я сейчас используюодин компонент (ResponsesEditComponent) в

1) Получить поля «type» и «childUrl» из URL-адреса (этот URL-адрес перемещается с использованием маршрутизатора и бокового навигационного меню. Параметры извлекаются с использованием activRoute)

2) Принять очень простой пользовательский ввод

3) Выполнить сервисный вызов для отправки полученного ввода. Решение об использовании службы зависит от полей «type» и «childUrl», полученных из параметров.

В некотором пункте 7-8 пунктов меню будут иметь подпункты, которыетакже будет использовать службы, которые принадлежат их родительскому пункту меню.

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

Я рассматриваю

  • разделить один маршрут на 8 маршрутов
  • использовать 8 компонентов вместо 1, каждый из которых соответствует пункту меню
  • внедрить 1 соответствующую услугу каждому компоненту

но это, кажется, просто повторяющаяся работа.

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

Приветствия.

Ответы [ 2 ]

0 голосов
/ 19 декабря 2018

Я бы сделал эти две вещи более автономными.Элемент боковой навигации не должен знать о каких-либо сервисах ResponsesEditComponent.Он может иметь собственный сервис и, скажем, ActivatedRoute.От ActivatedRoute вы можете иметь дело с состоянием навигационного меню.С помощью сервиса вы можете подписаться на любые «подсветки того или иного» события.И служба может отправлять эти события, внедряясь с вашими службами ResponseEdit.

И у ResponseEditComponent, вероятно, также должна быть только одна служба-обертка.Это легко, почти тривиально, проверить.Отправьте компоненту данные: type и: childUrl (пожалуйста, дайте им больше описательных имен).Нарисуйте соответствующую форму (возможно, вы можете иметь разные подкомпоненты для разных форм, дальнейшее разделение слоев).Загрузите данные формы, если таковые имеются, на основе заданного типа.Когда форма (или вложенный компонент) выдает изменение, например, Сохранить событие, вызовите службу с помощью simple (type, childUrl, emittedData).Служба должна быть в состоянии определить, на какой подсервис перенаправить сохранение.

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

0 голосов
/ 19 декабря 2018

Общее поведение вызывает общие компоненты.

В Angular вы кодируете по составу, а не по расширению: вы реализуете несколько интерфейсов (OnInit, AfterViewInit, CanActivate и т. Д.) Для своих классов, определяя их поведение, вместо расширения ваших классов другими классами.

Если бы у меня было 8 маршрутов, которые делали бы одно и то же, но вызывали разные конечные точки, я бы:

  • Сделать 1 компонент
  • Сделать 1 сервис
  • Использование распознавателей для переопределения URL-адреса API для каждого маршрута

Если бы 8 маршрутов имели несколько иное поведение, я бы

  • Сделал бы 1 службу
  • Сделать 1 компонент
  • Использовать средство разрешения фабрики компонентов для создания компонентов с немного отличным поведением
...