Климент klimentRu

Потому-что это модно?

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

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 еще сыроват.
Но его релиз должен решить проблему с размерами бандла.

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

Но безусловно в любом случае в Angular будет больше чем в SvelteJS ))

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

бОльшая часть этого кода это каркас сгенерированный angular-cli. А код написаный разработчиком это: верстка 3х компонентов и запрос на сервер, и подписка на изменение инпута.

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

Имел в виду, что Angular предоставляет готовые архитектурные решения, и если вы пришли с одного angular проекта на другой, то они скорей всего будут похожи. И там не будет очень плохого кода.

К примеру в моей практике был случай когда по наследству перешел проект на нативном JS в котором был один файл на 9000 строк и метод render более 500 и единственным возможным решением в этом аду было вставление очередного if/else. И все это выросло из «маленького проекта в котором не нужна архитектура».

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

Типизация в Angular благодаря TS, но сам Angular написан на TS поэтому большинство приложений тоже написаны на TS.

У Ангуляра «из коробки» есть модули:
— роутинга,
— http,
— работа с формами,
— подключен RxJs для удобства работы с ассинхронными операциями.

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

Все это от одной команды разработчиков.
Все это разворачивается одной коммандой.

ng new my-app

Повторюсь еще раз, что целью является не доказательство того, что Angular меньше, а то что у Angular есть другие достоинства и на нем можно быстро писать небольшие приложения которые ничем (кроме лишних 40кб gzip) не уступают React, Vue и др.

Без учета gzip.

C min+gzip. Ядро angular занимает примерно 60Кб.


Собранное приложение.

Безусловно Angular будет немного уступать некоторым другим библиотекам в размере бандла.

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

А лишние 100кб бандла в наше время не самая большая проблема. ИМХО

Классы с большой буквы писать принято.

class Rectangle {
  constructor(height, width) {} 
  getArea() {}
}
let square = new Rectangle(2, 2);

Вместо Object.assign в ES6 можно использовать spread оператор

let obj = { a : 1, b : 2};
let newObj = {...obj}

А в целом статья познавательная. Спасибо!

То что у Вас получилось из User сложно назвать моделью.
А для дополнения модели новыми полями лучше использовать мапер.
Например как на бэке мапятся entity(модель БД) и DTO, так же и на фронте можно сделать прослойку из маперов между приложением и слоем api сервисов.
Как вариант можно использовать библиотеку automapper-ts

Можно ссылку на проект с примером?

Из коробки. Пример приложен.

1. Это перевод
2. Инфа полезная поэтому решил выложить

Возможно у Вас не корректный ngIf
В статье есть пример warning не выдает.
Angular CLI: 1.6.7
Node: 8.4.0
OS: win32 x64
Angular: 5.2.8

Спасибо! Много полезной инфы.

Обоснуйте свою точку зрения, пожалуйста!
JS начинает превращаться в нормальный строго типизированный язык. Без внезапных преобразований строки в число, динамического добавления новых свойств и методов объекту и прочего.

На JS все что угодно можно с помощью 6 символов написать. www.jsfuck.com

Та же обертка в функцию с вынесением из компонента. Тоже хороший вариант.

Спасибо! Сейчас сказать затрудняюсь. Буду продвигать Angular в массы!

Разницы в работе нет. Только удобство чтения.

Template-driven вариант мне кажется более интуитивным и простым.

По моему получение формы через ViewChild менее удобный и точно менее понятный способ, чем описание в компоненте всй формы с валидациями. Особенно если форма большая.

Из официальной документации:

Neither is «better». They're two different architectural paradigms, with their own strengths and weaknesses. Choose the approach that works best for you. You may decide to use both in the same application.

Так что не стоит холиварить. В некоторых ситуациях использование template-driven forms может быть удобнее чем reactive forms.

Согласен, но в моей практике был кейс, когда надо было делать именно подсветку не валидных контролов.
Подумал, что это более интересный вариант.