Правильный шаблон для использования метода, объявленного в службе, при работе в шаблоне компонента в Angular - PullRequest
Новая
       10

Правильный шаблон для использования метода, объявленного в службе, при работе в шаблоне компонента в Angular

0 голосов
/ 09 февраля 2020

В большинстве моих компонентов я использую FontAwesome и объявляю их для использования следующим образом. 

import * as fa from "@fortawesome/free-solid-svg-icons";
...
@Component({ ... })
export class SomeComponent implements OnInit {
  constructor(private service: SirService) { }
  add = fa.faPlus;
  ...
  }
}

В реальном шаблоне у меня есть что-то вроде этого. 

<fa-icon [icon]="add" ...></fa-icon>

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

constructor(private sir: SirService) { }
add = this.sir.willGiveMeIconFor("add"); ...

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

constructor(private sir: SirService) { this source = sir; }
public icons: SirService;
//add = this.sir.willGiveMeIconFor("add"); ...

И в шаблоне (после переименования метода в сервисе, чтобы сделать лучше семантика, конечно). 

<fa-icon [icon]="icons.show('add')" ...></fa-icon>

Мне сказали, что объявление службы как publi c в конструкторе - плохая практика. Я также чувствую, что я держу несколько ссылок на него без видимой причины. Поскольку я не делал ничего, используя эту стратегию, я чувствую осторожность, чтобы не забежать дальше, ударив стену дальше.

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

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

1 Ответ

0 голосов
/ 09 февраля 2020

Я бы начал с точного определения того, что нам здесь нужно.

  • Мы не хотим переключаться на другой компонент для поддержки этого (затем вводить службу, как Вы показали),
  • Мы не хотим, чтобы такой вид услуг был во всех компонентах, которые используют FA (кажется, гораздо больше, чтобы написать, что мы выиграем от этого),
  • Я бы поспорил, если этот сервис нужен как логическая часть этих компонентов,
  • В качестве конечного эффекта мы хотим получить значение из службы к директиве [icon], и я думаю, что это ответ на вопрос о соблюдении соглашения.

Затем я бы создал общую директиву с именем myApp-fa-icon или что-то в этом роде и поместил бы там службу, может даже выставить некоторое перечисление для значков в приложении, поскольку сейчас мы действительно переходим от строкового решения к другому строковое решение (но централизованное). Тогда внутри этой директивы я бы принял только это перечисление, а не строку (но возникает рутинная задача импортировать это перечисление в каждый компонент, когда вы хотите сделать что-то динамически с иконкой, но, с другой стороны, это сузит список значков до

И для создания службы публикации c Вам не нужно переназначать его в поле публикации c, просто установите его public внутри конструктора, если хотите.

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

  1. Это будет выглядеть неловко: [icon]="add | my-icon"
  2. Если мы упрямый, мы можем объявить директиву без параметров, которая получит ввод [icon] как @Input() и ngOnChanges(), мы можем просто пропустить все логи c (так что-то вроде этого: <fa-icon [myApp-fa-icon] [icon]="add" ...></fa-icon>, но еще раз - это выглядит немного странно для меня.
  3. Это действительно имеет значение? Это не то же самое, что определение значка - очень тяжелая операция.

Редактировать:

Хорошо, я создаю emaple myselft и должен сказать, что склонен к созданию пользовательского компонента, который будет служить прокси для fa-icon. Он гораздо менее сложен и более читабелен, чем использование директивы.

1 ) директива просто перехватит значение атрибута [icon], заменит его на значение, загруженное из сервиса, и заставит Angular обнаружить изменения, чтобы сделать директиву fa-icon icon для своей работы. Слишком сложно, извините, я думал fa-icon элемент работает немного по-другому.

Вот рабочий пример .

...