Как стать автором
Обновить
11
0
Климент @klimentRu

angular

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

this.myForm.get("myControl").disable();
Вот интересная статья про внедрение в компоненты и директивы Transclusion, Injection and Procrastination И к каким непредсказуемым последствиям это может привести.
В отличии от C# или Java, где по интерфейсу можно создавать моковые реализации классов для тестов в Angular внедрение зависимостей служит больше для управления сложностью.

С тестами ничего не изменилось.

Если нужно протестировать сервис у которого нет зависимостей или их мало, то можно создать экземпляр через new MyService()

Если нужно тестировать компонент или что-то другое во что внедряется сервис то все так-же создается тестовый модуль через TestBed и в секции providers: [] мокаются все зависимости.
Если делать отдельный модуль и в нем предоставлять сервис, то в файле этого модуля можно подключить и настроить какие то сторонние библиотеки, которые не хочется подключать в главный модуль.

В таком случае рекомендуется использовать для модуля providers: []
Если действительно понадобится ограничить область видимости сервиса, проще воспользоваться старым способом providers:[], так как он точно не приведет к циклическим зависимостям.


И ещё полезно знать, что есть viewProviders, которые позволяют ограничить область сервиса на шаблон и всех его наследников.

Об этом написано в разделах Внедрение в @Сomponent и @Directive и Внедрение сервиса в компонент (providedIn: SomeComponent)
Хотел подчеркнуть основные мысли. Приму к сведению.
В es2016 реализация декораторов через @ уже (Exploring EcmaScript Decorators).
Да и модули с введением import и export устарели.

Зачем одни и те-же устаревшие примеры из статьи в статью копировать?
А потом ими люди пользуются по незнанию(
То что мы каждый день делаем на работе это тоже задачи. И смысл в том, что надо понимать их суть в том числе со стороны бизнеса, и уметь разобраться и декомпозировать. А сайты с задачками как раз и помогают улучшать эти навыки.
Да, но паттерны можно только заучить. Это же список примеров, как вы их хотите изучать?

Можно поинтересоваться а основные парадигмы ООП тоже не нужны?

Вы предлагаете изучать таблицу умножение вместо того чтобы изучать само умножение

Вы предлагаете умножать не зная таблицу умножения?

Я учился программированию в те времена, когда паттерны за знания не считались

На перфокартах что-ли? Но и тогда были фундаментальные основы.
Люди, которые вместо этого заучивают паттерны

Заучивание и изучение это немного разные вещи. Естественно не стоит зубрить все наизусть. Но читать и пытаться понять всегда полезно. Даже для джунов.

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

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

Если вас во время такой практики не посещает мысль, что 1000 строк в одном месте это так себе идея, вам выше кодера не подняться

Из моей практики. Разговоры про «креативный подход и мышление вне шаблонов» начинают обычно как раз те кто пишет такой код, и считает его уже идеальным.

P.S. А вы вышли за рамки шаблонов или потеряли возможность самостоятельно думать?
Одно дело станок для хобби в гараже, другое промышленное оборудование со скоростью перемещения на ускоренном ходу до 30 м/мин. Пролетит перед глазами даже кнопку аварийного останова нажать не успеешь. Стоимостью одной фрезы 5 — 10 к рублей поломка которой уже является существенным косяком. И учитывая особенности обработки от аллюминия до титановых и жаропрочных сплавов. И точности обработки до пяти микрон. Технологического цикла в котором может быть задействовандо 5-10 человек и прочего.

Я не против книг. Как раз за них, но во многих случаях полезнее (особенно для начинающих) краткая инструкция и наставничество. Чтоб человек понимал основные алгоритмы и узкие места своей работы.
С таким подходом можно любую книгу. Например «Совершенный код» можно назвать сборником общих советов. Т.к. некоторые описаные там вещи довольно очевидны.

Может вы считаете, что патерны это тоже архитипы, и не стоит их изучать? Только практика из 1000 строк валидного кода запиханых в один класс или в одну функцию.

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

Может у вас есть более полезные советы и своя стратегия изучения нового или книги достаточно?
То есть если хочешь стать хирургом, то достаточно купить справочник и тесак? И можно прочесть и идти практиковаться?

Около пяти лет занимался программированием станков ЧПУ. И скажу что при ошибке в программе станка велика вероятность повредить оборудование, или нанести ущерб работающим людям.

Человек который считает, что достаточно прочесть книгу видимо никогда не делал ничего серьезного. Или является непризнаным гением.
Любое задание которое вы выполняете на работе это и есть задачи которые перед вами ставят. Только это задачи из реальной жизни. Суть статьи именно о них.

А на собеседовании их обычно задают для проверки уровня кандидата, а не для самолюбия.

По моему опыту примерно 50% собеседуемых не могут ответить на элементарные вопросы, при этом хотят зп 100к +
Про собеседования нигде не написано. Имеется в виду, что разработчик должен комплексно подходить к поставленной задаче, и думать головой, а не просто уметь нажимать на кнопки.

Дать ответ на задачу быстро в условиях стресса, может только человек, который эту задачу уже решал или знает ответ.

Допустим, что нужно срочно сделать какую-то задачу на работе. Её дают вам, а вы говорите: «Извините не могу работать в условиях стресса. Только если я эту задачу раньше решал.» Так получается?
Что имеете в виду?
Состояние хранится в store (хранилище), отдельно от приложения, а компоненты подписываются на данные которые им нужны.
Даже если фитча описана со всеми ньюансами и вы используете TDD со 100% покрытием тестами, редко обходится без отладки через chrome-devtools (если это не hello world, то практически никогда).

redux-devtools — это дополнительный инструмент более удобный чем console.log и debugger.
Можно резюмировать так. Архитектура и фреймворк — это фундамент вашего здания. Если планируется построить небоскреб, то и фундамент должен быть более качественным и глубоким, если это одноэтажный домик, то тогда можно обойтись и минимальными затратами.

Перенося это с метафор на разработку. Если у вашего мини-приложения или стартапа большие амбиции и перспективы роста, то стоит взглянуть на Angular, т.к. он даст много плюсов в перспективе.

В противном случае есть более подходящие инструменты.
Без. Ivy еще сыроват.
Но его релиз должен решить проблему с размерами бандла.

Информация

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