Python conf in Kharkiv, Nov 16 with Intel, Elastic engineering leaders. Prices go up 21.10

Хтось вже тестував AngularJS 2, які ваші враження?

Я вже зачекався ... хоча б порадували вже бетою.

Дивлюся на доки і якось поки що не хочеться починати їх вчити, здається що друга версія ще глибоко в альфі, хоча milestones вже показує 75% нульової бети.

Також відлякує що на вибір дається зразу три варіанта:
— AngularJS 2 for TypeScript (by default)
— AngularJS 2 for JavaScript
— AngularJS 2 for Dart

Невже вони приблизно в рівній мірі перспективні, і не можна вибрати серед них фаворита?...

Хтось вже щупав AngularJS 2? Який із трьох варіантів? Справді там спостерігається «драматично» вища швидкість роботи? А як щодо зручності розробки (кажуть особливо спрощено оголошення директив)?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Давно стал поглядывать AngularJS. Есть-ли какие-то живые стартапы с кодом чтобы посмотреть чо как?

Точно вже є, про це можна почитати в їхньому блозі angularjs.blogspot.com (достатньо буде прочитати самих свіжих 10-20 дописів) щоб оглянути його можливості та прочитати де він використовується.

Можна вже не звертати увагу на першу версію, краще зразу дивитись на другу.

Намагаюсь зробити щоб в батьківському класі підключати сервіси, а в дочірньому класі використовувати їх, але тут є дилема:

— якщо в батьківському класі просто оголосити змінну з типом Service, то вона не інжектиться автоматично, треба її оголошувати лише при передачі в конструктор;

— якщо ж в батьківський конструктор передавати цю змінну, то обов’язково треба це ж робити в кожному дочірньому класі.

Ніхто не в курсі чи можна якось заінжектити змінну причому до спрацювання конструктора?

// В батьківському класі
import {Service} from '../services/service';

export class Parent
{
  constructor(public service: Service){}
}


// В дочірньому класі
import {Parent} from '../parent/parent';

export class Child extends Parent
{
  constructor()
  {
    super(); // error: Supplied parameters do not match any signature of call target.
    console.log(this.service); // undefined
  }
}

Кхм, схоже що я просто запрацювався.

Взагалі то, щоб вирішити дану «проблему», достатньо в батьківському класі інжектити необхідний сервіс, а у дочірньому просто не створювати конструктора =).

Схоже що починаючи з релізу AngularJS 2 його популярність на ринку праці підскочіть дуже помітно, а якщо в кандидатів є поєднання навичок «AngularJS 2 + Node.js + TypeScript + ES6», то пошук роботи для них навряд чи затягнеться...

Гм, схоже, що в альфі другої версії ангулара можна було спочатку зробити так

import { Start } from './components/start';
import { About } from './components/about';
import { Contact } from './components/contact';

...

@RouteConfig([
  { path: '/', component: Start, as: 'start'},
  { path: '/about', component: About, as: 'about'},
  { path: '/contact', component: Contact, as: 'contact'},
])

а потім в HTML-коді писати так

<nav>
  <ul>
    <li><a router-link="start">Start</a></li>
    <li><a router-link="about">About</a></li>
    <li><a router-link="contact">Contact</a></li>
  </ul>
</nav>

замість теперішнього варіанту, згаданого в документації

<nav>
  <ul>
    <li><a [routerLink]="['/Start']">Start</a></li>
    <li><a [routerLink]="['/About']">About</a></li>
    <li><a [routerLink]="['/Contact']">Contact</a></li>
  </ul>
</nav>

Чи все-таки можна і зараз якось спрощено писати директиви в HTML-коді?

Пробовал с typescript, сырое все, как по мне. Но я далеко не спец

С появления наблюдаю, причин для перехода с ember или просто попробовать сделать хоть что либо большее чем helloworld — пока не удалось найти. Разве что поиграться с аннотациями в тайпскрипте, но опять же — жс не на столько дубовый что бы применение этому требовалось.
Единственный вывод из всего — это тенденция движения в сторону «веб компонентов» в том виде как их видит (или приснится) конкретному разработчику. имхо

причин для перехода с ember
Хоча я сам не працював з ним, але кажуть, що до нього треба ще купу бібліотек прикрутити щоб він нагадував функціонал AngularJS, причому це говорилось за першу версію AngularJS.

Зараз я вже хоч трохи пощупав другу версію, то мені подобається все окрім розміру зібраних пакетів, хоча цей мінус скоро збираються прибрати. А так функціонал другої версії здається охоплює весь «динамічний фронтенд», так би мовити.

