11.02.2018 20:08
splincodewd 44 11500 Источник

Awesome Angular



От переводчиков


Всем привет, с вами Максим Иванов и Дмитрий Сергиенков, и сегодня мы поговорим о новостях в мире Angular. Мы подготовили для вас наиболее интересные материалы и отобрали список вопросов, который вам должен понравиться. Отметим только, что если вы будете ждать от этой статьи ответа на вопрос "Чем Angular лучше других технологий?", то придется вас огорчить, у нас не будет ответа на него. Почему? Как правило, все мнения вида "Технология X лучше технологии Y" почти всегда не более, чем отражение точки зрения высказывающегося. Однако для тех, кто только начинает изучать этот фреймворк, мы постараемся объяснить, что дает вам эта технология и какую пользу она приносит. Также не проходите мимо и ответьте на опрос, самые популярные ответы будут отправлены Игорю Минару (ведущий разработчик команды Angular). Ну что же, приступим.



Содержание:


  1. Angular
    1.1. Что дает вам Angular?
    1.2. Angular-RU — русскоговорящее сообщество
    1.3. Angular Russia Meetups
    1.4. Angular + StackBlitz
    1.5. Angular 6: coming soon


  2. Angular-дайджест
    2.1. Официальные ресурсы
    2.2. Новости в twitter
    2.3. Сообщества
    2.4. Серверный рендеринг
    2.5. Cheatsheet (чит-лист)
    2.6. UI библиотеки
    2.7. Важные особенности
    2.8. Angular CLI
    2.9. Dev Tools
    2.10. Starter Kit
    2.11. Webpack стартеры
    2.12. Angular Universal
    2.13. Публикации
    2.14. Видеоуроки
    2.15. Стайл-гайды
    2.16. Angular Connect конференция
    2.17. Книги
    2.18. Курсы и тренинги
    2.19. Подборка статей
    2.20. Интеграция
    2.21. Подборка компонентов
    2.22. Пайпы
    2.23. Стукрутуры данных
    2.24. Роутинг
    2.25. Валидация
    2.26. Логгирование
    2.27. i18n
    2.28. Производительность
    2.29. Ленивая загрузка
    2.30. Лоадеры
    2.31. Примеры приложений
    2.32. Генераторы
    2.33. Инструменты документации
    2.34. TodoMVC
    2.35. Расширения для IDE's
    2.36. TypeScript
    2.37. Dart
    2.38. Babel
    2.39. ES5
    2.40. Ionic
    2.41. Meteor
    2.42. NativeScript
    2.43. React Native
    2.44. Haxe
    2.45. C#
    2.46. Java
    2.47. Kotlin
    2.48. Scala
    2.49. Bit
    2.50. Security
    2.51. NgRx


Angular


Angular — это платформа для разработки мобильных и десктопных веб-приложений.

Current Angular version:

npm version


Current Browser support for Angular:

Sauce Test Status


Брэд Грин (Brad Green, Angular Platform Engineering Director at Google): "Под платформой я подразумеваю то, что мы создали структуру поддерживаемую набором огромного количества библиотек, инструментов и сервисов, которые создают полную и масштабируемую инфраструктуру для разработки".



Брэд работает в Google почти 12 лет, он проработал во многих местах, но гордится больше всего тем, что почти 5 лет он проработал вместе со Стивом Джобсом. Даже здесь, разговаривая про Angular, мы можем вспомнить старину Джобса и почтить его память.




1.1. Что дает вам Angular?


Angular позволяет вам из "коробки" создавать большие и сложные по части бизнес-логики приложения. Angular было полным переосмыслением AngularJS, наверное, это было самое болезненное, но оно того стоило, сам фреймворк стал куда чище и гибче, более enterprise-подобным и с этой точки зрения обладает высокой масштабируемостью.


Какие плюсы можно выделить:


  • Поддержка Google, Microsoft;
  • Инструменты разработчика (CLI);
  • Единая структура проекта;
  • TypeScript из "коробки" (вы можете писать строго типизированный код);
  • Реактивное программирование с RxJS;
  • Единственный фреймворк с Dependency Injection из "коробки";
  • Шаблоны, основанные на расширении HTML;
  • Кроссбраузерный Shadow DOM из коробки (либо его эмуляция);
  • Кроссбраузерная поддержка HTTP, WebSockets, Service Workers;
  • Не нужно ничего дополнительно настраивать. Больше никаких оберток;
  • Более современный фреймворк, чем AngularJS (на уровне React, Vue);
  • Большое комьюнити.

Чтобы оставаться честными, стоит выделить и минусы:


  • Выше порог вхождения из-за Observable (RxJS) и Dependency Injeciton;
  • Чтобы все работало хорошо и быстро нужно тратить время на дополнительные оптимизации (он не супер быстрый, по умолчанию, но быстрее AngularJS во много раз и с каждой новой версией становится все быстрее);
  • На самом деле, если вы планируете разрабатывать большое enterprise-приложение, то в этом случае у вас нет архитектуры для управления состоянием из "коробки" — нужно добавлять Mobx, Redux, CQRS/CQS или другой state-менеджер, чтобы потом не сломать себе мозг;
  • Angular-Univesal имеет много подводных камней;
  • Динамическое создание компонентов оказывается нетривиальной задачей.

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


  • Form Builder — для разработки поистине сложных форм, вам следует знать реактивные формы, точнее принципиально забыть про декларативные формы. Вот один из хороших примеров (реактивная форма + валидация);


  • Change Detection — так как Angular по умолчанию использует двустороннее связывание модели данных (Model-View-ViewModel), то при работе с большим объемом таких данных ваши приложения будут работать медленнее, поэтому в некоторых случаях стоит позаботиться о правильной стратегии обнаружения изменений. Вы можете посмотреть на различные OpenSource проекты: PrimeNG, Angular Material, Clarity UI, Angular Bootstrap и прочие, все они используют ChangeDetection.OnPush.


  • Templating — синтаксис шаблонов с точки зрения абстракции изменился не слишком сильно по сравнению с AngularJS, то есть мы так же можем написать условия, циклы, связать модель данных и прочее. Все, что вам следует хорошо понять и разобраться в Angular шаблонах — что такое структурные и декларативные директивы, а также что такое Input-параметры и Output-события.


  • Routing — наверное, это одно из основополагающих явлений в разработке веб-приложений. Тут просто важно понимать, что маршрутизация так же, как и компоненты, имеет свой жизненный цикл, понимая это, вы можете писать поистине крутые приложения. Еще стоит отметить: если на какой-либо из маршрутов вы вешаете модуль, а не компонент, который отвечает за отображение страницы по этому маршруту, то модуль будет подгружаться на странице по требованию.


  • Annotations — к слову, многие новички не знают, но стоит отметить. Декораторы, которые используются в изобилии при написании приложений на Angular, не являются какой-то жесткой магией TypeScript. Декораторы являются спецификацией EcmaScript и когда браузеры начнут поддерживать их, они будут нативно исполняться в browser runtime. На самом деле, декораторы весьма полезны и обеспечивают довольно высокой читаемостью ваш код. Один из примеров — это валидация моделей данных с использованием декораторов или десериализация/сериализация данных.


  • Observables — на самом деле, здесь стоит отметить только то, что в скором времени Observables будут спецификацией EcmaScript и все это будет нативно поддерживаться в браузерах. С точки зрения теории, если раскрыть понятие Observer (наблюдатель) — это поведенческий шаблон проектирования. Также известен как «подчинённые» (Dependents). Создает механизм у класса, который позволяет получать экземпляру объекта этого класса оповещения от других объектов об изменении их состояния, тем самым наблюдая за ними.


  • Shadow DOM — это средство для создания отдельного DOM-дерева внутри элемента, которое не видно снаружи без применения специальных методов, является спецификацией W3C. Грубо говоря, это удобный способ создания изолированных и переиспользуемых веб-компонентов. Чисто технически, если бы браузеры уже сегодня поддерживали многие концепции, которые использует Angular, нам не потребовались бы транспайлеры и прочие системы сборки, все, что мы писали на Angular, работало бы уже нативно.


