Angular-styleguide: Предложение: изменить с "do" на "рассмотреть" добавление суффикса "Service" к классам Service (02-04), потому что это не улучшает ясность и не добавляет ценности.

@GUSCRAWFORD у официального руководства по стилю Angular есть несколько веских причин 😃. Обратите внимание, что это не строгие правила, но, если вы спросите меня, я стараюсь следовать им каждый день, так как они написаны экспертами Angular 😏

@bampakoa В чем, по 02-04 ?

• Каков пример недостатка _не_ следования за ним?
• Почему полезно иметь службу с явным именем *er или *Service

Со своей стороны, чтобы сыграть защитника дьявола, единственный пример ценности, который приходит на ум, - это реализация CanActivate , и, глядя на файловую структуру, стоит знать, что я _не_ внедряю это в компоненты или другие службы. Я мог легко справиться с этим и со структурой каталогов.

Если я вижу переменную с именем User , я бы предположил, что это экземпляр модели пользователя; Вероятно, он будет иметь такие свойства, как User.id , User.email и т. Д.

И наоборот, если я вижу переменную с именем UserService , я бы предположил, что это служба; Вероятно, у него будут такие функции, как UserService.fetch() , UserService.update() и т. Д.

Я думаю, это улучшает ясность.

@GUSCRAWFORD В дополнение к комментарию @mattgrande :

• Я увидел огромное преимущество при работе в командах с другими разработчиками или даже когда мне нужно сотрудничать через plnkr или codepen , возможно, для воспроизведения ошибки.

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

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

Нет ничего плохого в том, чтобы не следовать правилам, вы все равно будете писать на Angular: smiley: Очень полезно, что мы, разработчики Angular, говорим на одном языке и используем одни и те же обозначения в повседневном кодировании.

@mattgrande Я почти согласен, только когда я думаю о том, что User , я в значительной степени знаю, что это сервис, если я его использую, потому что он находится в моей сигнатуре конструктора, где он вводится.

@bampakoa :

• Расскажите, какое огромное преимущество вы имели при работе с командой, и как явно названный xService устраняет путаницу; Я определенно вижу дополнительную иллюстративность в кодовой ручке
• Растущая кодовая база: разве вы не разделяете службы в другой каталог? Разве я не должен быть тоже? (Я также не предлагаю изменить соглашение об именах файлов)
• Приведите мне пример (вариант использования) использования gulp для поиска сервисов? Я не думал об этом, я нашел этот (AJs) пакет интересным, но несколько спорным с инструментами CLI;

:) Не пытаюсь быть излишне разборчивым, но там:

1. Должен быть _ некоторый вред_ или явный недостаток несоблюдения правила руководства по стилю, следовательно, не имеет большого значения без него
2. Я согласен, что мы должны говорить на одном языке, но DI - это более широкая концепция, которая подразумевает обозначение Service без особой необходимости.
3. Дело не в моих собственных идиосинкразиях - если я остаюсь в пределах 02-04 и использую CLI для создания UserManager > ng g s user-manager я получаю UserManagerService несмотря на er (в документации указано, что Logger качестве хорошего примера) является допустимым именем.
   
   
   
   • Очевидно, что User также является технически приемлемым именем, несмотря на путаницу - тем более, что мне кажется, почему бы просто не упростить и не отказаться от рекомендации суффикса Service и рекомендовать прекратить добавление в cli
   
   

Я чувствую, что это просто лишний набор текста, а не улучшение читаемости или ясности

Расскажите об огромном преимуществе, которое у вас было при работе с командой, и о том, как явно названный xService устраняет путаницу.

Я думаю, что каждая команда разработчиков должна соответствовать одному и тому же набору правил в контексте одного и того же языка. В нашей команде фронтенд-разработчиков, которая состоит в основном из разработчиков Angular, нам нужно быстро понимать исходный код друг друга, если нам это нужно. Подумайте, что будет. Если я использую суффикс Service , другой суффикс SVC, а третий - ни один из них.
Я обнаружил, что это также полезно, когда мне нужно заглянуть в приложение через некоторое время. Вам не нужно помнить, что этот Пользователь ввел в ваш компонент 😃

Растущая кодовая база: разве вы не разделяете службы в другой каталог? Разве я не должен быть тоже? (Я также не предлагаю изменить соглашение об именах файлов)

Я предпочитаю структуру папок по функциям . Это дает мне лучшее понимание структуры моего приложения.

Приведите мне пример (вариант использования) использования gulp для поиска сервисов? Я не думал об этом, я нашел этот (AJs) пакет интересным, но несколько спорным с инструментами CLI;

В моем случае нет необходимости использовать его, но я знаю, что он будет там, если мне придется.

@bampakoa - это причина, по которой вам нравится правило, а не пример правила, позволяющего избежать путаницы для вашей команды. Отсутствие оного - яркий пример, подтверждающий мою точку зрения.

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

Если бы я никогда даже не видел ваш код или смотрел на него впервые, я мог бы вывести те же детали дизайна без инъекций, явно названных xService

Я хочу создать службы с клиентом, и только в этом случае добавление суффикса службы к имени должно быть явным (например, Ng cli g "myService")