Есть же для второго angular-cli (кстати на основе эмбера)
На счет библиотек. Если относительно эмбера, то тут много вариантов, зависит от желания, хочешь — делаешь сборку самостоятельно кроме handlebars/htmlbars и ember-data из базы — ничего больше не нужно. Опять же — прекрасный ember-cli с babel компилятором с es6 .
А вот относительно ангуляра — разве он не позиционировался всегда как легковесная, простая в изучении библиотека ? (1.x я имею в виду, со 2м пока разбираемся)

На скільки я розумію, то це призначається для бекенда, так же?

Angular — это бэкенд фреймверк ?

Ні, але я чув згадку, що типу треба зробити можливість в ньому для prerendering’у на бекенді.

Вот Вы и ответили. А про быкенд, наверное это из-за популярности нового тренда fastboot начитались лишнего )

Enables offline compilation. We’re nearly complete with our next phase of performance optimization where we move all parsing/compiling to a build step. To make integration with existing build systems as smooth as possible we need to parse the template using Node.js without requiring any browser.
angularjs.blogspot.com/...plates-will-it-parse.html

Бігло продивився, здається це щось типу як npm для nodejs.

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

подобные тулзы можно найти тут:
yeoman.io/generators
либо же поискать подобные boilerplat-ы для angular-a приямо на гитхабах

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

Аннотации и рефлекшоны в жаве — понятно.. и то, по максимуму di ioc — ушло в хмльные бины. Для жс di реализуется во фреймверках (это если про долгоиграющее) .
Если говорить относительно статики — покажите хоть один реализованный паттерн для фронтенда где бы это требовалось, не говорю уже про невозможность реализации без этого. (gwt трансляции как опровержение если что)

Кому лень вчитываться в поток сознания.
>TypeScript provides static typing through type annotations to enable type checking at compile time
en.wikipedia.org/...peScript#Type_annotations

Какую Вы там бизнес логику в аннотациях пишете ? ))))

Аннотации и рефлекшоны в жаве — понятно..
зачем в одном предложении использовать слова джава и рефлекшн =) достаточно все грустно там..
Если говорить относительно статики — покажите хоть один реализованный паттерн для фронтенда где бы это требовалось, не говорю уже про невозможность реализации без этого
речь в первую очередь шла о TypeScript vs JS. Вот как раз аннотации в том виде, как они используются в angular2, в пример.

Вот и вернулись к тому с чего начинали — сомнительная нужность аннотаций.

все стало на свои места. я говорил о metada annotations.
а про type annotations вообще и речи не идет. я не знаю, как можно большие проекты писать хотя бы без такого механизма. не говоря уже о плюшке с DI. сам по себе compile-time type checking просто огромный прорыв как по мне

зачем в одном предложении использовать слова джава и рефлекшн =) достаточно все грустно там.

Пример использования технологий (не станете же спорить что это плохой пример) для управления бизнес логикой.

Ваш лінк веде не на метод subscribe, а тому сходу не зрозумів, але в підсумку все спрацювало, дякую.

Колупаюсь в другій версії ангулара, поки що не можу зрозуміти як мені виявляти зміни у location (це мені треба для встановлення класу active в головному меню).

На даний момент все добре працює при ініціалізації, але коли переходжу по сторінкам, то не бачу як можна прослуховувати зміну location (вішати на клік функцію не хочеться поки що)

@RouteConfig
([
  new Route({ path: '/', component: Home, name: 'Home', useAsDefault: true}),
  new Route({ path: '/about', component: About, name: 'About'}),
  new Route({ path: '/help', component: Help, name: 'Help'}),
])
export class App
{
  public selectedMenu: {current:string};
  
  constructor(private location:Location)
  {
    this.selectedMenu = {current: location.path()};
  }
}

Ніхто не в курсі як це вирішити?

$location.url().indexOf(’___yourUrlSubPathIsHere___’)
?

Такі підказки годяться для недоджуніорів...

посипаю голову попелом і повзу у свою нору, щоб здохнути подалі від людських очей :)

там есть встроенная директива RouterLink, которая в том числе умеет определять активную ссылку.

Либо же вот здесь есть небольшое обсуждения вариантов.

На стековерфлоу показано саме той приклад, який у мене є на даний момент

<li [class.active]="somethingThatReturnsTrueOrFalse()"><a [routerLink]="['/About']" class="link">About</a></li>

Але оцей вираз чи функція somethingThatReturnsTrueOrFalse оцінюється при ініціалізації/завантаженні сторінки. Це працює добре, як і очікується, але при переходах по іншим сторінкам повторної оцінки не буде.

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

