Pull to refresh

Comments 59

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

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


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

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

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

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

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

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


//example.component.ts
data: any;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


Уж выберите что-то одно — вы ходите писать 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 гораздо проще, чем на Ангуляре.

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

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

> Строчка там, строчка тут. Вот и выходит, что 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 гораздо проще, чем на Ангуляре.

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

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


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

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

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

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

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

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


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

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

weigth += options.add5ton? 5000: 0;

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

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

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

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

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

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

x && x();

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

// vs

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


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

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


if (options.let5ton) 
   params.weigth = 5000;
   params.height = 3000;
params.update();
Да, именно в таком. Или в вот таком.
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; 
  ... # обрабатываем строку  

}

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


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

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

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

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

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

Articles