Привет. Подскажите, плз, обращение к сервису в темплейте это большой

грех или может есть метод покрасивее?

Допустимо - но в данном случае я бы написал директиву в которой бы заюзал сервис для установки свойства [link]. Все что как-то меняет DOM - используй директивы.

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

Имхо, за такое по руках бить нужно)

почему?

Логику в темплейт не надо пихать)

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

А я вообще промахнулся, я хотел на его вопрос ответить, а вышло на твой ответ)

Аааа ) бывает)

Почему?

Серьезно?)

Потому что это не PHP?

Да, мне интересно, можете ответить конкретно?

Вы правы, это также не лампа и даже не глобус)

логика пишется либо в сервисах либо если уж очень простая в компонентах. Шаблон ничего не должен решать. Кроме как отображать данные.

Вы не закончили мысль. Там должно быть еще самое важное "потому что ...."

https://developer.mozilla.org/en-US/docs/Glossary/MVC

Вы считаете, что в ангуляре мвс? Всё таки холивар был разрешен выше, но давайте продолжим, если вы того желаете. Мы обсуждали размещение ридонли переменных в темплейтах. Некоторые отдельно взятие берут эту простую операцию, обзывают её "размещать логику в темплейте" и начинают бороться с какой-то супер огромной проблемой, приплетая сюда и ченджДетекшнСтратегии и другие умные слова, с которыми встретились Посыл простой. Не дублировать переменные вида user = this.service.user, а вызвать эти переменные в темплейте по виду {{service.user}} в рамках ограничений service per component. Где здесь противоречие мвс и прочим умностям? Из плохо что мы получили: 1) сервис из приватного модификатора доступа получает публичный 2) какая-то неведомая проблема с каким-то абстрактно непонятным переделыванием сервиса в неопределенном будущем, которая может заафектить поддержку Вы или @oligarhe можете еще чем-нибудь полезным пополнить умозаключения, кроме "атата сейчас всех будем по руками бить"? Если да, сердечно прошу Вас. Если нет, давайте не будем продолжать

1) соблюдение правил инкапсуляции. Компоненты могут использоваться через viewchild, тогда юзер может получить доступ к сервису и использовать его. Затем, любые изменения приватного свойства приведут к цепочке изменений дальше. 2) правило деметры. Чем меньше вложенность с которой мы работаем, тем проще проводить реакторинг. Например public user$ = service.getUser() будет проще редактировать, если мы усложним заменим сервис, или поменяем метод. Шаблон при этом менять не придется. https://habr.com/ru/post/512716/. Это всего лишь бест практисы, к ним можно прислушиваться, можно не прислушиваться. Почему так агрессировать на этот счет - мне не понятно

То бишь, ровно те 2 пунктах, о которых я написал выше. К которым мы пришли еще выше

Нет агрессии, просто одно и то же уже который круг обсуждаем

"атата сейчас всех будем по руками бить"? Это ты обещал ему руки сломать? 😳

[2] Проблема как раз таки вполне известная. Вы теряете контроль над переменной в самом компоненте. К примеру, в сервисе на это переменную вешают геттер-функцию, в результате пострадает перф, а никто и не заметит.

А если не вешают? 😱

А если вешают? ))

Circular dependency detected

Вот к чему обращения к сервису в шаблоне приводят))

Сервиса в сервисы вы имеете в виду? О божечки, еще одна мысля хорошая по теме, жаль что не по той)