В чому саме ви бачите костиль? На сторінці документації показано одну із частин даного прикладу

<a [routerLink]="['./User']">link to user component</a>

Ця частина так само десь точно є в документації

<div [class.active]="TrueOrFalse"></div>

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

Жесть, виявляється, що таки функція somethingThatReturnsTrueOrFalse() буде викликатись при кожному переході, причому по «сотні раз». Вже ж начебто digest прибирали, чи ні? Мабуть просто замінили digest на рідний для ES6 механізм виявлення змін...

Невже вони приблизно в рівній мірі перспективні, і не можна вибрати серед них фаворита?...
ну так если по умолчанию предлагается
AngularJS 2 for TypeScript (by default)
то наверное его считают за основную реализацию.
да и я по тем видюхам с ютуба, посвященных 2-му ангуляру, что видел, я так понял, что его пилят на TypeScript-е как раз.

В нете можно поискать несколько готовых boilerplate-ов с вторым ангуляром. Там уже готовые скрипты для галпа или вебпака + примеры. Что касается производительности, то можно, например, наглядно можно на примерах с большими таблицами. Когда я тестил его был на порядок быстрее первого ангуляра, а так же быстрее реакта.

Из минусов для меня это TS/ES6, т.к. я не особый почитатеь синтаксического сахара из того же ES6. Но это субъективная причина.

как можно не влюбиться в деструктуризацию и дефолтные значения? :)

Влюбиться можно очень легко, да вот только эта любовь разбивается о суровые реалии действительности поддержки движками этих самых фич :(. Да и порой посредники типа бабеля и прочих не радуют вовсе:
kpdecker.github.io/six-speed

Тестувати швидкість збираюсь на пару тисячах тестових true-деревовидних коментарях...

Так, між іншим, вже перший AngularJS справляється значно краще із рендером таких коментарів, в порівнянні з коментарями на ДОУ...

Дело вкуса, конечно. Но скоро ES6 станет стандартом в разработке (если уже не стал). Так что все равно прийдется переходить. С непривычки может отпугнуть, но — из личного опыта — поработав с ним пару дней и уяснив нюансы, больше не хочется возвращаться к старому синтаксису. И те же webpack+babel творят чудеса.

На счет «скоро» — далеко не факт. Чтобы он стал стандартом надо как минимум чтобы на фронте был достаточный процент браузеров, поддреживающих его, а на бекенде, чтобы он по производительности хотя бы сравнялся с тем, что есть сейчас. А пока что «webpack+babel» творят только замедление производительности.

Не заметил я что-то ощутимого замедления производительности. Там не такая большая обертка. А если там что-то и проседает, то для большинства задач это абсолютно не критично. Экономия на спичках. А учитывая это, нет причин не писать на ES6.

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

Не могу спорить с этим. Поэтому я и написал «для большинства». Но большинство как раз определяет стандарт.

Это вы просто не работали с рельными высоконагруженными проектами.
а какая именно из фич у вас приводила к критическим тормозам сама по себе?
просто интересно.

Они все в целом приводили к тормозам. Отдельно каждую мы не меряли. Но в коде, который тестировался было многое: начиная от упомянутых вами деструктуризации и дефолтных значений до простого испольхования let/const вместо var. Так же весьма печально обстояли дела с литералами объектов, когда в них использовались переменные.

Если вам интересна статистика по каждой фиче, то выше я приводил линку на бенчмарки. Они +/- совпадают с тем, что поулчилось у нас.

Если вам интересна статистика по каждой фиче
в том-то и дело, что нет.
у меня не редко были тормоза из-за неоптимально написанного кода. в ES5.
потому мне и интересно было услышать кейс, когда, скажем, критично пятикратное замедление от использования for-of конструкции.
случаи из жизни, так сказать.

Если случай из жизни, то пример — роутер на бэкэнде, через кототрый проходят все запросы. Если в его функциях использовать хотя бы только дефолтные значения, то производительность req/s падает заметно, использование let/const добавляет сверху еще. Если брать пример для фронта, то это можно увидеть на задаче с построением графиков по не совсем простому жсону.

думаю со временем это исправят, новый стандарт как никак, команде В8 еще оптимизировать и оптимизировать

ощущение были что дока ужос!!
а так стало на фреймворк похоже, а не на подделку студентов какихто

Они же вроде пишут на TS, а потом остальные все версии просто компилируют. Так что если у вас проект на dart — используйте AngularJS 2 for Dart, а если чистый js — то для JavaScript соответственно.

Подписаться на комментарии