1.2. Angular-RU — русскоговорящее сообщество




Развивающееся сообщество


Angular-RU Angular-RU Angular-RU


Совсем недавно наше комьюнити официально добавили на angular.io. Сейчас всеми силами мы пытаемся развивать его, и вы можете принять в этом участие. Вы можете вступить в наш чат в telegram (там же вы можете узнать информацию о различных стримах по Angular, которые мы проводим), либо же просто присылать нам свои pull-request(ы) или разработки и стать членом сообщества разработчиков Angular-RU.



Текущий список разработок сообщества


Список стартеров:



Список npm-пакетов:




1.3. Angular Russia Meetups


Angular-RU Angular-RU



Уже 2 года в Москве проходят митапы по Angular. В этом году планируется провести первый митап в Санкт-Петербурге (в скором времени появится информация, которую вы можете также отслеживать в чате AngularPiter). Если у вас есть идеи, или же вы хотите выступить с докладом, вы можете присылать свои заявки. Также, если в вашем городе уже проходят митапы, но нам об этом неизвестно, вы можете написать нам Issue по этому поводу, чтобы мы добавили вас.



1.4. Angular + StackBlitz


Самая замечательная новость, которую стоит отметить со стороны разработчиков команды Angular — это то, что они перенесли все работающие примеры в документации на современную онлайн IDE StackBlitz. То есть теперь ваши проекты, которые вы запускаете у себя локально, идентичны примерам из документации.


Если раньше они все были на SystemJS и работали в Plunker, то теперь вам достаточно зайти на официальный сайт StackBlitz и запустить одной кнопкой приложение на Angular или Ionic. Все это работает прямо в браузере, прямо там же вы можете устанавливать npm-пакеты и писать свой код на TypeScript.


Но это не все. Самое потрясающее в том, что теперь вы можете запустить любой GitHub-репозиторий с Angular-приложением прямо на StackBlitz.



Как это работает? Вам достаточно написать в адресной строке следующее:


stackblitz.com/github/{GH_USERNAME}/{REPO_NAME}

или так:


.../github/{GH_USERNAME}/{REPO_NAME}/tree/{TAG|BRANCH|COMMIT}

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



1.5. Angular 6


Сейчас мы с вами поговорим о том, что нас ждет в Angular 6. На самом деле, нас ждет много всего, и это прекрасно. Уже доступна Angular 6-бета, и сейчас на каких-нибудь своих приложениях вы можете потестировать новую версию (в рамках этого вы можете заводить новые issue на официальном трекере angular в случае, если у вас что-то не работает и вы знаете как это воспроизвести). Многие также задаются вопросом, а чем же заняты разработчики команды Angular, каков их Roadmap? Теперь вы можете отследить это, для нас появился специальный ресурс hq.angular.io, там отсортированы задачи команды по приоритетам.


Новый render-движок


Скорее всего, для обратной совместимости, нам придется включать флаг для того, чтобы наши приложения теперь работали на новом render-движке Ivy. Однако стоит отметить, что это фантастическая новость. Производительность приложения и скорость работы (на основе синтетических тестов) оказалась лучше, чем на последней версии Vue. А размер приложения сократился на 90%.






Помните тот троллинг про Angular 2 (когда многие начинали переходить с AngularJS на Angular 2), когда наши приложения весили 1Мб и когда Webpack 2 падал с непонятными ошибками? Эти времена практически завершились. Да, на самом деле, Angular 2 был сырым на тот момент, но из-за горящих сроков и дедлайнов, команда Angular выпустила фреймворк как есть. Но сейчас мы понимаем, что с каждой новой версией он становится все лучше и лучше. Конечно, наш фреймворк не развивается семимильными шагами, но вполне идет к своей цели и за это следует их уважать и ставить звездочки на гитхабе.


Новый компилятор — ABC


Google сейчас работает над новой системой сборки Bazel, сама система сборки также будет со встроенным компилятором для наших проектов. На самом деле, когда ваш проект сильно разрастается, (в том случае, когда он состоит из 1000 модулей, система сборки webpack начинает очень сильно замедляться, и это заметно: у webpack просто заканчивается оперативная память). Многие считают, что из-за этого команда Angular до сих пор не включила —aot режим для инкрементальной сборки. Конечно, если вы разрабатываете маленькие проекты, вам это не страшно, но, в принципе, вы всегда вправе использовать что угодно для сборки проектов (Rollup, Webpack, ..). Angular, разумеется, не привязывает к чему-либо. Однако ваша задача придерживаться и жить в гармонии с Angular CLI (и тогда вам не важно, что у него под капотом).


Сейчас известно, по заявлению команды Angular, что сборка проектов с Bazel занимает 2 секунды в инкрементальной сборке, и ваши приложения будут весить считанные килобайты за счет встроенных Rollup и Uglify2. Но пока известно (из последних коммитов), что мы ждем в следующей версии Webpack 4, а использование Bazel — это еще не точно и пока лишь планы.


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



Angular Elements



Angular Elements — это проект, суть которого — возможность компилирования Angular-компонентов в Custom Elements. Это одна из долгожданных особенностей, которая позволит вам писать переиспользуемые компоненты не только в экосистеме Angular, но и использовать их в проектах на React, Vue, Ember и тд. На самом деле, будущее за Web-components, в силу их нативного применения.Это позволит вам в принципе избавиться от экосистемы Angular (там, где это не требуется).


Пример вы можете посмотреть здесь. Был скомпилирован написанный на Angular компонент, который вместе с ядром Angular в сумме (без дополнительных манипуляций сжатия, минификации и прочего) дает на выходе всего 44кб. 


<html lang="en">
<head>
  <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>Ng Elements Test</title>
    <script type="module" src="/hello-world.js"></script>
</head>
<body>

  <hello-world name="World"></hello-world>

</body>
</html>



Уже есть куча примеров, где Angular-компоненты используются в React или Preact. Но самое главное, что это теперь возможно. Однако впереди еще много работы. Остается множество вопросов, которые следует решить. Дополнительно про Angular Elements вы можете прочитать тут.


Angular CLI update


$ ng update

Теперь вам не нужно будет больше беспокоиться об обновлениях своего приложения, так как начиная с Angular CLI 1.7+ будет добавлена возможность автоматического обновления зависимостей, ко всем прочему будет производиться автоматический рефакторинг устаревшего функционала.


То есть, если вы раньше писали: 


this.http.get(url).map(data => /* do something with data */);

То Angular CLI автоматически подменит устаревший код в такое (вероятнее всего опять же с включенным флагом): 


this.http.get(url).pipe(
        map(data => /* do something with data */)
);


Angular-дайджест



Официальные ресурсы




Новости в twitter


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

Angular Team (эксперты из команды Angular)


Google Developer Experts


Остальные известные эксперты:


Сообщества:


Митапы:


Этот список далеко не полный...



Сообщества







Серверный рендеринг





Cheatsheet (чит-лист)





UI библиотеки


Material Design





Важные особенности


Компоненты


Компонент управляет отображением представления на экране, в ее основе используется Shadow DOM по умолчанию (для создания инкапсулированного визуального поведения). Как правило, компоненты используются для создания простого виджета в пользовательском интерфейсе, в то же время они могут представлять из себя набор еще более простых компонентов внутри себя (для увеличения абстракции и создания простых функциональных виджетов внутри приложения).


@Component({
  selector: 'html-name-element'
})
export class MyComponent {
  // ...
}

Шаблоны


Шаблон — это ваша html-разметка, в которой вы можете описывать ваши взаимодействия с DOM на основе модели данных и событий вашего класса компонента (в примере, контроллер MyComponent).


@Component({
 templateUrl: './my.component.html'
})
export class MyComponent {

  public title: string = "Hello world";

  // ..

}

<!-- my.component.html -->
<p>
  Интерполяция: {{ title }},  
  или так:      {{ this.title }}
</p>

Обнаружение изменений


Каждый компонент имеет свой собственный детектор изменений, который гарантирует проверку привязок данных, определенных шаблоне.


