Комментарии 6
В принципе, это решение можно сформулировать проще: директива как сервис. Мы используем такое решение для настройки пермишенов и некоторых других вещей. Можно даже повесить два декоратора сразу.
С этим есть одна неприятность - у вложенных компонентов нельзя ограничить наследование каким-то уровнем, сервис может протекать куда не надо.
А я наоборот люблю DI за то, что мы можем подкладывать и переопределять сущности на любом уровне. Даже если возникает ситуация, где нам хочется ограничить какой-то скоуп от нашей сущности, то всегда можно переопределить ее на null в обычных или viewProviders
Это просто не всегда удобно, скажем, можно сделать некий связующий сервис между компонентами, чтобы связывать их прямо в шаблоне не прибегая к мороке с ручным соединением инпутов/аутпутов/темплейт референсов, в этом случае хочется, чтобы ничего лишнего сервис не делал, не просачивался дальше текущего шаблона. Да, сейчас приходится провайдить null, но это некрасиво и чревато ошибками.
Спасибо за статью!
Есть вопрос по организации кода: у вас большое количество компонент и теперь появляется большое количество директив-контроллеров с конкретной реализацией логики. Как удаётся отслеживать появление новых директив, дублирующих существующую функциональность?
И ещё вопрос, связанный с миграцией старого кода на новый: как организовали переход существующих компонент на директивы-контроллеры?
В директивы-контроллеры не выносится никакая реальная логика, они фактически лишь сокращают путь между местом, куда данные передают (верхнеуровневый компонент), и местом, где их получают (внутренний компонент Textfield), поэтому логика не может перемешаться — она одна и написана в текстфилде. Если мы сделаем еще один передатчик для той же самой логики, то не сможем пропустить это в самом текстфилде.
Про миграцию отличный вопрос, стоило включить это в статью.
Когда я переписывал Тайгу на контроллеры, то назвал инпуты в них аналогично тому, какими они были у самих компонентов. К модулям компонентов добавлялись контроллеры и экспортились из них, то есть изменения прошли только под капотом и полностью бесшовно для пользователей. Единственный потенциальный минус — так можно частично потерять один из плюсов подхода — уменьшение бандла. Если во всем приложении контроллер ни разу не использован, то он все еще заскочит в бандл, хоть и в единственном экземпляре вместо десятка.
Для совсем полной смены подхода можно написать миграцию для ng update, которая будет перепахивать кодовую базу проектов при бампе версии библиотеки и подменять импорты с одного модуля на модуль + набор отдельных модулей контроллеров. Тут могу порекомендовать наш инструмент ng-morph, который упрощает процесс написания + его легче использовать для обычного проекта (если у вас не библиотека и ng update)
Концепция контроллеров компонента в Angular: часть вторая