Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 53
Мне кажется надо срочно сменить название, а то холивар по поводу обратной совместимости неминуем. По сути, практически новый продукт — зачем ему терять разочарованных предыдущими версиями.
Вообще разработчики уже озаботились вопросом миграции, хотя сначала заявили, что пути не будет вовсе. Вот доклад от Michał Gołębiowski о миграции, а следующие версии 1.х планируются, как некий мост до версии 2.0, например, в 1.4 портировали новый роутер.
Но, конечно, реальности это не меняет, для перехода с 1.х на 2.0 придётся переписать приложение полностью. Но тут надо задаться вопросом целесообразности, версию 1.х будут поддерживать ещё долго, пока не упадёт посещаемость angularjs.org. А если уперлись в производительность- можно, на крайний случай, запустить в приложении оба ангуляра разом и заменить только узкие места, как некоторые сейчас делают с React.js
Но, конечно, реальности это не меняет, для перехода с 1.х на 2.0 придётся переписать приложение полностью. Но тут надо задаться вопросом целесообразности, версию 1.х будут поддерживать ещё долго, пока не упадёт посещаемость angularjs.org. А если уперлись в производительность- можно, на крайний случай, запустить в приложении оба ангуляра разом и заменить только узкие места, как некоторые сейчас делают с React.js
Они не заявляли, что пути миграции не будет, они заявляли, что пока нет чего-то хотя бы близкого к финальной версии по API, нет смысла составлять какие-либо планы миграции.
И уже сейчас, чем больше в приложении будет использоваться компонентный подход (любая страница, ее часть или повторно используемый виджет — это директива с изолированным scope), тем проще потом будет переход. Подобный подход и в текущей версии хорош, потому что позволяет явно прописать интерфейс взаимодействия между родительскими и вложенными состояниями/страницами/виджетами и т.п.
И уже сейчас, чем больше в приложении будет использоваться компонентный подход (любая страница, ее часть или повторно используемый виджет — это директива с изолированным scope), тем проще потом будет переход. Подобный подход и в текущей версии хорош, потому что позволяет явно прописать интерфейс взаимодействия между родительскими и вложенными состояниями/страницами/виджетами и т.п.
Этот html-код не пройдёт валидацию.
Пройдет.
Запихал в validator.w3.org, не прошел.
Ну, можете добавить все эти flex и т.д. через data-* атрибуты и все будет хорошо. Более того, есть решения для gulp/grunt для автоматизации этого, хоть я и не вижу в этом смысла.
Что-то я с утра туплю.
Вы пытались темплейт провалидировать или что? Мне кажется что это не правильно как-то.
Вы пытались темплейт провалидировать или что? Мне кажется что это не правильно как-то.
Создатель ангуляра Misko Hevery утверждает, что это вполне валидный html код и в доказательство приводит этот пункт спецификации html, но если Вас интересует какой-то определённый валидатор допускается вместо [value] можно будет писать bind-value или data-bind-value.
Лучший валидатор — браузер. ©
<!-- meta name="GENERATOR" content="Microsoft FrontPage 1.0" -->
Это выглядит не менее страшненько, чем версия 1 — просто здесь свои причандалы.
Кажется, усложнять вещи, которые могут и должны быть простыми — отличительная черта разработчиков ангуляра.
Кажется, усложнять вещи, которые могут и должны быть простыми — отличительная черта разработчиков ангуляра.
Можете рассказать, что тут для вас «усложнение»?
[class.md-checked]="item.checked"
(click)="item.toggleCheck()"
[item]="item"
#newitem
*foreach="#item in store.items"
Вот это всё — рак мозга. Есть ощущение, что им (разработчикам) скоро перестанет хватать спецсимволов.
Плюс, import из ES6 насколько я понимаю не умеет работать с конкатенированными файлами.
Т.е. если у вас на странице 100 компонентов, то у вас будет как минимум 100 запросов к серверу.
Любой фреймворк будет подразумевать под собой определённый набор своих «причиндалов», которые требуют изучения. По поводу версии 1.х я ещё могу согласиться, что синтаксис несколько громоздкий(из-за специфики ES5), но новый синтаксис мне кажется куда более изящным и выразительным + теперь IDE сможет Вам помогать при разработке благодаря типизации.
Внутри arrow-function сохраняется родительский контекст.
ES2015 в текущей версии ангуляра можно использовать совершенно без проблем. Вот пример кода из текущего проекта.
load() {
this.items=[];
- let that=this;
let itemsStr=window.localStorage['todoItems'];
if(itemsStr) {
JSON.parse(itemsStr).forEach((e) => {
- that.addItem(e.name, e.checked);
+ this.addItem(e.name, e.checked);
});
}
}
ES2015 в текущей версии ангуляра можно использовать совершенно без проблем. Вот пример кода из текущего проекта.
class CityController {
static $inject = ['$routeParams', 'CityApi'];
constructor(params, api) {
this.api = api;
this.load(params.city);
}
load(id) {
this.api.get(id).success((city) => {
this.city = city;
});
}
}
module.exports = CityController;
Внутри arrow-function сохраняется родительский контекст.
Большое спасибо, не знал, поправил код в статье.
static $inject = ['$routeParams', 'CityApi'];
К сожалению, этого в ES2015 нет, property initializers пока только предлагаются к добавлению в ES7. Хотя никто нам не мешает их использовать с препроцессорами :)
Я сильно сомневаюсь, что где-то, кроме node/io.js можно будет использовать нативный ES6 в 2015-16 годах. А значит в любом случае прийдется использовать препроцессоры. А раз так, давайте делать это на полную катушку.
Ну и пока это в babel не добавили, я использовал
Ну и пока это в babel не добавили, я использовал
static get $inject() {
return ['$routeParams', 'CityApi'];
}
Ну так в babel в ближайшее время (в зависимости от результатов собрания TC39, что будет на следующей неделе) могут появиться и декораторы.
А я надеялся в реальном проекте использовать angular 2, но как написано в статье без костылей он работать не будет.
Действительно новый ангулар не нимеет ничего общего со старым по сути название angular это просто маркетинговый ход для популизации нового продукта. Развитие настоящего angulara уже больше не будет.
Действительно новый ангулар не нимеет ничего общего со старым по сути название angular это просто маркетинговый ход для популизации нового продукта. Развитие настоящего angulara уже больше не будет.
Пока не время его использовать, это ранняя-ранняя альфа, чтобы оценить идеи, заложенные в его основу и подготовить нынешние проекты к менее безболезненной миграции. И Вы не совсем правы, ветка 1.х будет не только поддерживаться, но и развиваться ещё довольно долго.
Почему маркетинговый ход? Мажорная версия, мажорные изменения. В крупных проектах такое происходит. Из известных мне — symfony 1 и 2, bootstrap 2 и 3, php 4 и 5. Во всех этих проектах есть обратно не совместимые изменения.
Ангуляр как был фреймворком с DI, контроллерами и директивами, так он им и остался. Да, поменялось API, но мир не стоит на месте, особенно в фронтенде.
Ангуляр как был фреймворком с DI, контроллерами и директивами, так он им и остался. Да, поменялось API, но мир не стоит на месте, особенно в фронтенде.
Поддерживаю. Symfony2 вообще практически другой фреймворк по сравнению с первой версией, кстати.
И тоже компонентная база и аннотации.
Гм. То, что фреймворк использует «компоненты» и «аннотации» не является его отличительной особенностью, мне кажется. Сейчас большое количество библиотек состоит из компонентов и использует аннотации
В PHP комьюнити Symfony2 был первым фреймворком в этом плане. И упомянут он тут из-за аналогии, монолитный Symfony1 и компонентный Symfony2 + аннотации. Совсем как у ангуляра.
Мне казалось, скажем, Zend Framework 1 тоже состоял из компонентов. Разве нет? Конечно, зависимости там посерьезнее, чем у Symfony, но тем не менее. То, что он поставляется монолитно и отдельный компонент не установить через Composer, не означает, что архитектурно он монолитен.
Zend1 был набором библиотек. Как и Symfony1. Использовать большую часть из них вне Zend или Symfony не реально. Разница в том что в случае с Zend2 или Symony2 можно взять пачку компонентов и собрать свой фреймворк. Та же разница и в angular. Можно взять компоненты, какие-то заменить другими и получить свой фреймворк адаптированный под нужды разработки.
Основные киты Ангуляра — декларативность, DI, тестируемость. В этом плане ничего не меняется. Что-то просто становится гибче, что-то жестче, меняется API. Если вы старались в своем приложении побольше думать о декомпозиции, повторном использовании и явном интерфейсе взаимодействия между различными частями приложения, то переход будет не настолько сложен, а уж концептуально ничего не поменяется, так только, синтаксически…
2-way-binding была одной из базовых фич Angular, теперь ее нет, так что не только сахар.
Ну посмотрим, что они там с формами в конце концов сделают. А то может оказаться, что под 2-way-binding каждый понимал что-то немного свое :)
Скорее change detection а не дата биндинг. Теперь этот функционал предоставляет отдельный компонент — watchtower.js. Все хорошо.
watchtower.jsКстати где на него посмотреть? А то github.com/angular/watchtower.js заброшен почти год назад, а в основном репозитарии я не нашел упоминания о watchtower.
github.com/angular/angular/tree/master/modules/angular2/src/change_detection я правда пока не понимаю как они собираются вести разработку. Делать сплит на несколько модулей?
Любопытно, если они перейдут на typescript и его генерацию модулей — что они будут делать с циклическими зависимостями? Typescript создает модули CommonJS (или, реже, AMD), в которых если модуль A делает require модуля B, а модуль B с свою очередь делает require модуля A — то с удивлением получит вместо него пустой объект. В node.js для борьбы с этой неприятностью пишут «module.exports = » в начале с последующей инициализацией, но typescript-то так не делает и делать, судя по всему, не планирует.
Свойство componentServices – это список классов для инъектора.
Хочу дополнить, при добавлении создается экземпляр классов из этого списка. Так же есть список services, который позволяет инъектировать(странно звучит на русском) в дочерние элементы.
Для изучения так же рекоммендую примеры hello world и todo от авторов фреймворка. Забавный факт, при открытии hello world, браузер создает 110 запросов и в сумме скачивает более мегабайта. Это самый тяжелый hello world, который я видел (:
Изучая сборку и запуск angular2, создал github.com/htdt/ng2-jspm (без es6-shim через jspm).
инъектировать — внедрять.
Ну так, оно ж не оптимизировано. Если грузить через spdy/http2 проблем с этим не особо много.
браузер создает 110 запросов и в сумме скачивает более мегабайта
Ну так, оно ж не оптимизировано. Если грузить через spdy/http2 проблем с этим не особо много.
Точно, «внедрять» лучше. Полагаю к релизу они сделают сборщик. Кстати, по ссылке выше jspm собирает проект, сокращая до 3 запросов и 344кб (не мало и не стабильно, для изучения, не для продакшена).
добавить к этому uglify или closure compiler, gzip и уже можно жить. По поводу сборки — есть es6-module-transpiler который может собрать все в красивый бандл, без всяких зависимостей в виде require.js или jspm. Единственное что смущает — как это все будет работать с typescript, хотя думаю проблем не будет.
Fesor, а ты не встречал гайдов как приготовить эту альфу с webpack-ом?
И обязательно ли связываться с traceur'ом чтобы всю эту кухню запустить или они его используют потому что гугл?
А то я тоже последнее время на бабеле с webpack, хотелось бы как-то в этой среде все это запустить для «попробовать».
И обязательно ли связываться с traceur'ом чтобы всю эту кухню запустить или они его используют потому что гугл?
А то я тоже последнее время на бабеле с webpack, хотелось бы как-то в этой среде все это запустить для «попробовать».
Кто-нибудь знает примерную дату выхода релизной версии angular 2?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Angular 2.0.0-alpha для тех, кто не в силах ждать