Внедрение зависимостей


Внедрение зависимостей (англ. Dependency Injection) — это композиция структурных шаблонов проектирования, при которой за каждую функцию приложения отвечает один, условно независимый объект (сервис), который может иметь необходимость использовать другие объекты (зависимости), известные ему интерфейсами. Зависимости передаются (внедряются) сервису в момент его создания.


// logger.service.ts
@Injectable()
export class LoggerService {
  // ..

  public get trace() {
    return console.debug.bind(console);
  }

}

// my-component.component.ts
@Component({ /* .. */ })
export class MyComponent {

  constructor(private logger: LoggerService) {
    logger.trace('Init MyComponent');
  }

}

Директивы


Директивы позволяют получать прямой доступ к DOM ваших элементов. Они бывают двух видов: структурные и атрибутные.


Атрибутная директива:


@Directive({
  selector: '[bold]'
})
export class BoldDirective {

    constructor(private elementRef: ElementRef){
        this.elementRef.nativeElement.style.fontWeight = "bold";
    }
}

Здесь внедряется сервис "ElementRef". Он представляет ссылку на элемент, к которому будет применяться директива:


<!-- my-component.component.html -->
<p bold>Hello world</p>

Структурные директивы:


Структурные директивы изменяют структуру DOM с помощью добавления или удаления html-элементов. Существует минимум три встроенных структурных директивы: ngIf, ngSwitch и ngFor.


@Component({ /* ... */ })
export class AppComponent {
    // ..

    public items = ["Apple iPhone", "Huawei Mate", "Samsung Galaxy"];
}

<!-- my-component.component.html -->
<ul>
  <li *ngFor="let item of items">{{item}}</li>
</ul>

Пайпы


Пайп (pipe) представляет собой особый обработчик, который позволяет форматировать отображаемые значения


// my-component.component.ts
@Component({ /* .. */ })
export class MyComponent {
  public fields = [ { id: 1 }, { id: 2 } ];
}

<!-- my-component.component.html -->
Читаемый вывод объекта: 
<pre> {{ fields | json }} </pre>

Помимо стандартных, вы можете писать собственные


@Pipe({ name: 'factorial' })
export class FactorialPipe implements PipeTransform {
  transform(value: number, args?: any): number {
    if (value <= 0) return 0;

    let result = 1;
    for (let i = 1; i <= value; i++) {
        result = result * i;
    }

    return result;
  }
}

// my-component.component.ts
@Component({ /* .. */ })
export class MyComponent {
  public x = 5;
}

<!-- my-component.component.html -->
Факториал числа {{ x }} равен {{ x | factorial }}
<!-- Факториал числа 5 равен 120 -->

Web Workers


Поддержка Web Worker в Angular предназначена для упрощенного распараллеливания в вашем приложении. Когда ваше приложение запускается, Angular проводит всю основную работу по обработке вашей логики в отдельных потоках, ядро выполняет вычисление в своем рабочем потоке, в то время как другие функции могут и вовсе выполняться не в потоках.


HTTP


Самый распространенный способ получить данные от web-служб — это через HttpClient сервис доступный для внедрения зависимостей в ваших компонентах. Angular HttpClient довольно прост. Все, что нам нужно сделать, это вызвать метода get и передать ему url. Данный метод get возвращает объект Observable. Этот класс является частью библиотеки rxjs, которая используется во многих местах Angular'а.


// rest.service.ts
@Injectable()
export class RestService {

  constructor(private httpClient: HttpClient) {}

  public getByObservable(url: string): Observable<any> {
      return this.httpClient.get(url);
  }

  public getByPromise(url: string): Promise<any> {
      return this.httpClient.get(url).toPromise();
  }

}

Подобно обещанию (Promise), наблюдатель (Observable) не содержит в себе сразу значения. Вместо этого у него есть метод подписки(subscribe), где мы можем зарегистрировать обратный вызов(callback). Этот callback вызывается, как только результат будет доступен. Помимо обещания, Observable может вернуть более одного значения. Вы можете вернуть себе поток результатов. Но это не имеет значения в данном случае. В нашем случае Observable возвращает только одно значение.


// my-component.component.ts
@Component({ /* .. */ })
export class MyComponent {

  constructor(private rest: RestService) {}

  // Observable classic examples
  public getFields() {
    this.rest.getByObservable('http://anyurl.com').subscibe(value =>{
      // value - результат
    },
    error => {
      // error - объект ошибки
    });
  }

  // Promise classic examples
  public async getAsyncField() {
    try {
      // value - результат
      const value = await this.rest.getByPromise('http://anyurl.com');
    } catch (error) {
      // error - объект ошибки
    }
  }

}

Роутинг



Тестирование



Ahead-of-Time компиляция





Angular CLI


Angular CLI — инструмент для быстрой разработки приложений на Angular




Dev Tools


  • @compodoc/ngd-cli — Просмотр зависимостей в Angular
  • angular-playground — Scenario Driven Development
  • @ngrx/store-devtools — Инструменты разработчика для @ngrx/store.
  • angular-prettyjson — Улучшенный вывод объектов в шаблоне для отладки (директива json)
  • Augury — Chrome расширение разработчика для отладки
  • angular-webpack-config — Заготовленная Webpack конфигурация для быстрого старта



Starter Kit





Webpack стартеры





Angular Universal


Universal (изоморфный) — рендеринг приложений Angular на серверной стороне

Universal (основные ресурсы)



Основные источники


  • universal-starter — Angular Universal стартер от @Angular-Class
  • ng-seed/universal — Angular Universal стартер с Webpack, dev/prod modes, DLLs, AoT compilation, HMR, SCSS compilation, lazy loading, config, cache, i18n, SEO, TSLint/codelyzer



Публикации





Видеоуроки





Стайл-гайды





Angular Connect конференция





Книги





Онлайн тренинги





Подборка статей





Интеграции





Подборка компонентов





Пайпы (pipes)


  • fuel-ui — OrderBy и Range, портированные из AngularJS 1.x в Angular
  • ngx-filter-pipe Пайп (pipe) для фильтрации массивов
  • ngx-pipes набор полезных пайпов для Angular
  • ngx-order-pipe OrderBy — сортировка коллекций
  • angular2-camelcase Пайп для преобразования строк в camelCase
  • angular-pipes — Используем крутые пайпы
  • ngx-pipes — Пайпы без единой зависимости
  • ng-pipes — Набор полезных пайпов
  • angular-linky — Linky пайп



Стукрутуры данных


  • angular-localstorage — Декоратор для автоматического сохранения и восстановления полей классов из LocalStorage
  • ng-webstorage — LocalStorage и SessionStorage менеджер
  • ng-storage localStorage и sessionStorage обертки
  • angular-safeguard — Обертка над cookies/sessionStorage/localStorage
  • @ngx-cache/core — Умное кеширование в Angular
  • angular-cookie Библиотека имплеминтирующая из AngularJS 1.x $cookies-сервис в Angular
  • ng-http-cache — Кеширование http-запросов



Роутинг


  • ng-breadcrumb — генератор иерархии маршрутизации на основе вложенного роутинга
  • ng-page-transition — Простой компонент с анимированными переходами при имезении маршрутизации
  • @ngx-i18n-router/core — Инструмент интернационализации роутинга



Валидация





Логгирование





i18n


  • @ngx-translate/core — Удобная библиотека для работы с файлами локализаций (i18n)
  • @angular-ru/ngx-i18n-combine — Объединение файлов i18n из компонентов и общих файлы для ваших локализаций (json, ts, js, jsx, tsx)
  • angular-l10n — Библиот для перевода сообщений, дат и цифр
  • @ngx-universal/translate-loader — Лоадер, который обеспечивает переводы на стороне браузер или сервера



Производительность


  • angular-performance-checklist — чеклист советов по улучшению производительности приложений на Angular
  • @angularclass/idle-preload — Idle Preload для предварительной загрузки асинхронных маршрутов



Ленивая загрузка


  • ng-lazyload-image — Ленивая подргузка изображений на Agular
  • ng-image-lazy-load — Лоадер для ленивой загрузки изображений



