В отличии от C# или Java, где по интерфейсу можно создавать моковые реализации классов для тестов в Angular внедрение зависимостей служит больше для управления сложностью.
С тестами ничего не изменилось.
Если нужно протестировать сервис у которого нет зависимостей или их мало, то можно создать экземпляр через new MyService()
Если нужно тестировать компонент или что-то другое во что внедряется сервис то все так-же создается тестовый модуль через TestBed и в секции providers: [] мокаются все зависимости.
Если делать отдельный модуль и в нем предоставлять сервис, то в файле этого модуля можно подключить и настроить какие то сторонние библиотеки, которые не хочется подключать в главный модуль.
В таком случае рекомендуется использовать для модуля providers: []
Если действительно понадобится ограничить область видимости сервиса, проще воспользоваться старым способом providers:[], так как он точно не приведет к циклическим зависимостям.
И ещё полезно знать, что есть viewProviders, которые позволяют ограничить область сервиса на шаблон и всех его наследников.
Об этом написано в разделах Внедрение в @Сomponent и @Directive и Внедрение сервиса в компонент (providedIn: SomeComponent)
То что мы каждый день делаем на работе это тоже задачи. И смысл в том, что надо понимать их суть в том числе со стороны бизнеса, и уметь разобраться и декомпозировать. А сайты с задачками как раз и помогают улучшать эти навыки.
Заучивание и изучение это немного разные вещи. Естественно не стоит зубрить все наизусть. Но читать и пытаться понять всегда полезно. Даже для джунов.
теряют возможность самостоятельно думать в вопросах проектирования, и начинают думтать в рамках шаблонов.
В любой технической отрасли есть основы, которые должен знать каждый хотя бы частично. В математике никто не говорит, что использование таблицы умножение это мышление в рамках шаблонов. Или в физике закон Ньютона.
Если вас во время такой практики не посещает мысль, что 1000 строк в одном месте это так себе идея, вам выше кодера не подняться
Из моей практики. Разговоры про «креативный подход и мышление вне шаблонов» начинают обычно как раз те кто пишет такой код, и считает его уже идеальным.
P.S. А вы вышли за рамки шаблонов или потеряли возможность самостоятельно думать?
Одно дело станок для хобби в гараже, другое промышленное оборудование со скоростью перемещения на ускоренном ходу до 30 м/мин. Пролетит перед глазами даже кнопку аварийного останова нажать не успеешь. Стоимостью одной фрезы 5 — 10 к рублей поломка которой уже является существенным косяком. И учитывая особенности обработки от аллюминия до титановых и жаропрочных сплавов. И точности обработки до пяти микрон. Технологического цикла в котором может быть задействовандо 5-10 человек и прочего.
Я не против книг. Как раз за них, но во многих случаях полезнее (особенно для начинающих) краткая инструкция и наставничество. Чтоб человек понимал основные алгоритмы и узкие места своей работы.
С таким подходом можно любую книгу. Например «Совершенный код» можно назвать сборником общих советов. Т.к. некоторые описаные там вещи довольно очевидны.
Может вы считаете, что патерны это тоже архитипы, и не стоит их изучать? Только практика из 1000 строк валидного кода запиханых в один класс или в одну функцию.
Я знаю и ведущих специалистов которые на практике за пять и более лет не научились декомпозировать методы и классы, и думаю для них данная инфа тоже была бы полезной.
То есть если хочешь стать хирургом, то достаточно купить справочник и тесак? И можно прочесть и идти практиковаться?
Около пяти лет занимался программированием станков ЧПУ. И скажу что при ошибке в программе станка велика вероятность повредить оборудование, или нанести ущерб работающим людям.
Человек который считает, что достаточно прочесть книгу видимо никогда не делал ничего серьезного. Или является непризнаным гением.
Любое задание которое вы выполняете на работе это и есть задачи которые перед вами ставят. Только это задачи из реальной жизни. Суть статьи именно о них.
А на собеседовании их обычно задают для проверки уровня кандидата, а не для самолюбия.
По моему опыту примерно 50% собеседуемых не могут ответить на элементарные вопросы, при этом хотят зп 100к +
Про собеседования нигде не написано. Имеется в виду, что разработчик должен комплексно подходить к поставленной задаче, и думать головой, а не просто уметь нажимать на кнопки.
Дать ответ на задачу быстро в условиях стресса, может только человек, который эту задачу уже решал или знает ответ.
Допустим, что нужно срочно сделать какую-то задачу на работе. Её дают вам, а вы говорите: «Извините не могу работать в условиях стресса. Только если я эту задачу раньше решал.» Так получается?
Даже если фитча описана со всеми ньюансами и вы используете TDD со 100% покрытием тестами, редко обходится без отладки через chrome-devtools (если это не hello world, то практически никогда).
redux-devtools — это дополнительный инструмент более удобный чем console.log и debugger.
Можно резюмировать так. Архитектура и фреймворк — это фундамент вашего здания. Если планируется построить небоскреб, то и фундамент должен быть более качественным и глубоким, если это одноэтажный домик, то тогда можно обойтись и минимальными затратами.
Перенося это с метафор на разработку. Если у вашего мини-приложения или стартапа большие амбиции и перспективы роста, то стоит взглянуть на Angular, т.к. он даст много плюсов в перспективе.
В противном случае есть более подходящие инструменты.
С тестами ничего не изменилось.
Если нужно протестировать сервис у которого нет зависимостей или их мало, то можно создать экземпляр через new MyService()
Если нужно тестировать компонент или что-то другое во что внедряется сервис то все так-же создается тестовый модуль через TestBed и в секции providers: [] мокаются все зависимости.
В таком случае рекомендуется использовать для модуля providers: []
Об этом написано в разделах Внедрение в @Сomponent и @Directive и Внедрение сервиса в компонент (providedIn: SomeComponent)
Да и модули с введением import и export устарели.
Зачем одни и те-же устаревшие примеры из статьи в статью копировать?
А потом ими люди пользуются по незнанию(
Можно поинтересоваться а основные парадигмы ООП тоже не нужны?
Вы предлагаете умножать не зная таблицу умножения?
На перфокартах что-ли? Но и тогда были фундаментальные основы.
Заучивание и изучение это немного разные вещи. Естественно не стоит зубрить все наизусть. Но читать и пытаться понять всегда полезно. Даже для джунов.
В любой технической отрасли есть основы, которые должен знать каждый хотя бы частично. В математике никто не говорит, что использование таблицы умножение это мышление в рамках шаблонов. Или в физике закон Ньютона.
Из моей практики. Разговоры про «креативный подход и мышление вне шаблонов» начинают обычно как раз те кто пишет такой код, и считает его уже идеальным.
P.S. А вы вышли за рамки шаблонов или потеряли возможность самостоятельно думать?
Я не против книг. Как раз за них, но во многих случаях полезнее (особенно для начинающих) краткая инструкция и наставничество. Чтоб человек понимал основные алгоритмы и узкие места своей работы.
Может вы считаете, что патерны это тоже архитипы, и не стоит их изучать? Только практика из 1000 строк валидного кода запиханых в один класс или в одну функцию.
Я знаю и ведущих специалистов которые на практике за пять и более лет не научились декомпозировать методы и классы, и думаю для них данная инфа тоже была бы полезной.
Может у вас есть более полезные советы и своя стратегия изучения нового или книги достаточно?
Около пяти лет занимался программированием станков ЧПУ. И скажу что при ошибке в программе станка велика вероятность повредить оборудование, или нанести ущерб работающим людям.
Человек который считает, что достаточно прочесть книгу видимо никогда не делал ничего серьезного. Или является непризнаным гением.
А на собеседовании их обычно задают для проверки уровня кандидата, а не для самолюбия.
По моему опыту примерно 50% собеседуемых не могут ответить на элементарные вопросы, при этом хотят зп 100к +
Допустим, что нужно срочно сделать какую-то задачу на работе. Её дают вам, а вы говорите: «Извините не могу работать в условиях стресса. Только если я эту задачу раньше решал.» Так получается?
Состояние хранится в store (хранилище), отдельно от приложения, а компоненты подписываются на данные которые им нужны.
redux-devtools — это дополнительный инструмент более удобный чем console.log и debugger.
Перенося это с метафор на разработку. Если у вашего мини-приложения или стартапа большие амбиции и перспективы роста, то стоит взглянуть на Angular, т.к. он даст много плюсов в перспективе.
В противном случае есть более подходящие инструменты.
Но его релиз должен решить проблему с размерами бандла.