Комментарии 38
Может кто-нибудь знает про про StaticInjector? Чем он лучше ReflectiveInjector?
platformBrowserDynamic([{ provide: A1, useClass: A1, deps: [B1] }, B1])
.bootstrapModule(AppModule, { providers: [ {provide: A2, useClass: A2, deps: [B2]}, B2 ] })
С виду те же метаданные, только отделенные от классов.
Кода больше надо писать, указывать зависимости вручную.
Как обеспечить типобезопасность, ведь классы аргументов передаются отдельно в deps.

Или bootstrap-код теперь сам компилятор генерит?

Если дело только в скорости было, то можно было просто отказаться от тормозного Reflect.defineMetadata и генерировать более оптимальные метаданные.
Зачем делать зависимости только явными?
НЛО прилетело и опубликовало эту надпись здесь

Как то они слишком часто стали релизить новую версию. Будто вчера был мега релиз 2рого)

Теперь каждые полгода, с большей совместимостью между версиями)))
Было бы здорово если бы разработчики включили Angular Universal в сам Angular и SSR уже бы поддерживался из коробки.
А разве не пол года назад был релиз 4 версии? Или это как с сериалом, новый сезон каждые год (в данном случае пол)?
НЛО прилетело и опубликовало эту надпись здесь
Сори, но со стороны звучит как штука которую очень трудно поддерживать.
НЛО прилетело и опубликовало эту надпись здесь

А какие у вас задачи для Javascript на не-spa страничке?


Переключение картинок стрелочками влево-вправо можно и на ванильном JS сделать.


А если есть какая-то сложная форма с логикой, то можно тот же Vue взять, только роутинг не использовать.

НЛО прилетело и опубликовало эту надпись здесь
все сборщики заточены на spa

расскажите об этом поподробнее. Я собирал вебпаком обычный мультистраничный сайт, особой заточки на SPA не заметил.

НЛО прилетело и опубликовало эту надпись здесь

У меня было так


entry: {
   home: "./src/home.js",
   product: "./src/product.js",
   search: "./src/search.js",
},

plugins: [
  new webpack.optimize.CommonsChunkPlugin({filename: "commons.js"})
]

Собирается 3 отдельных файла для каждой страницы, плюс файл "commons.js", в который складываются общие модули для всех трех страниц, в том числе фреймворк.


Если хотите явным образом вынести библиотеки в файл "vendor.js", для этого тоже есть рецепт.

НЛО прилетело и опубликовало эту надпись здесь

а что с vue файлами не так? Как я понимаю, в home.js будет что-то типа такого


import Vue from 'vue';
import HomeComponent from './components/Home.vue';

new Vue({
  el: '#app',
  render: h => h(HomeComponent)
});

примерно аналогичный код напишем и в product.js и search.js файлах

Не надо так делать. Достаточно сделать один входной файл app.js:
import Vue from 'vue';

// Перечисляем наши базовые компоненты
Vue.component('top-menu', require('./components/TopMenu.vue'));

new Vue({
  el: '#app'
});


После чего, этот компонент можно напрямую запихнуть куда угодно в шаблон страницы и Vue подхватит его без проблем:
<body>
  <div id="app">
     <top-menu></top-menu>
     <div class="content">
       ...
     </div>
  </div>
</body>

И никаких spa.

А как разделять компоненты по страницам?


Например, есть тяжелый компонент Filters, который нужен на странице поиска, но не на странице одного продукта.

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

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

Но обычно даже сильно большое spa редко переваливает в сжатом виде за 500кб (и то его тогда бьют на чанки). Так что это не такая большая беда, что ваш компонент будет присутствовать на каждой странице юзера, но рендериться только на одной. Да и к тому же хороший кеш решит все эти проблемы.
А что, если есть несколько мелких компонентов, которые юзаются повсеместно?

CommonsChunkPlugin вынесет их в отдельный commons.js файл. Настраивается в одну строчку.

Согласен. Ну тогда можно и Filters вынести в отдельный чанк и подключать по необходимости. Тоже одна строчка )
НЛО прилетело и опубликовало эту надпись здесь
Посмотрел на логотип, прочитал как «Апять [двадцать пять]».
А если без Ди Каприо? Никак? По моему символично.

Статья очень хорошо отображает суть A2+: очень много букв. Какие-то из них классные, на какие-то глаза бы мои не смотрели.