Лоадеры


  • gulp-inline-ng-template — Gulp-плагин для встраивания HTML и CSS в @Component-декоратор.
  • angular-template-loader — Объединяет все html и css в единое целое при компиляции компонентов
  • angular-router-loader — Webpack лоадер, который позволяет загружать модули на основе строки с помощью маршрутизатора



Примеры приложений




Генераторы





Инструменты документации


  • Storybook: "Cреда разработки, которую вы полюбите"
  • Compodoc: Отличный инструмент для создания документации вашего приложения
  • AngularDoc: Веб-сайт, отображающий "Архитектуру и визуализацию Angular-приложения"
  • NgModule-Viz: Визуализация связей между NgModules и зависимостями в Angular



TodoMVC





Расширения для IDE's





TypeScript


TypeScript позволяет вам писать код на JavaScript так, как вы этого хотите.

TypeScript является типизированным надмножеством JavaScript, который компилируется в JavaScript.


TypeScript (основные ресурсы)



Основные источники





Dart


Dart — язык программирования, созданный Google. Dart позиционируется в качестве замены/альтернативы JavaScript. Dart — это масштабируемый язык программирования с открытым исходным кодом, с качественными библиотеками и рантаймом, для создания веб-приложений, серверов и мобильных приложений.

Основные источники





Babel


Babel – предназначен для транспиляции современного JS кода в код работающий на предыдущем стандарте, к примеру ES5.

Babel (основные ресурсы)



Angular Online Playground



Основные источники



Babel плагины





ES5


ECMAScript включает в себя структурированные, динамические, функциональные и прототипные фичи

Основные источники


angular-es5-starter-kit Пример Angular приложения на ES5




Ionic


Ionic — это прекрасный SDK с открытым исходным кодом для разработки гибридных мобильных приложений.


Ionic (основные ресурсы)





Meteor


Meteor — веб-платформа на языке JavaScript, предназначенная для разработки Web-приложений реального времени.

Meteor (основные ресурсы)



Основные источники





NativeScript


Создайвайте действительно нативные iOS, Android приложения на JS (TS) + CSS. NativeScript — кроссплатформенный фреймворк с открытым исходным кодом.

NativeScript (основные ресурсы)



Основные источники





React Native


React Native — это фреймворк для создания нативно отображаемых iOS- и Android-приложений.


React Native (основные ресурсы)





Haxe


Haxe — это высокоуровневый мультиплатформенный язык программирования с открытым исходным кодом, а также компилятор, с помощью которого можно создавать приложения и генерировать исходный код для разных платформ, сохраняя единую кодовую базу. Haxe включает в себя функциональность, поддерживаемую на всех платформах, например: числовые типы данных, строки, массивы, а также поддержку некоторых файловых форматов (xml, zip). Haxe также включает в себя поддержку платформо-специфических API для Adobe Flash, C++, PHP и других языков. Код, написанный на языке Haxe, может быть транслирован в код ActionScript 3, JavaScript, Java, C#, C++, Python, Lua, PHP, Apache CGI, а также в приложение Node.js

Основные источники





Scala


Scala — мультипарадигмальный язык программирования, спроектированный кратким и типобезопасным для простого и быстрого создания компонентного программного обеспечения, сочетающий возможности функционального и объектно-ориентированного программирования. Язык программирования Scala является «симбиозом» Java и C#.


Основные источники


  • play-angular — серверный рендеринг Angular на Scala



C#


C# — объектно-ориентированный язык программирования. Является языком разработки приложений для платформы Microsoft .NET Framework.




Java


Java — сильно типизированный объектно-ориентированный язык программирования, разработанный компанией Sun Microsystems (в последующем приобретённой компанией Oracle). Приложения Java обычно транслируются в специальный байт-код, поэтому они могут работать на любой компьютерной архитектуре, с помощью виртуальной Java-машины


Основные источники





Kotlin


Kotlin — статически типизированный язык программирования, работающий поверх JVM и разрабатываемый компанией JetBrains. Компилируется также в JavaScript и на другие платформы через инфраструктуру LLVM.




Bit


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




NgRx





Security



В заключение:



Во многом Angular — это не только технология, фреймворк или платформа, это люди, в конце концов. То огромное сообщество разработчиков, которые пишут на этой технологии каждый день. Стараются сделать ее лучше и рассказать другим. Поэтому, чтобы сделать фреймворк лучше, вы можете писать свои замечания и предложения на официальном Issues-трекере, присылать свои pull-request(ы). А еще вы можете присоединиться к отечественному сообществу разработчиков в Telegram. Вместе мы можем общаться на темы лучших практик в Angular, делиться опытом и знаниями. Мы открыты к тому, чтобы вы могли выступать на конференциях и митапах, вы можете присылать свои заявки, лучшие из них отбирает сам Алексей Охрименко, который старается также поддерживать наше сообщество и стремиться к его развитию. Поэтому любите Angular, пишите на Angular, развивайтесь с Angular. С вами были Максим Иванов и Дмитрий Сергиенков, пока.

