Принял к сведенью (возможность сократить код в ngOnInit) - в выходные проверю
Пока нареканий в работе не было (про двойные вызовы метода ngModelChange) - в выходные проверю
Так как имеется возможность миграции других проектов в моно-репозиторий а в них может быть смешанная реализация форм решили оставить поддержку шаблонных форм и будем дорабатывать по мере необходимости
По мере улучшения концепта у нас в проекте буду актуализировать репозиторий на github
В случае замены или обновления внешней ui-библиотеки, мы будем переписывать только модуль с обертками.
Для расширения функциональности оберток можем просто написать нужные директивы которые будут дизейблить поля, а можно и написать директивы которые в себе содержат все тайговые директивы - аля варианты Ну и можно применить подход описанный тут -> Концепция директив-контроллеров для компонента в Angular (часть 1,часть 2)
Пользовательские сообщения валидации мы можем провайдить на уровне обертки (используя тайговский токен - TUI_VALIDATION_ERRORS). У нас это просто директива которая на вход принимает словарь ошибок валидации и пробрасывает их в токен
Но в основном мы пользуемся реактивным подходом при работе с формами
Для себя решил так. Использую комбинацию двух методик организации стилей Применяю в компоненте БЭМ Для позиционирования этих компонентов на странице примеяю методологию AtomCSS
Первое! Автору спасибо за вложенные усилие и публикацию статьи
Вопросы
Автору
1) Обычно выносят в файлы тот код который планируют переиспользовать — я правильно понимаю что этот код(провайдер) будет использоваться только в одном компоненте?
2) С коллегами пообсуждали статью и возник еще вопрос. А не будет ли проблем с отловом ошибок если прописали не тот интерфейс в фабрике или месте инжектирования
3) не будет ли сложно поддерживать/использовать такой код?
Комментаторам
1) инжектируя работу роут как параметр разве мы не увеличиваем связанность разных классов — веть сервисы нужны для работы с данными/бизнесовой логикой (то есть даем ему id и получаем список организаций для этого id, сервис не должен знать что такое роутер)
Отвергаешь предлагай
собственно предложить нечего =(
1) разве что сделать какой то базовый компонент для всех компонентов-контейнеров в котором будет инжектиться роутер и стоять геттер на параметры роута (такой метод затрудняет понимание кода, и не стоит того)
Хорошая работа
Очень рекомендую ознакомиться с тем что сделали ребята из Tinkoff у себя в Taiga UI
https://habr.com/ru/companies/tinkoff/articles/546178/
А в чем были нарисованы сей чудесные диаграммы?
PlantUML + кастомизация?
начал глубже разбираться с работой форм
вот статья по теме может будет полезной/интересной
Принял к сведенью (возможность сократить код в ngOnInit) - в выходные проверю
Пока нареканий в работе не было (про двойные вызовы метода ngModelChange) - в выходные проверю
Так как имеется возможность миграции других проектов в моно-репозиторий а в них может быть смешанная реализация форм решили оставить поддержку шаблонных форм и будем дорабатывать по мере необходимости
По мере улучшения концепта у нас в проекте буду актуализировать репозиторий на github
Спасибо за объёмный вопрос
В случае замены или обновления внешней ui-библиотеки, мы будем переписывать только модуль с обертками.
Для расширения функциональности оберток можем просто написать нужные директивы которые будут дизейблить поля, а можно и написать директивы которые в себе содержат все тайговые директивы - аля варианты
Ну и можно применить подход описанный тут -> Концепция директив-контроллеров для компонента в Angular (часть 1, часть 2)
Пользовательские сообщения валидации мы можем провайдить на уровне обертки (используя тайговский токен - TUI_VALIDATION_ERRORS).
У нас это просто директива которая на вход принимает словарь ошибок валидации и пробрасывает их в токен
Но в основном мы пользуемся реактивным подходом при работе с формами
Спасибо за комментарий.
Постараюсь в следующих публикациях понятней расписывать материал.
Вы можете ознакомится с демо на stackblitz
Если кратко то мы делаем удобней работу с внешней библиотекой компонентов
А WMI не позволяет устанавливать ПО на удаленной машине?
если я правильно помню это самая мощное средство администратора
Для себя решил так.
Использую комбинацию двух методик организации стилей
Применяю в компоненте БЭМ
Для позиционирования этих компонентов на странице примеяю методологию AtomCSS
про различные методологии можно почитать тут https://habr.com/ru/post/256109/
стили с переопределениями стилей из библиотек размещаю в каталоге styles/[lib-name]
Спасибо за статью, полезно!
Чет не заметил ссылки на https://docs.emmet.io/cheat-sheet/
а как будут распологаться lazy-load модули?
9_9 копипаст?
P.S. странно но про инжектирование компонентов я знал =)
Вопросы
Автору
1) Обычно выносят в файлы тот код который планируют переиспользовать — я правильно понимаю что этот код(провайдер) будет использоваться только в одном компоненте?
2) С коллегами пообсуждали статью и возник еще вопрос. А не будет ли проблем с отловом ошибок если прописали не тот интерфейс в фабрике или месте инжектирования
3) не будет ли сложно поддерживать/использовать такой код?
Комментаторам
1) инжектируя работу роут как параметр разве мы не увеличиваем связанность разных классов — веть сервисы нужны для работы с данными/бизнесовой логикой (то есть даем ему id и получаем список организаций для этого id, сервис не должен знать что такое роутер)
Отвергаешь предлагай
собственно предложить нечего =(
1) разве что сделать какой то базовый компонент для всех компонентов-контейнеров в котором будет инжектиться роутер и стоять геттер на параметры роута (такой метод затрудняет понимание кода, и не стоит того)