Удивительный Angular

    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 по умолчанию использует двустороннее связывание модели данных, то при работе с большим объемом таких данных ваши приложения будут работать медленнее, поэтому в некоторых случаях стоит позаботиться о правильной стратегии обнаружения изменений. Вы можете посмотреть на различные 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. С вами были Максим Иванов и Дмитрий Сергиенков, пока.

    Only registered users can participate in poll. Log in, please.

    Что вы считаете неудобным в экосистеме Angular и какими слабостями он обладает?

    Share post

    Similar posts

    Comments 59

      +2
      Спасибо! Много полезной инфы.
        +3
        Добавил в закладки, спасибо за подборку.
        К голосованию я бы еще добавил бы пункт про оптимизацию, из коробки Angular показывает довольно невысокую оптимизацию. Не сказать, что это сложно исправить, но новичка это может обескураживать.
          +1
          из коробки Angular показывает довольно невысокую оптимизацию

          Даже если CLI использовать?
          Но понимать хотя бы onPush в связке с иммутабельным стором желетельно, что не идет из коробки вместе с CLI.
          PS лично я не большой сторонник использования CLI, но в реальности выбор зависит от проекта и команды.
          +1
          splincodewd Нужен фикс твиттера Минара twitter.com/igorminar :)
            +1
            в закладку сразу :) такое нельзя пропустить.
              +12
              но гордится больше всего тем, что почти 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 в лучших традициях запрятано куда-то в жопу и настолько переусложнено, что через отладчик хрен разберёшься, где что одно проиинъектиться и почему он не может что-то правильно заинъектить.


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

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

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

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

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

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


                  //example.component.ts
                  data: any;
                  
                  //example.component.html
                  {{data.field}}

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

                    +1
                    Что значит dev и prod, имеется ввиду CLI на настройка по умолчанию? Там в prod AOT включен и fullTemplateTypeCheck поставлен в true если не ошибаюсь, а в dev по уполчанияю это выключено, но скоро планирубт включить. Но вообще можно ведь настроить как угодно сборку, не полагаясь на CLI (который кривоватый в целом). Включите себе AOT и fullTemplateTypeCheck в dev режиме и будет более строгая валидация.
                      0
                      Кстати с какой ошибкой падает? По логике при типе any ошибки быть не должно. Есть у меня догадка что у вас падает линтинг, тк в в CLI вроде codelyzer рулы настроны на {{ data.field }} формат выражения, а не {{data.field}} (то есть с пробелами нужно). PS лучше any использовать поминимуму и включить stric:true опцию компиляции TS.
                    0
                    Ну, банальный пример: как сделать так, чтобы при переходе с /tasts/ на tasks/1/ роутер не перерендеривал весь список задач, а просто открывал рядом панельку с детализацией? Базовое поведение безбожно сломано кривыми абстракциями.
                    Я конечно не видел ваш конфиг, но в большинстве знакомых мне способов реализации — ничего перерендериваться не будет. Самый обычный способ через — loadChildren.
                      –1
                      > Ну, банальный пример: как сделать так, чтобы при переходе с /tasts/ на tasks/1/ роутер не перерендеривал весь список задач, а просто открывал рядом панельку с детализацией?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


                        Шаблоны, основанные на расширении 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.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                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, ибо фичи сами себя не сделают, пока разработчики развлекаются с дебагом чужого говнокода. У меня к вам встречный совет — не используйте плохо написанные, криво спроектированные переусложнённые фреймворки без цельной экосистемы переиспользуемых компонент.

                                  0
                                  Два разных роута — два разных компонента.

                                  Можно использовать кастомный матчер, чтобы у вас был один роут, и тогда перерендеринга не произойдёт. Опциональные параметры в ангуляре не поддерживаются, но через кастомный матчер делаются довольно несложно, вот тут github.com/angular/angular/issues/12347#issuecomment-338903820 я предложил решение.
                                  Но специфики вашего проекта конечно не знаю, может быть это тоже не подойдёт.
                                    0
                                    > Конечно, можно ведь делать все эти приседания вручную.

                                    О каких приседаниях речь-то? Мне кажется, вы тут боретесь с собственноизобретенной проблемой.

                                    > О, это чудеснейшая вещь, которая зашивает в урлах структуру отображения, из-за чего урлы у вас буду выглядеть не /tasks/1/, а /(left:tasks;right:tasks/1).

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

                                    > Она бесполезна. От слова «совсем».

                                    Полезна, потому что показывает наличие забытых компонент.

                                    > Поведение с АОТ и без него не консистентно.

                                    Оно и не должно быть консистентно, потому что с АОТ приложение работает не так как с джитом.

                                    > Я считаю эту фичу кривым дизайном.

                                    Ну считайте, однако, мнение на факты не влияет.

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

                                    Там даже раздел про Inject() есть, разве не так?

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

                                    Что-то я не понял, сперва вы говорите что вам влом создать 4 файла, а потом говорите, что писать html и css — так себе удовольствие. Уж выберите что-то одно — вы ходите писать html/css в том же файле, или отделять от логики? В чем там у вас проблема с «провязыванием» (1 строчка для темплейта, одна — для стилей) вообще не ясно.

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

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

                                    > Очередной костыль для какого-то частного случая. При чём тут он?

                                    При том, что он решает вашу проблему в 100% случаев. Не надо никакой груды операторов. Просто share() на конце любого observable со значительным количеством вычислений.

                                    Операторов, конечно, много, но по факту нужны map, flatMap, switchMap, combineLatest, withLatest, share. Ну do для отладки. Что-то иное нужно _крайне_ редко, раз на тысячи строк кода.

                                    > Посмотрите, как сделан $mol или Vue — там нет никаких стримов. Только объекты, их свойства, функции вычисления их значений и всё

                                    И ангуляр забыли, там тоже стримов нет.

                                    > RxJS так не работает.

                                    А как он, по-вашему, работает?

                                    > С тех пор как появился. Тут я это уже расписывал:

                                    Среди того, что расписано я вижу плюсы html, а не минусы.

                                    > Ambient context из $mol или React.

                                    Серьезно? Нечитабельный мол и помесь ужа с ежом из реакта — хорошая реализация?

                                    > Потому что болтами привязывает вас к DOM.

                                    Вы что-то путаете. Это просто механизм изоляции стилей для компонента, он будет работать точно тем же образом и для рендера в системе, у которой никакого дома нет. Ангуляр вообще полностью отвязан от дома, т.к. о существовании дома знает только самый низкий уровень рендера (который можно заменить и рендерить, например, в virtual dom или в нейтив).

                                    > Изоляция стилей доставляет больше проблем, чем пользы. Банально попробуйте вменяемо реализовать разные цветовые схемы разных панелей, содержащих одни и те же компоненты, чтобы работало в IE11.

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

                                    > Вы правда считаете реализацию этой псевдоизоляции в Ангуляре человеческой?

                                    Да, она не лучшая, но это лишь временное решение до повсеместного введения shadow dom.

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

                                    Там слежение за изменениями не сделано никак, т.к. фреймворку о том, как и что изменяется, объясняет сам программист, руками. Причем вместо существующих вариантов описания (вроде тех же обсерваблов, которые известны, понятны, имеют библиотеки с широким функционалом) предполагаются свои костылеобразные огрызки.

                                    > У меня к вам встречный совет — не используйте плохо написанные, криво спроектированные переусложнённые фреймворки без цельной экосистемы переиспользуемых компонент.

                                    Это не поможет, увы, так как говенные компоненты есть для любых фреймворков.
                                      –1

                                      Одни передёргивания… вам не стыдно использовать такие убогие демагогические приёмы для защиты какого-то фреймворка?


                                      О каких приседаниях речь-то? Мне кажется, вы тут боретесь с собственноизобретенной проблемой.

                                      Конечно же ангуляровские модули — это моё изобретение.


                                      Уж выберите что-то одно — вы ходите писать html/css в том же файле, или отделять от логики? В чем там у вас проблема с «провязыванием» (1 строчка для темплейта, одна — для стилей) вообще не ясно.

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


                                      Это множественные роутеры, а не вложенные (когда несколько разных, независимых роутов на одной странице).

                                      Ага, это named router-outlet — одно из типично предлагаемых решений.


                                      Полезна, потому что показывает наличие забытых компонент.

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


                                      Оно и не должно быть консистентно, потому что с АОТ приложение работает не так как с джитом.

                                      AOT переносит компиляцию шаблонов с рантайма в компайлтайм. Это ненормально, что корректно написанное приложение перестаёт собираться из-за кода, который оно не использует.


                                      Зачем вы полезную фичу объявляете багом?
                                      Багом её считаю не я, а автор баг-репорта и ещё 91 человек, что нагуглили ту же проблему и не поленились поставить лайк. Я считаю эту фичу кривым дизайном.
                                      Ну считайте, однако, мнение на факты не влияет.


                                      Огрызайтесь, пожалуйста, перед зеркалом.


                                      angular.io/guide/testing
                                      Там даже раздел про Inject() есть, разве не так?

                                      Уверен вы вполне в состоянии открыть ссылку и воспользоваться поиском по странице.


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

                                      Наличие откровенно лишней абстракции, которая и форсируется, и не создаётся стандартным кодогенератором автоматически.


                                      Очередной костыль для какого-то частного случая. При чём тут он?
                                      При том, что он решает вашу проблему в 100% случаев.

                                      Не решает и для 1%.


                                      Не надо никакой груды операторов. Просто share() на конце любого observable со значительным количеством вычислений.

                                      Если это всё, что вы умеете делать для оптимизации, то вы пишите крайне неэффективный код. Эффективный код на Rx писать катастрофически сложно.


                                      Операторов, конечно, много, но по факту нужны map, flatMap, switchMap, combineLatest, withLatest, share. Ну do для отладки.

                                      debounce, distinctUntilChanged, subscribe, unsubscribe, next, throw, getValue, 'catch', defer,


                                      Что-то иное нужно крайне редко, раз на тысячи строк кода.

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


                                      И ангуляр забыли, там тоже стримов нет.

                                      https://github.com/angular/angular/search?q=rxjs


                                      RxJS так не работает.
                                      А как он, по-вашему, работает?

                                      Уверен вы прекрасно знаете как он работает. Остальным же рекомендую почитать: https://github.com/nin-jin/slides/tree/master/orp#%D0%9F%D0%B0%D1%80%D0%B0%D0%B4%D0%B8%D0%B3%D0%BC%D1%8B чтобы понять фундаментальную разницу.


                                      Среди того, что расписано я вижу плюсы html, а не минусы.

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


                                      Ambient context из $mol или React.
                                      Серьезно? Нечитабельный мол и помесь ужа с ежом из реакта — хорошая реализация?

                                      Серьёзно. Реализация контекста в $mol никак не связана с языком композиции кмпонент, который вы необоснованно хейтите. И что не так с его реализацией в реакте? Ну, кроме того, что реакт не умеет в реактивность.


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

                                      И при чём тут styles encapsulation, если мы говорили про shadow-dom, который без собственно dom не работает?


                                      Ангуляр вообще полностью отвязан от дома, т.к. о существовании дома знает только самый низкий уровень рендера (который можно заменить и рендерить, например, в virtual dom или в нейтив).

                                      И все компоненты, что используют нативные события или нативные элементы. То есть почти все компоненты. Эта красивая сказка про безболезненную подмену рендерера — не более чем сказка. Она хороша, пока ею не начнёшь заниматься.


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

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


                                      Да, она не лучшая, но это лишь временное решение до повсеместного введения shadow dom.

                                      С учётом популярности React и непопулярности Polymer, shadow dom можно уже не ждать.


                                      Там слежение за изменениями не сделано никак, т.к. фреймворку о том, как и что изменяется, объясняет сам программист, руками.

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


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

                                      Разберитесь в предмете, пожалуйста, чотбы не говорить глупостей: https://habrahabr.ru/post/349022/


                                      У меня к вам встречный совет — не используйте плохо написанные, криво спроектированные переусложнённые фреймворки без цельной экосистемы переиспользуемых компонент.
                                      Это не поможет, увы, так как говенные компоненты есть для любых фреймворков.

                                      На $mol их гораздо меньше в процентном соотношении. Всё потому, что писать качественные компоненты на $mol гораздо проще, чем на Ангуляре.

                                        0
                                        > Конечно же ангуляровские модули — это моё изобретение.

                                        И какая связь с приседаниями?

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

                                        Вы что-то выдумываете. Создать три файла — дело пары секунд, все провязывание — состоит в указании стилевого файла и файла шаблона, это две строчки в описании компонента, в одном месте. Это все.

                                        > Ага, это named router-outlet — одно из типично предлагаемых решений.

                                        Я не знаю, что за вредители вам какие-то странные вещи предлагают. Есть вполне конкретные инструменты, при помощи которых ваша вполне конкретная задача решается без каких-либо проблем.

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

                                        А что должно измениться?

                                        > AOT переносит компиляцию шаблонов с рантайма в компайлтайм.

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

                                        > Уверен вы вполне в состоянии открыть ссылку и воспользоваться поиском по странице.

                                        Я им воспользовался, и вижу раздел про inject.

                                        > Наличие откровенно лишней абстракции, которая и форсируется, и не создаётся стандартным кодогенератором автоматически.

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

                                        > Не решает и для 1%.

                                        Ну вы приведите пример, где не решает.

                                        > Если это всё, что вы умеете делать для оптимизации, то вы пишите крайне неэффективный код. Эффективный код на Rx писать катастрофически сложно.

                                        Этого вполне достаточно для того, чтобы обеспечить однократное вычисление любого тяжелого кода. И это очень просто.

                                        > debounce, distinctUntilChanged, subscribe, unsubscribe, next, throw, getValue, 'catch', defer,

                                        Next, да, нужен, про него забыл. debounce является семантическим оператором и не относится вообще к внутренней логике обсерваблов. Остальное — просто практически никогда не нужны, а зачастую и вредны.

                                        > Один раз из 10 приходится лезть в документацию в поисках очередного оператора, чтобы сделать простейшую вещь.

                                        Вы не можете запомнить десяток операторов? Это странно.

                                        > github.com/angular/angular/search?q=rxjs

                                        Что должна продемонстрировать ваша ссылка?

                                        > Уверен вы прекрасно знаете как он работает.

                                        Прекрасно знаю, потому и говорю — именно так он и работает.

                                        > Серьёзно. Реализация контекста в $mol никак не связана с языком композиции кмпонент, который вы необоснованно хейтите. И что не так с его реализацией в реакте? Ну, кроме того, что реакт не умеет в реактивность.

                                        Мы, вроде, про синтаксис говорили? С ним все не так.

                                        > И при чём тут styles encapsulation, если мы говорили про shadow-dom, который без собственно dom не работает?

                                        Он при том, что shadow-dom — просто механизм реализации styles encapsulation. Ничего более.

                                        > И все компоненты, что используют нативные события или нативные элементы.

                                        К счастью, таких компонентов практически нет. Более того — использование нативных событий и элементов строго нерекомендовано.

                                        > Поэтому фреймворки с грамотной архитектурой либо форсируют единообразное использование цветовых схем всем компонентам и/или предоставляют механизмы поменять любые стили любого стороннего компонента.

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

                                        > С учётом популярности React

                                        Эта популярность — лишь популярность в сравнении с другими спа-фреймворками, что в общем море веба составляет каплю.

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

                                        Так вам при реактивном подходе и приходится объяснять, что и в какой последовательности. Он в этом и состоит.

                                        > Разберитесь в предмете, пожалуйста, чотбы не говорить глупостей:

                                        Разобраться в чем? В том, что можно переписать реакт и заставить его работать на обсерваблах? А кто-то с этим спорил?

                                        > На $mol их гораздо меньше в процентном соотношении. Всё потому, что писать качественные компоненты на $mol гораздо проще, чем на Ангуляре.

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

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


                                  1. Милые сердцу стектрейсы zone.js
                                  2. Нет fail fast, там где он нужен. Как пример: очень, очень странные баги с роутингом, когда в router-outlet рендерятся сразу 2 роута при переходе(предыдущий остается, внизу рендерится тот, на который переходим) из-за того, что где-то что-то упало. Причем, они рендерятся, как-будто все нормально.
                                  3. Отсутствие человеческих render props.
                                    0
                                    Соглашусь что родной роутинг кривоватый (допустим навигация из лейзи модулей как внутри так и глобально как-то нелогично работает, баги непофикшенные давно висят в гитхабе), а вот как ui router с ангуляром?
                                    0
                                    имхо, в голосовании не хватает пункта про наличие/отсутствие адекватного инструмента отладки в дополнение к dev-tools. Augury справляется с этой задачей так себе.
                                      +2
                                      В статье нехватает ссылок на СВОБОДНЫЕ вакансии по Ангуляру.
                                      Если их будет такое же огромное колличество как тонны ссылок из данной статьи то — да, на Ангуляр стоит переходить.Сложность разработки растет, это однозначно.Это хорошо или плохо? Для компании производителя сложности это хорошо.А для людей это хорошо? Вы попробуйте устроится на работу в компанию в которой как стандарт принят подобный инструмент.Вас на собеседовании будут гонять по знанию всех этих мегатон технических особенностей.Ангуляр стремительно движется в сторону «касты» и «углового братства».При этом бизнес который возьмен за основу данный инструмент попадет в ловушку сложности и замкнутости.
                                        0
                                        Моя любимая ссылка по теме stateofjs.com/2017/front-end/results. Пишут на Angular 2 в три раза меньше, чем на React. При этом половина из тех, кто пишет на Angular продолжать с ним работать не хочет.
                                          –4
                                          Зачем на всех ровняться? Не забывайте что во фронт-енд разработке большая часть скрипт-кидди.
                                            0
                                            Не забывайте что во фронт-енд разработке большая часть скрипт-кидди.

                                            Есть какая-то статистика?
                                            0
                                            Там нигде не описаны характеристики выборки, нормализация и т.п. вещи, так что считать это корректной статистикой нельзя.
                                              0
                                              Если у вас есть более корректная статистика — поделитесь.
                                          +1
                                          Офигеть вы красавчики. Аплодирую стоя
                                            0
                                            Ох! Дочитал.

                                            В списке модулей часть оказались подсвеченными, как посещённые:
                                            • 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
                                              PS. Вообще A2+ мне нравится больше и больше по сравнению с angularJS, но проблема в том, что меня уже не бесит так React)

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

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

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


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

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

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


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

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


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

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

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

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

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

                                                        Многие действительно так считают, есть правило для eslint, хотя оно и выключено по умолчанию, — eslint.org/docs/rules/prefer-const
                                                          0
                                                          Ну правила для eslint — это не довод. У меня пачка правил для tslint отключена, в т.ч. и для продакшена. Есть, например, такое холиварное правило, как запрет if без {}. Но проблема в том, что короткие условия с коротким операндом читаются лучше, чем braced if.

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

                                                          Вот то, что const упрощает чтение кода, для людей привыкших к такой нотации, для меня довод. Хотя приходится постоянно читать исходники чужих пакетов и порой излишнее следование «правилам хорошего кода», бесит больше, чем им не следование. Если код читается хорошо и автор достаточно хорош, чтобы не допускать сайд-эффектов, то по мне пусть хоть var использует всегда. А если человек использует const, строгую типизацию, 100500 досконально описанных интерфейсов, но у него проблемы с логикой… или код теряется за «феншуйным» бойлерплейтом — мои лучи ненависти рвутся на свободу.
                                                            0
                                                            Для коротких условий с коротким операндом есть тернарный оператор или просто &&.
                                                              0
                                                              И что вам скажет eslint с настройками «из коробки», на конструкт типа:
                                                              options.add5ton ? weight += 5000 : 0;

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

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

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

                                                              weigth += options.add5ton? 5000: 0;

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

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

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

                                                                params.weigth = options.let5ton ? 5000: undefined;
                                                                ?

                                                                  0
                                                                  мы создали поле в объекте, в данной задаче это может дать сайд эффекты
                                                                  +1
                                                                  options.add5ton && weight += 5000;

                                                                  Такой код приведет к ошибке, в случае присвоений выражение нужно в скобки брать options.add5ton && (weight += 5000);

                                                                  Я так раньше тоже писал, но перестал, считаю плохим тоном, ну и точку дебага так просто не поставишь на true или false. Линтеры для того и нужны чтобы стиль кодирования был консистентным, и это для меня это важнее нескольких лишних строк кода.
                                                                    0
                                                                    Я так не пишу) Это был пример для товарища выше.

                                                                    Хотя конструкт

                                                                    x && x();

                                                                    и его производные мне нравится но вот линтеру нет)
                                                                    +1
                                                                    if (options.let5ton) {
                                                                      params.weigth = 5000;
                                                                    }
                                                                    
                                                                    // vs
                                                                    
                                                                    if (options.let5ton) params.weigth = 5000;
                                                                    


                                                                    А я вот не противник такого принудительного расставления фигурных скобочек. Привыкаешь читать/писать одинаковый код везде. Ну да, это 3 строки вместо 1, но читается ли эта одна строка быстрее/легче чем 3? По мне так, как ни странно, для трех строк глазки то меньше туда-сюда двигаются.
                                                                    Но, на то правило и холиварное, что дело привычки. Допускаю, что кому-то 3 строки вместо 1 прям вот сердечную боль вызывают.
                                                                      0

                                                                      Я слышал что проблема в основном в таком


                                                                      if (options.let5ton) 
                                                                         params.weigth = 5000;
                                                                         params.height = 3000;
                                                                      params.update();
                                                                        0
                                                                        Да, именно в таком. Или в вот таком.
                                                                        if (options.let5ton && options.let5ton.allowed && something_function(options.let5ton) && somenthing_else()) params.weight +=5000;

                                                                        Поэтому при сложных условиях я пишу фигурные скобки. А в простых читается однозначно. При этом код остаётся компактным, что даёт выигрыш в чтении (я обычно стараюсь писать методы/функции «на полэкрана»).

                                                                        В Perl есть прикольный оператор unless (обратный if). А у всех (или почти всех) операторов управления есть постфиксная и префиксная форма, то есть можно писать и так:
                                                                        if ($options->let5ton) $params->weight += 5000;

                                                                        и так (в постфиксной форме скобки не надо):
                                                                        $params->weight += 5000 if $options->let5ton;

                                                                        Так вот. Хороший тон в Perl использовать unless, но использовать в постфиксной форме и только с простыми условиями, тогда код офигенно читается. А любое сложное условие в unless вызывает взять в одну руку кирпич, в другую автора кода…

                                                                        Хороший пример:
                                                                        while(<>){# берём $_ из потока
                                                                          chomp();# выкусываем CR/LF
                                                                          next unless;# если пустая строка сразу идём за следующей
                                                                          ...# обрабатываем строку  
                                                                        }

                                                                        или без «магии» умолчаний:
                                                                        while(my $line = <STDIN>){ 
                                                                          chomp($line); 
                                                                          next unless $line; 
                                                                          ... # обрабатываем строку  
                                                                        
                                                                        }
                                                                          0

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


                                                                          if (options.let5ton) 
                                                                             params.weigth = 5000;
                                                                             params.height = 3000;
                                                                          params.update();
                                                                  0

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

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

                                                          Удивительный Angular: вроде бы хороший фреймворк, а вроде бы и нет. Обсуждение проблем и костылей для их решения в комментариях прекрасно дополняет позитивную повестку самой статьи

                                                            0
                                                            Ребят, посоветуйте где можно найти хорошего фронтенд разработчика на Angular5 на проектную работу? Есть ли сообщество/форум посвященный таким публикациям помимо fl.ru/freelansim? Буду признателен за рекомендации

                                                            Only users with full accounts can post comments. Log in, please.