Как стать автором
Обновить
75
0
Роман Седов @MarsiBarsi

Angular Google Developer Expert

Отправить сообщение
Ага, у меня было так, что DI шел тяжеловато, но когда разобрался, то полюбил :)

Могу порекомендовать тут скринкаст Степана Суворова на ютюбе, там базовые штуки: www.youtube.com/watch?v=bJvBRJUytgg&list=PLDyvV36pndZF-vwsVB48ivZyNJ4ETBKNY&index=14

Более фундаментально про саму концепцию IoC и конкретно DI есть интересная серия видео у Ильи Климова:
www.youtube.com/watch?v=ETyltCwtQHs&list=PLvTBThJr861xKTf1x6P49MwN6yoN4v69k

На почитать могу собственный материал порекомендовать: первая глава в angular.institute. Только там на английском, надеюсь не будет проблемой

Обычно формы живут в рамках одного компонента, поэтому с ними таких вопросов не возникает.


Бывают случаи сложнее, когда форма большая и хочется ее разнести. Помню был случай, когда сложный компонент вроде выпадающего календаря нуждался в данных контрола, но с дефолтным значением. Тоже решали частными провайдерами и вот такой штукой в useFactory: https://twitter.com/marsibarsi/status/1269201441756979200

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

У нас провайдеры хорошо упрощают код в кейсах, когда компонент зависит именно от данных. Для других случаев мы используем как обычные сервисы, так и разные вроде Observabled-based или Subject-based варианты, как в статье, ссылка на которой в комментарии ниже
да, все верно :)
Приведенный в статье кейс очень простой, но это плата за лаконичность статьи. Сложный кейс мог бы дать один конкретный хороший пример, но замылыть суть самой идеи. Я выбрал первый вариант

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

Возможно, не до конца вышло донести мысль, что это лишь один из альтернативных подходов и точно не заменяющий все остальные :(
Круто, статья мотивирует и заряжает! Надеюсь после таких публикаций будет появляться больше и больше локальных комьюнити :)
Привет!

Мне нравится, что мы можем положить в npm не только необходимые файлы, но и оставить в этих файлах только самое необходимое. `files` в `package.json` будет достаточно для обычной JS библиотеки. Если взять, например, Angular Workspace с библиотекой, то там создание отдельной папки для публикации просто необходимо, потому что мы передаем в npm иной `package.json` — очищенный от зависимостей и информации, которые не относятся к финальной либе

Да, вызов release остался открытым. Если проект будет развиваться, то стоит настроить авторелиз release-веток
C tslint согласен. Хотя typescript'еры не очень охотно переводят на него свои проекты, рано или поздно придется. Кстати, вот здесь roadmap tslint на закрытие пакета в несколько стадий

В пункте про `standard-version` я хочу показать возможность решить вопросы о наименовании коммитов, ведении changelog-файла и версионировании разом. npm version в данном случае решает только третью задачу
К сожалению, да. Но пока работает без проблем. Также знаю ребят, которые готовят достойную альтернативу. Как только выпустят — обязательно отпишу здесь
Странно, что не выцепляет по названию из README. Поправил, спасибо!

Информация

В рейтинге
Не участвует
Откуда
Нижний Новгород, Нижегородская обл., Россия
Работает в
Зарегистрирован
Активность