Директива AngularJS против Сервиса против Контроллера


15

Я собираюсь начать реализацию запроса на изменение на внутреннем веб-сайте моей компании, который проверит несколько полей и выделит их, если они соответствуют определенным рекомендациям. Например, если дата рождения сегодня, это поле будет выделено, и во всплывающей подсказке будет указано: «Пожелайте им счастливого дня рождения!».

Спецификации просят, чтобы это было загружено после завершения рендеринга остальной части страницы, поэтому это не увеличит время загрузки. Поскольку я новичок в angularJS, я не уверен в «правильных» способах сделать это.

Вопросы:

Поскольку это включает добавление границ, изображений и атрибутов заголовка (манипулирование DOM), похоже, мне следует использовать директиву.

Тем не менее, он не будет многоразовым или «коротким», как кажется в большинстве директив.

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

Я знаю, как сделать все это в контроллере, но это плохой плохой код: P

Есть идеи, как лучше всего это сделать? По сути, мне понадобится http-вызов для проверки всех данных, который вернет объект со значениями bool для каждого типа 'Call Out', который мне нужно сделать. Затем я пробежусь по этому списку и, если значение равно true, добавлю рамку, изображение и текст всплывающей подсказки.

Я не уверен, что этот вопрос достаточно ясен, поэтому, если вы хотите, чтобы я добавил некоторые детали, пожалуйста, спросите. Спасибо!


1
Почему вы должны использовать только 1 из 3? Мне кажется, что сочетание как минимум директив и сервиса / контроллера было бы лучше здесь.
Пит

Комбинация тоже подойдет, я просто не понимаю, как это должно работать.
Бобо

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

Ответы:


27

Вы правы, есть много вариантов.

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

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

  • Контроллеры: контроллеры подключают и управляют значениями / функциями, связанными с областью $. В конечном итоге $ scope обычно сильно зависит от представления . IE его модель представления.
  • Сервисы: сервисы имеют тенденцию связывать инфраструктуру, серверную часть или другие функции браузера
  • Директивы: директивы позволяют интегрироваться с событиями / функциями DOM, которые не обрабатываются существующими обработчиками.

Таким образом, вы хотите подтолкнуть код в одном из трех направлений:

  1. Код от моего контроллера действительно логически другой кусок данных / логики представления и должен быть разделен на другой контроллер . Обратите внимание, что при работе с элементами в $ scope лучше всего разделять части, за которые отвечает каждый контроллер, на свои собственные объекты в $ scope. Например, $ scope.creditCard. [Blah] для одного контроллера против $ scope.billingAddress. [Blah] для другого контроллера. Это помогает предотвратить проблемы с использованием angular наследования прототипов в $ scope.

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

  3. Код от моего контроллера сильно связан с организацией представления / DOM, и поэтому должен быть разделен на собственную директиву

Пример 1. может быть для обработки ввода / проверки кредитной карты отдельно от остальной формы оплаты. У вас будет куча логики кредитных карт в контроллере, отдельная от логики, позволяющей пользователям вводить адреса, чтобы они были логически отдельными контроллерами.

Примером 2 может быть перемещение части, которая связывается со службой поддержки кредитных карт, для принятия / отклонения платежа. Или другим примером может быть модуль, который обращается к бэкэнду для обработки API создания пользователя.

Примером 3 может быть создание какой-либо функции автоматической вкладки, которая перемещает курсор между 4 полями редактирования после ввода 4 чисел для кредитной карты.

Разделите ваше приложение соответственно.


Это действительно помогло мне понять больше об угловых. Большое спасибо :)
Бобо,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.