Комментарии (44)


  1. klimentRu
    11.02.2018 23:27
    #10663508
    +2

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


  1. DSolodukhin
    11.02.2018 23:33
    #10663516
    +2

    Добавил в закладки, спасибо за подборку.
    К голосованию я бы еще добавил бы пункт про оптимизацию, из коробки Angular показывает довольно невысокую оптимизацию. Не сказать, что это сложно исправить, но новичка это может обескураживать.


    1. serf
      12.02.2018 10:17
      #10663966

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

      Даже если CLI использовать?
      Но понимать хотя бы onPush в связке с иммутабельным стором желетельно, что не идет из коробки вместе с CLI.
      PS лично я не большой сторонник использования CLI, но в реальности выбор зависит от проекта и команды.


  1. zaikin-andrew
    12.02.2018 09:47
    #10663904

    splincodewd Нужен фикс твиттера Минара twitter.com/igorminar :)


  1. padonnak
    12.02.2018 09:47
    #10663906

    в закладку сразу :) такое нельзя пропустить.


  1. vintage
    12.02.2018 11:13
    #10664058

    но гордится больше всего тем, что почти 5 лет он проработал вместе со Стивом Джобсом. Даже здесь, разговаривая про Angular, мы можем вспомнить старину Джобса и

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


    фреймворк стал куда чище и гибче, более enterprise-подобным и с этой точки зрения обладает высокой масштабируемостью

    К сожалению, энтерпрайз тяготеет больше к дубовым переусложнённым вещам. В это среде очень популярно мнение, что если вещь сложная, то много чего умеет. А если простая, то там много чего не хватает. Мой опыт работы с этим чудом инженерной мысли говорит, что он очень не гибкий. Шаг в сторону от того, что написано в документации и ты напарывашься на "это невозможно" и "если тебе так не нравится как сделано в Ангуляре, то никто не заставляет его использовать". Ну, банальный пример: как сделать так, чтобы при переходе с /tasts/ на tasks/1/ роутер не перерендеривал весь список задач, а просто открывал рядом панельку с детализацией? Базовое поведение безбожно сломано кривыми абстракциями.


    Поддержка Google, Microsoft;

    Одних только не закрытых багов более 800: https://github.com/angular/angular/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen++bug
    Ещё 1000 других проблем: https://github.com/angular/angular/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+


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


    Первый же попавшийся пример: https://github.com/angular/angular/issues/13590 — человек включил AOT компиляцию (а без неё размер бандла становится огромным) и всё упало. Компилятор зачем-то требует, чтобы каждый компонент был импортирован хотя бы в один модуль.


    У меня было ещё веселее — приложение работает, а тесты все падают (в рантайме, конечно же), что не могут зарезолвить зависимости. Пляски с бубном и перелопачивание СтекаПереполнения подсказало воркэраунд — добавлять @Inject() для всех зависимостей. Вот тебе и устаревшая конструкция. При этом самостоятельно разобраться в том, почему такое происходит, не представляется возможным.


    Миллион человек в комьюнити, это звучит, конечно, круто. Но это всё по большей части потребители. Многие ли из них хоть сколь-нибудь разбираются в архитектуре фреймворка и способны понять почему что-то работает не так, как ожидается? А многие ли из таких людей имеют время и желание вам помогать? А вам ведь зарелизить приложение надо было ещё вчера.


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


    Инструменты разработчика (CLI);

    Опять же, из-за переусложнённой архитектуры, требующей кучу приседаний, вам просто жизненно необходимы кодогенераторы. Ибо на каждый компонент нужно создать от 4 файлов и провязать их друг с другом и приложением. При этом стандартный кодогенератор генерит лишь что-то своё и не даёт толком подстроить бойлерплейт под проект. Например, нам для каждого общего компонента нужно создавать ещё и демонстрационную страничку, а также ангуляровский модуль. Ангуляровские модули — это вообще чудесная нашлёпка поверх нативных, из-за чего tree shaking перестаёт работать. Всё, что вы включили в модуль безусловно попадёт в бандл. Поэтому мы к каждому компоненту прикладываем отдельный модуль, чтобы можно было подключить только его, безо всех остальных компонент.


    А как этот CLI делает рекомпиляцию — это просто чудо. Например, он может просто забыть перекомпилировать код — и сиди думай, чего это то, что ты написал работает неправильно. Бывает сборка падает, но ты об этом не узнаешь пока не заглянешь в консоль — в браузере будет показываться просто устаревший код. Особенно при рефакторинге эта фича очень доставляет. Да, вы можете порекомендовать какой-то иной "стартер кит", где таких проблем нет. Но суть не в том, что нельзя никак выкрутиться (выкрутиться можно всегда, ну или привыкнуть и перестать замечать), а в том, что базовое поведение стандартных инструментов безбожно сломано.


    TypeScript из "коробки" (вы можете писать строго типизированный код);

    Ангуляр — один из немногих фреймворков, написанных на TS. Это действительно классно, когда IDE понимает, что как взаимосвязано в коде. Но и тут Ангуляровцы накосячили — шаблоны совсем не типизированы. Вы можете написать любую чушь в них и они мало того, что скомпилируются, но даже в рантайме не выдадут ошибок — у вас просто что-то не отрендерится. Да, в новой версии обещают переписать компилятор шаблонов. Но это лишний раз подчёркивает, что изначально эта базовая функциональность была сделана спустя рукава. И лишь спустя несколько лет латания дыр, они таки созрели что-то с этим сделать. И то, когда это ещё будет, а приложение выпускать надо уже вчера. Удивительный фреймворк будет этот Ангуляр версии к 10, ага.


    Реактивное программирование с RxJS;

    Это самая бестолковая форма реактивного программирования, превращающая код в головоломку вида "как бы так извертнуться, чтобы состояние всего мира не перевычислялось на каждый чих". Поэтому Rx в компонентах стараются не использовать, ибо она малость не совместима с простой и понятной схемой "поменяли что-то в объекте — компонент отложенно перерендерился". Хоть бы на MobX сделали, который сам автоматически конфигурирует потоки данных.


    Единственный фреймворк с Dependency Injection из "коробки";

    Не единственный. Но единственный с такой трендовой кривой реализацией. Компоненты нигде не инстанцируются напрямую через new (даже в тестах), поэтому инъекция через конструктор не даёт никаких профитов. А вот неудобств полно — каждый раз наследуясь от класса необходимо скопипастить объявления всех его зависимостей и прокинуть их ему. Резолвятся эти зависимости сразу при создании объекта, даже если никогда не будут им использованы. При этом dependency tree в лучших традициях запрятано куда-то в жопу и настолько переусложнено, что через отладчик хрен разберёшься, где что одно проиинъектиться и почему он не может что-то правильно заинъектить.


    Продоолженние следует...


    1. serf
      12.02.2018 11:21
      #10664090
      +1

      Опять же, из-за переусложнённой архитектуры, требующей кучу приседаний, вам просто жизненно необходимы кодогенераторы. Ибо на каждый компонент нужно создать от 4 файлов и провязать их друг с другом и приложением.

      Кодогенерация совсем не обязательна, моем мнение что это зло, возможно допустимое для начинающих. CLI тоже зло как по мне, возможно допустимое для начинающих.

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

      Это вы когда последний раз ангуляр пробовали?


      1. DSolodukhin
        12.02.2018 11:43
        #10664142

        Справедливости ради, шаблоны и правда не очень-то хорошо работают с типами, хотя явную чушь оно скорее всего даже не соберет. В принципе, эту проблему можно частично решить плагинами для IDE и/или редактора, но это уже костыль.
        Еще раздражает разный набор проверок при сборке в dev и prod режимах с angular/cli. Например:


        //example.component.ts
data: any;