Зачем надо было выпиливать встроенные промисы и фильтры из коробки? чтобы на их место зафигачить монструозный RxJS? Если раньше нужно было сломать мозг над отличиями фабрики от провайдера, то теперь ломаем мозг, чем лучше subscribe вместо промисов. Если смысл тот же, но нет способа объединения подписок в цепочки)

В общем поматерившись два месяца, я таки смог успешно работать с A4. И по мне многое сделано хорошо. Может быть то, что сделано плохо (и очень плохо), наконец починили в А5. Пойду поем и дочитаю статью)
НЛО прилетело и опубликовало эту надпись здесь
Язык шаблонов. Шаг вперёд — два назад. То что в одном теге нельзя использовать ngFor и ngIf одновременно — это сильно. Приходится писать для одной из директив ng-template с артефактным синтаксисом, который лишь немного менее артефактен, чем ngFor.

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

Избыточность HttpService, избыточность Router* (при том что некоторые вещи всё равно делаются грязными хаками).

Бойлерплейт при регистрации компонетнов, сервисов.

Урезание двунаправленной «магии». Да, это даёт выигрыш в производительности у косоруких разрабов, но почему остальные для того, чтобы «поймать» изменение свойства на втором уровне вложенности должны писать обработчик dirtychecking руками или изобретать велосипеды типа динамические getter/setter like Vue?

Научиться контролировать размер scope не так сложно. Стоит начать это делать и А1 «летает».

Хотя по сути основных претензий две: документация и бойлерплейт. Вроде последнего стало меньше, по сравнению с А1, но стоит попробовать сделать чуть нестандарные вещи и опачки, в коде разрастаются загадочные inject'ы и связанные с ними воркарраунды.
НЛО прилетело и опубликовало эту надпись здесь
То что в одном теге нельзя использовать ngFor и ngIf одновременно — это сильно.
Это решается через ngFor + фильтр. Причины очевидны, но возможно когда-нибудь сделают разруливание этого на уровне фреймворка.
Шаг вперёд — два назад.
В целом да, убрали кучу косяков первой версии, но налепили кучу новых.
То что в одном теге нельзя использовать ngFor и ngIf одновременно — это сильно. Приходится писать для одной из директив ng-template с артефактным синтаксисом, который лишь немного менее артефактен, чем ngFor.
А в чём проблема использовать ng-container? У меня обычно для одного случая так
<ng-container *ngIf="somethingGlobal">
     <div *ngFor="let item of list">some {{item}} here</div>
</ng-container>

и для другого вот так
<ng-container *ngFor="let item of list">
     <div *ngIf="item.visible">some {{item.data}} here</div>
</ng-container>

и проблем нету никаких.
Можете попробовать <ng-container>, может подойдет к вашей проблеме.
Rxjs отличается от Promise идеологически и предназначен для другого — для реактивного программирования и работы с потоками данных.
Есть понятие pull-объектов, которые получают данные сами, и push-объектов, которые реагируют когда данные сами к ним приходят.
Вот
Pull / Single: Function
Push / Single: Promise
Pull / Multiple: Iterator
Push / Multiple: Observable

RxJs как раз решает вопрос о push-коллекциях. И его сила раскрывается в куда более сложных кейсах.

А объединяются они в цепочки через flatMap:
 // first, second возвращают observable
  first().flatMap(firstResult=>second())
   .flatMap(secondResult=>...)

Rx — это что-то из разряда "я его ненавидел пока не понял в чём его прикол, теперь жить без него не могу". Приходится, правда, сломать себе мозг, пока с ним разбираешься. Сейчас работаю над real-time приложением: данные и события прилетают из множества источников совершенно непредсказуемо и нужно адекватно на них реагировать. Даже не представляю как без Rx с этим можно справиться и не сойти с ума.

Я считаю, что эти цифры, количество установок, абсолютно некорректны. У меня, грубо говоря, 1 SPA из 10 попадает в паблик — что AngularJS, что React, что любой другой SPA. Остальное — приватные продукты, которые недоступну общему глазу. Предположу, что я не один такой.
> Многие разработчики отмечают, что если ваш код на Angular выглядит сложным, то это значит, что вы делаете что-то неправильно;

Как быть если чужой код на Angular выглядит сложным?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.