//example.component.html
{{data.field}}

        В dev режиме этот кусок кода прекрасно компилируется и работает, в prod — падает при компиляции.


        1. serf
          12.02.2018 11:49
          #10664158

          Что значит dev и prod, имеется ввиду CLI на настройка по умолчанию? Там в prod AOT включен и fullTemplateTypeCheck поставлен в true если не ошибаюсь, а в dev по уполчанияю это выключено, но скоро планирубт включить. Но вообще можно ведь настроить как угодно сборку, не полагаясь на CLI (который кривоватый в целом). Включите себе AOT и fullTemplateTypeCheck в dev режиме и будет более строгая валидация.


        1. serf
          12.02.2018 12:30
          #10664230

          Кстати с какой ошибкой падает? По логике при типе any ошибки быть не должно. Есть у меня догадка что у вас падает линтинг, тк в в CLI вроде codelyzer рулы настроны на {{ data.field }} формат выражения, а не {{data.field}} (то есть с пробелами нужно). PS лучше any использовать поминимуму и включить stric:true опцию компиляции TS.


    1. Starche
      12.02.2018 12:59
      #10664324

      Ну, банальный пример: как сделать так, чтобы при переходе с /tasts/ на tasks/1/ роутер не перерендеривал весь список задач, а просто открывал рядом панельку с детализацией? Базовое поведение безбожно сломано кривыми абстракциями.
      Я конечно не видел ваш конфиг, но в большинстве знакомых мне способов реализации — ничего перерендериваться не будет. Самый обычный способ через — loadChildren.


    1. Druu
      13.02.2018 04:01
      #10665774

      > Ну, банальный пример: как сделать так, чтобы при переходе с /tasts/ на tasks/1/ роутер не перерендеривал весь список задач, а просто открывал рядом панельку с детализацией?

      Вложенный router-outlet или опциональный параметр. В чем тут вообще проблема? Задача решается стандартными средствами.

      > Первый же попавшийся пример: github.com/angular/angular/issues/13590 — человек включил AOT компиляцию (а без неё размер бандла становится огромным) и всё упало. Компилятор зачем-то требует, чтобы каждый компонент был импортирован хотя бы в один модуль.

      Зачем вы полезную фичу объявляете багом?

      > У меня было ещё веселее — приложение работает, а тесты все падают (в рантайме, конечно же), что не могут зарезолвить зависимости. Пляски с бубном и перелопачивание СтекаПереполнения подсказало воркэраунд — добавлять Inject() для всех зависимостей. Вот тебе и устаревшая конструкция. При этом самостоятельно разобраться в том, почему такое происходит, не представляется возможным.

      Зачем вы плясали с бубном и пытались самостоятельно разбираться в том, что прямым текстом описано в любом туториале по тестированию ангуляра и ангуляровскому DI?

      > Ибо на каждый компонент нужно создать от 4 файлов и провязать их друг с другом и приложением.

      Зачем вам эти 4 файла?

      > Ангуляровские модули — это вообще чудесная нашлёпка поверх нативных, из-за чего tree shaking перестаёт работать.

      Ангуляровский модуль — это замкнутый набор компонентов/сервисов, которые не могут работать друг без друга. Что вы собрались тут тришейкать?

      > Но и тут Ангуляровцы накосячили — шаблоны совсем не типизированы.

      Поздравляю с выходом из криокамеры! Уже давно все типизировано, с поддержкой иде, подсветкой ошибок, автокомплитом.

      > Это самая бестолковая форма реактивного программирования, превращающая код в головоломку вида «как бы так извертнуться, чтобы состояние всего мира не перевычислялось на каждый чих».

      Не надо изворачиваться, просто share().

      > Поэтому Rx в компонентах стараются не использовать, ибо она малость не совместима с простой и понятной схемой «поменяли что-то в объекте — компонент отложенно перерендерился».

      Как она может быть несовместима, если _именно так_ и работает?

      Какие-то у вас странные претензии, если честно, из разряда «я мутабельно меню состояние в редьюсере и все ломается, что такое??? приходится лепить воркэраунды и костыли, говно ваш редакс!»


    1. vintage
      13.02.2018 10:05
      #10666026

      Итак, продолжим..


      Шаблоны, основанные на расширении HTML

      Даже если забыть про то, что html совршенно не годится для композиции компонент, реализация в Ангуляре самая ужасная. Вы можете прицепить структурную директиву к элементу через звёздочку… но к одному элементу не более одной. Вы можете забиндить выражение через двойные фигурные скобочки, а можете через квадратные вокруг имени атрибута. Мы очень последовательные ребята. Синтаксис настольо интуитивно понятен, что чтобы не путать квадратные и круглые скобочки даже придумали метафору "бананы в ящике", словно намекая на то, кто будет работать с этим фреймворком. Ну и конечно же куда без примитивной пародии на JS в атрибутах *ngFor и иже с ним. А как чудесен костыль с объявлением кастомных локальных переменных внутри цикла через *ngIf, чтобы не писать (task$|async).title и тому подобные штуки, которые безбожно тормозят в большом количестве.


      Кроссбраузерный Shadow DOM из коробки (либо его эмуляция)

      shadow dom и так то мертворождённая технология, ибо никому фактически не нужна, а проблем доставляет массу. Так ещё и эта изумительная эмуляция. Компонент практически не контролирует элемент в который рендерится. Вы даже не сможете банально директиву применить к этому элементу из компонента. В результате, если вашему компоненту нужна функциональность директивы, то извольте указывать её при каждом вызове компонента. И конечно же компонент не может указать каким хтмл-тэгом его рендерить. В результате, вы либо повторяете для каждой ссылки routerLinkActive="active" и [routerLinkActiveOptions]="{ __change_detection_hack__: [ id, mode ] }", либо каждая ссылка превращается в два элемента — элемент компонента и ссылка с нахлабучками.


      __change_detection_hack__ — это моё вчерашнее открытие. Без этого костыля роутер не всегда добавляет класс текущим ссылкам. Люди целые статьи пишут как починить базовое поведение стандартного роутера: https://www.bennadel.com/blog/3375-forcing-routerlinkactive-to-update-using-an-inputs-hack-in-angular-5-0-2.htm
      Сделать роутер настолько ущербным и настолько кривым — это нужно было постараться.


      Более современный фреймворк, чем AngularJS (на уровне React, Vue);

      Вот это великое достижение, да. На любое событие обновлять состояние вообще всех компонент на странице — это деградация даже по сравнению с AngularJS. Спасибо, что хоть вообще дали возможность выключить этот dirty cheking. Но, конечно, вынести это в общую настройку или хотя бы выключить по умолчанию — не наш метод. Пусть разработчики в каждом компоненте пишут: changeDetection: ChangeDetection.OnPush, если не хотят, чтобы их приложение лагало при скроллинге.


      Помните тот троллинг про Angular 2 (когда многие начинали переходить с AngularJS на Angular 2), когда наши приложения весили 1Мб и когда Webpack 2 падал с непонятными ошибками?

      С тех пор ничего не поменялось. Приложение всё так же весит как слон, запускается как черепаха (да-да, с AOT), а вебпак периодически забывает вообще показать ошибку. Но давайте назовём критику троллингом и всё будет хорошо.


      Был скомпилирован написанный на Angular компонент, который вместе с ядром Angular в сумме (без дополнительных манипуляций сжатия, минификации и прочего) дает на выходе всего 44кб.

      Открываем консоль:


      hello-world.js — без минификации, да — 4.5kb
      elements.js — минифицирован — 15.6kb
      core.js — минифицирован — 125kb
      rx-lite — минифицирован — 17.7kb


      44.7кб получается лишь после gzip-ования.


      И это только для того, чтобы нарисовать 3 строчки текста в рамочке.


      Сейчас мы с вами поговорим о том, что нас ждет в Angular 6.

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


      Уф, выдохнул, спасибо, что выслушали.


      1. Druu
        13.02.2018 10:20
        #10666054
        +1

        > Даже если забыть про то, что html совршенно не годится для композиции компонент

        С каких это пор?

        > реализация в Ангуляре самая ужасная.

        Ужасна чем именно? Можете привести пример «неужасной» реализации?

        > shadow dom и так то мертворождённая технология, ибо никому фактически не нужна, а проблем доставляет массу.

        Почему не нужна? Разве придумали уже какой-то другой человеческий способ изоляции стилей?

        > Вот это великое достижение, да.

        Опять же, в сравнению с чем? Реакт, вон, на каждое обновление вообще заново всю страницу перестраивает.

        > А ждёт нас очередная поломка многих сторонних компонент.

        Не используйте плохо написанные, не поддерживающиеся компоненты.


        1. mclander
          13.02.2018 15:06
          #10666808
          +1

          > Не используйте плохо написанные, не поддерживающиеся компоненты.

          Преображенский:… И — боже вас сохрани — не читайте до обеда советских газет.
          Борменталь: Гм… Да ведь других нет.
          Преображенский: Вот никаких и не читайте


          1. Druu
            13.02.2018 15:23
            #10666844

            То, что кто-то пишет плохие, негодные компоненты — это проблема сообщества. Вы для любого фреймворка всякое говно при желании найдете. Да вобщем-то и для любого языка и для любой области, просто в случае жс/веба эта проблема стоит наиболее остро.


            1. nsinreal
              13.02.2018 15:38
              #10666892

              Эмм… Только вот релизный цикл у ангуляра весьма короткий. Это убивает компоненты уже оттестированные и уже работающие. И есть большая разница между обновлять компонент раз в два года и обновлять раз в полгода. Не каждому нравится онанировать по столько частому графику.


            1. nsinreal
              13.02.2018 15:44
              #10666902

              То, что кто-то пишет плохие, негодные компоненты — это проблема сообщества. Вы для любого фреймворка всякое говно при желании найдете. Да вобщем-то и для любого языка и для любой области, просто в случае жс/веба эта проблема стоит наиболее остро.

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

              Мне кажется, что весомая часть разумного выбора фреймворка опирается на то, что у него есть сообщество, что фреймворк будет поддерживаться. Если вы говорите, что сообщество Ангуляр говно, то это минус Ангуляру. А не какой-то сторонний факт, не относящийся к делу.


              1. Druu
                13.02.2018 16:39
                #10667018

                > Если вы говорите, что сообщество Ангуляр говно

                Я говорил не про сообщество ангуляра, а про сообщество js. Для любого сколько-нибудь популярного спа-фреймворка значительная часть библиотек — говно. Не важно, ангуляр это (первый или второй), реакт, вуе или еще что.


        1. vintage
          14.02.2018 11:00
          #10668184

          serf


          Кодогенерация совсем не обязательна

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


          Включите себе AOT и fullTemplateTypeCheck в dev режиме и будет более строгая валидация.

          Очень странная логика. Разработчик пилит — у него ничего не падает. Запушил — получай стекстрейсами по фейсу. Правильно, не надо разработчику знать об ошибках. Даже варнинги слать не надо. Устроим ему приятный сюрприз. А когда он возмутится — будем его унижать, мол он бузит, не разобравшись в теме: надо же было догадаться пойти поискать флаг компилятора, влючающий проверку типов в шаблонах.


          Starche


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

          Два разных роута — два разных компонента. Ререндера не будет лишь при вложеном роутинге, но тогда со внешнего роута не получить доступа к параметрам вложенного. А они нужны. Но я выкрутился через один роут с queryParams и условным рендерингом компонента.


          Druu


          Вложенный router-outlet

          О, это чудеснейшая вещь, которая зашивает в урлах структуру отображения, из-за чего урлы у вас буду выглядеть не /tasks/1/, а /(left:tasks;right:tasks/1). Классный дизайн, ничего не скажешь. Любой более-менее серьёзный рефакторинг и у пользователя сломаются все закладки. А ведь всего-то надо было предоставить реактивный стор с параметрами урла и простую возможность формировать списки компонент для рендеринга, учитывая состояние этого и других сторов. И всё, больше ничего не надо было бы для реализации любой схемы навигации.


          Зачем вы полезную фичу объявляете багом?

          1. Она бесполезна. От слова "совсем".
          2. Поведение с АОТ и без него не консистентно.
          3. Багом её считаю не я, а автор баг-репорта и ещё 91 человек, что нагуглили ту же проблему и не поленились поставить лайк.
          4. Я считаю эту фичу кривым дизайном.

          Зачем вы плясали с бубном и пытались самостоятельно разбираться в том, что прямым текстом описано в любом туториале по тестированию ангуляра и ангуляровскому DI?

          Вы в конкретное место этого полотна меня ткните, где описано, что надо использовать "устаревший" @Inject(), чтобы тесты не падали: https://angular.io/guide/testing


          Зачем вам эти 4 файла?

          Как минимум: скрипт, шаблон, стили, модуль и тесты. Плюс то же самое для демонстрационного компонента. Всё это надо провязать друг с другом и с приложением. Писать html и css в строковых литералах — так себе удовольствие, если вы об этом. Даже IDEA криво поддерживает миксование языков.


          Ангуляровский модуль — это замкнутый набор компонентов/сервисов, которые не могут работать друг без друга. Что вы собрались тут тришейкать?

          Представьте себе, я умею писать компоненты/сервисы/директивы/пайпы, которые могут работать друг без друга. И к каждому из них приходится писать отдельный ангуляровский модуль.


          Не надо изворачиваться, просто share().

          Очередной костыль для какого-то частного случая. При чём тут он? В Rx десятки таких костылей. Так что головоломка не только в том, как правильно сконфигурировать потоки, но и в том, какой же из этих костылей нужно использовать. Даже шпаргалки есть, ибо разобраться в этой груде похожих операторов весьма не просто: https://xgrommx.github.io/rx-book/content/which_operator_do_i_use/instance_operators.html И то тут далеко не все операторы учтены.


          Как она может быть несовместима, если именно так и работает?

          RxJS так не работает. Так работает Ангуляр. В результате получается химера из ОРП и ФРП. Посмотрите, как сделан $mol или Vue — там нет никаких стримов. Только объекты, их свойства, функции вычисления их значений и всё, никаких десятков видов стримов с сотней операторов.


          я мутабельно меню состояние в редьюсере и все ломается, что такое??? приходится лепить воркэраунды и костыли, говно ваш редакс

          Он говно не поэтому, а потому что синглтон.


          Даже если забыть про то, что html совршенно не годится для композиции компонент
          С каких это пор?

          С тех пор как появился. Тут я это уже расписывал: https://github.com/nin-jin/slides/tree/master/mol#%D0%A7%D1%82%D0%BE-%D0%BD%D0%B5-%D1%82%D0%B0%D0%BA-%D1%81-html


          Можете привести пример «неужасной» реализации?

          Ambient context из $mol или React.


          shadow dom и так то мертворождённая технология, ибо никому фактически не нужна, а проблем доставляет массу.
          Почему не нужна?

          Потому что болтами привязывает вас к DOM. Опыт Polymer показывает, что это тормоза на ровном месте и крайнее неудобство использования. А в тренде всякие VDOM, SSR, Canvas и Native.


          Разве придумали уже какой-то другой человеческий способ изоляции стилей?

          1. Изоляция стилей доставляет больше проблем, чем пользы. Банально попробуйте вменяемо реализовать разные цветовые схемы разных панелей, содержащих одни и те же компоненты, чтобы работало в IE11.
          2. Вы правда считаете реализацию этой псевдоизоляции в Ангуляре человеческой? С невменяемым поведением :host-context. С депрекейтнутым без альтернатив :ng-deep. С адской специфичностью селекторов. И криптомусором в доме.

          Опять же, в сравнению с чем? Реакт, вон, на каждое обновление вообще заново всю страницу перестраивает.

          Нашли на кого ровняться, да. Посмотрите как слежение за изменениями сделано в $mol и Vue — им не надо обновлять состояния всех компонент, чтобы понять, что ничего ререндерить не надо.


          Не используйте плохо написанные, не поддерживающиеся компоненты.

          Классный совет. Можно добавить ещё: никогда не обновляйте Ангуляр. А то у нас тут ребята потратили спринт на обновление до 5 версии, но так и не завелось. В итоге откатились до 4, ибо фичи сами себя не сделают, пока разработчики развлекаются с дебагом чужого говнокода. У меня к вам встречный совет — не используйте плохо написанные, криво спроектированные переусложнённые фреймворки без цельной экосистемы переиспользуемых компонент.


    1. nsinreal
      13.02.2018 15:34
      #10666872

      Добавлю
      1. Нетипизированный роутинг
      2. Нетипизированные формы
      3. Dependency Injection строго иерархический: нельзя предоставить сервис объявленный на нижнем уровне внутрь сервиса объявленного на верхнем уровне. Дрочево.
      4. DI не предоставляет хуков для уничтожения сервисов
      5. Бойлер-плейт везде.
      6. Нет способа добавить поведение к компоненту извне. Директивы не считаются, ибо умеют только с нативным аттрибутами и ивентами работать.
      7. Для того, чтобы ngFor работал не через жопу нужно написать trackBy и объявить метод в компоненте. Варнинга нет. Самый частый кейс: взять одно свойство. Раньше были идеи о простом синтаксисе, но это выкинули. Угар.
      8. Потрясная совместимость с rxjs. Если вы начинаете дрочиться с rxjs, то вам приходится руками писать в ngOnChanges костыли, чтобы у вас получился стрим ченджей.


  1. artiq
    12.02.2018 12:35
    #10664252
    +1

    Напишу о боли в работе с ангуляром 5:


    1. Милые сердцу стектрейсы zone.js
    2. Нет fail fast, там где он нужен. Как пример: очень, очень странные баги с роутингом, когда в router-outlet рендерятся сразу 2 роута при переходе(предыдущий остается, внизу рендерится тот, на который переходим) из-за того, что где-то что-то упало. Причем, они рендерятся, как-будто все нормально.
    3. Отсутствие человеческих render props.


    1. serf
      12.02.2018 12:50
      #10664302

      Соглашусь что родной роутинг кривоватый (допустим навигация из лейзи модулей как внутри так и глобально как-то нелогично работает, баги непофикшенные давно висят в гитхабе), а вот как ui router с ангуляром?


  1. vitstr
    12.02.2018 13:51
    #10664406

    имхо, в голосовании не хватает пункта про наличие/отсутствие адекватного инструмента отладки в дополнение к dev-tools. Augury справляется с этой задачей так себе.


  1. undersunich
    12.02.2018 15:09
    #10664580

    В статье нехватает ссылок на СВОБОДНЫЕ вакансии по Ангуляру.
    Если их будет такое же огромное колличество как тонны ссылок из данной статьи то — да, на Ангуляр стоит переходить.Сложность разработки растет, это однозначно.Это хорошо или плохо? Для компании производителя сложности это хорошо.А для людей это хорошо? Вы попробуйте устроится на работу в компанию в которой как стандарт принят подобный инструмент.Вас на собеседовании будут гонять по знанию всех этих мегатон технических особенностей.Ангуляр стремительно движется в сторону «касты» и «углового братства».При этом бизнес который возьмен за основу данный инструмент попадет в ловушку сложности и замкнутости.


    1. bjornd
      12.02.2018 18:45
      #10665180
      -1

      Моя любимая ссылка по теме stateofjs.com/2017/front-end/results. Пишут на Angular 2 в три раза меньше, чем на React. При этом половина из тех, кто пишет на Angular продолжать с ним работать не хочет.


      1. serf
        12.02.2018 21:36
        #10665408
        -2

        Зачем на всех ровняться? Не забывайте что во фронт-енд разработке большая часть скрипт-кидди.


        1. bjornd
          13.02.2018 11:28
          #10666214

          Не забывайте что во фронт-енд разработке большая часть скрипт-кидди.

          Есть какая-то статистика?


      1. Druu
        13.02.2018 03:44
        #10665770

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


        1. bjornd
          13.02.2018 11:36
          #10666248

          Если у вас есть более корректная статистика — поделитесь.


  1. mobilz
    12.02.2018 15:50
    #10664714
    +1

    Офигеть вы красавчики. Аплодирую стоя


  1. mclander
    12.02.2018 16:17
    #10664824

    Ох! Дочитал.

    В списке модулей часть оказались подсвеченными, как посещённые:

    • ng-bootstrap + @ng-bootstrap/ng-bootstrap, пользуюсь с удовольствием, но сейчас взял бы такую обёртку ngx-bootstrap
    • angular-modal, ng-modal — пробовал все но, в итоге остался с бутсраповским модалом — не очень удобно переопределять классы css
    • ng-charts — пришлось переписать компонент, уже не помню причин, что-то с неожиданной перерисовкой или её отсутствием) Поскольку там несколько ручных хаков под мой проект — не стал публиковать
    • ng-pdf-viewer — тоже не самая удачная обёртка, но руки переписать не дошли
    • ng-smart-table — вот за это хочется выдать с ноги. Один из лучших гридов в AngularJS — smart-table. Простой до безобразия, но позволяющий делать любые стандартные и нестандартные вещи без напряга. И тут какие-то красавчики делают библиотеку, которая по сравнению с «предшественником» как-то не выглядит smart. Обычных крепкий грид с сортировочкой, но не конструктор гридов… Ээх, возможно авторы smart-table не стали портировать либу на ng2+ из-за того, что такая «уже есть»)))


    PS. Вообще A2+ мне нравится больше и больше по сравнению с angularJS, но проблема в том, что меня уже не бесит так React)


    1. jMas
      12.02.2018 17:03
      #10664922
      +1

      PS. Вообще A2+ мне нравится больше и больше по сравнению с angularJS, но проблема в том, что меня уже не бесит так React)

      Не холивара ради, просто интересно что вас смущает в React?


      1. mclander
        12.02.2018 17:17
        #10664974

        Уже ничего. Раньше не нравился за «птичий язык» разметки и необходимость писать лишние буквы в this.state… Сейчас благодаря redux/mobx работы со стейтом не много и в основном в рендере. А если оная есть, то можно быстренько сделать алиас. 

        render() {
   let state = this. state, branch = this.state.branch;


        Ну и отсутствие двустороннего связывания, после A1. Вместо халявы this.x = 1, нужно обновление стейта this.setState({x :1}). Теперь двустороннее подвыпилили и из А2+ (точнее сделали его не таким халявным, особенно в структурах). Понятно, что это всё ради скорости, но у меня и A1 не тупил, потому что не связывал того, что не надо связывать;)

        Ну это так ворчание, бойлерплейта везде теперь пачка.


        1. jMas
          12.02.2018 18:25
          #10665140
          +1

          Лично я активно пользуюсь деструктуризацией и функциональными компонентами:


          function MyComponent({ propA, propB }) { return (<div>{propA + propB}</div>); }

          … учитывая, что statefull компоненты нужны далеко не всегда. Жизнь упрощает и это скорее дело вкуса.


          P/S: Недавно на хабре была статья про hyperapp — достаточно интересная библиотека, упрощающая работу с actions/reducers/lifecycle (правда API не совместимый с React).


        1. Fen1kz
          12.02.2018 22:29
          #10665474

          А почему пишете let вместо const? Сорри, просто для меня в коде let это как красный флаг «здесь какая-то магия watch out»


          1. mclander
            13.02.2018 12:37
            #10666452

            Просто let короче)

            Это личные предпочтения, я пишу let вместо var, потому что это даёт серьёзную выгоду в понимании и огораживании зоны видимости. А вот const использую только в случаях когда надо определить реальную константу.

            Это связано с другими языками программирования, немного сложно перестраивать понимание, что const — это не константа, а просто что-то внезапно становящееся неизменяемым в данной зоне видимости через данный алиас.

            Возможно, это действительно плохой стиль и надо больше константить объявления. Спасибо за замечание)


            1. bjornd
              13.02.2018 13:30
              #10666620

              Возможно, это действительно плохой стиль

              Многие действительно так считают, есть правило для eslint, хотя оно и выключено по умолчанию, — eslint.org/docs/rules/prefer-const


              1. mclander
                13.02.2018 14:59
                #10666796

                Ну правила для eslint — это не довод. У меня пачка правил для tslint отключена, в т.ч. и для продакшена. Есть, например, такое холиварное правило, как запрет if без {}. Но проблема в том, что короткие условия с коротким операндом читаются лучше, чем braced if.

                Использование const для контроля кода по мне плохое обоснование. Я не считаю, что программиста следует бить линейкой по рукам только за гипотетическую возможность сделать хрень. Это меня ещё в питоне выбешивало.

                Вот то, что const упрощает чтение кода, для людей привыкших к такой нотации, для меня довод. Хотя приходится постоянно читать исходники чужих пакетов и порой излишнее следование «правилам хорошего кода», бесит больше, чем им не следование. Если код читается хорошо и автор достаточно хорош, чтобы не допускать сайд-эффектов, то по мне пусть хоть var использует всегда. А если человек использует const, строгую типизацию, 100500 досконально описанных интерфейсов, но у него проблемы с логикой… или код теряется за «феншуйным» бойлерплейтом — мои лучи ненависти рвутся на свободу.


                1. bjornd
                  13.02.2018 16:55
                  #10667058

                  Для коротких условий с коротким операндом есть тернарный оператор или просто &&.


                  1. mclander
                    14.02.2018 16:46
                    #10669186

                    И что вам скажет eslint с настройками «из коробки», на конструкт типа:

                    options.add5ton ? weight += 5000 : 0;

                    или
                    options.add5ton && weight += 5000;

                    А уж что вам скажет тимлид? И сколько слов в его речи будет не обсценными? )

                    Ну, понятно, что вы имели ввиду

                    weigth += options.add5ton? 5000: 0;

                    Но если задача стоит так

                    if (options.let5ton) params.weigth = 5000;

                    Как это записать с тернарником, чтобы не создать лишний ключ?


                1. jMas
                  14.02.2018 14:38
                  #10668852

                  Допустим у нас часто попадаются любители переприсвоить что то. Даже если случайно оставил let кто то в будущем прийдет и соблазнится переопределить переменную на что то собственное. Код начинает становиться плохо читаемым, потому что вначале функции ты ожидаешь что в переменной ондо значение, а где то посередине значение заменили на что то новое и в конце переменная содержит уже что то третье. В JS есть отличная функция reduce() которая поможет избавиться от множества let, а создание константы с новым именем явно даст понять, что значение изменилось, и то чем "переменная" являлась в начале функции — к концу явно поменялось.


  1. mclander
    12.02.2018 17:17
    #10664972

    .


  1. xSorcerer
    12.02.2018 22:46
    #10665490

    Спасибо за статью. Сам после angular 1 сразу пересел на angular 4 — почти всё очень нравится, особенно подход к созданию форм. А единожды попробовав typescript — без него писать уже не захочешь :)
    Единственное что смущает — наличие ZoneJs. Если какой-нибудь нерадивый разработчик напишет в своей библиотечке setInterval(..., 10) — то приложение сразу впадает в шок от происходящего. Да и странно это писать везде zone.runOutsideAngular, что бы не запускать ChangeDetection. Как по мне подход angular1 к запуску цикла проверки был удачнее