Вы чересчур обобщили. Эта фраза имеет смысл в контексте ng-repeat, а не в целом по отношению к scope-иерархиям. И проблемой обычно является в связке с ng-model. Как там в примере и приведено.
Но ваш изначальный пример был про getter-свойство. Вы там память что ли экономили?
Scope inheritance is normally straightforward, and you often don't even need to know it is happening… until you try 2-way data binding (i.e., form elements, ng-model) to a primitive (e.g., number, string, boolean) defined on the parent scope from inside the child scope. It doesn't work the way most people expect it should work. What happens is that the child scope gets its own property that hides/shadows the parent property of the same name.
За этим, казалось бы, маленьким пунктом на последнем месте:
Пользуйтесь параметром track by в директиве ng-repeat. Во первых это быстрее, а во вторых убережет от ошибки duplicates in a repeater are not allowed, которая возникает, когда мы пытаемся вывести одинаковые объекты в списке.
скрывается чуть ли не самая распространенная проблема тормозов AngularJS.
Упереться в количество биндингов — это еще постараться надо.
А вот пересоздавать изрядный кусок DOM на каждый чих у людей получается достаточно часто, чем многие бенчмарки от людей, не очень знакомых с AngularJS, и страдают.
Ваша позиция понятна, для вас HTML — это нечто нерасширяемое, предназначенное только для отображения страницы. У вас не страница является приложением, а приложение генерирует страницу.
Каждому свое, просто разные подходы. Время покажет, какой выживет :)
А что такое «засранный DOM» и «внятный шаблонизатор» (в частности слово «внятный» в данном контексте не очень понятно)?
HTML по своей сути декларативен, если вам это не нравится, а также вы не приемлете подхода AngularJS по расширению HTML и созданию своего DSL для приложения, то очень странно, что вы его хоть для чего-то выбрали.
Ясно, спасибо. Просто постоянно тиражировалось мнение, что Dart добавят как-только Oilpan будет полностью завершен.
Под вторым вопросом я имел в виду — в виде плагина, или еще какой-либо простой путь доустановки Dart-а в уже существующую стандартную установку Chrome. Ладно, время покажет.
mraleph, Вы не знаете, эта новость как-то связана с Oilpan? Dart не будут интегрировать в стандартной сборке, но другие варианты какие-нибудь останутся (за исключением Dartium)?
Основные киты Ангуляра — декларативность, DI, тестируемость. В этом плане ничего не меняется. Что-то просто становится гибче, что-то жестче, меняется API. Если вы старались в своем приложении побольше думать о декомпозиции, повторном использовании и явном интерфейсе взаимодействия между различными частями приложения, то переход будет не настолько сложен, а уж концептуально ничего не поменяется, так только, синтаксически…
Они не заявляли, что пути миграции не будет, они заявляли, что пока нет чего-то хотя бы близкого к финальной версии по API, нет смысла составлять какие-либо планы миграции.
И уже сейчас, чем больше в приложении будет использоваться компонентный подход (любая страница, ее часть или повторно используемый виджет — это директива с изолированным scope), тем проще потом будет переход. Подобный подход и в текущей версии хорош, потому что позволяет явно прописать интерфейс взаимодействия между родительскими и вложенными состояниями/страницами/виджетами и т.п.
«На фундаментальном уровне, Angular считает, что вы используете stateless „сервис“-объекты для логики и простые объекты для структур данных (объекты без методов) для сохранения состояния. Сервисы по сути — глобальные переменные; большинство функций могут использовать любой сервис, обращаясь к ним по особому имени. Структуры данных хранятся в $scope, они связаны с шаблонами и директивами. Объекты структур данных управляются „контроллерами“ („клей“, связанный с шаблонами и директивами) и сервисами.»
Вы зачем это в дополнительные кавычки взяли? Я уж испугался, что автор обзора это откуда-то цитирует и что это из документации AngularJS.
Извините, невнимательно вслушался, там сначала говорится, что все ок, потом под конец что-то возникает. Вдвойне интересно было бы глянуть на исходники. 100 строк — это обыкновенный кейс, на котором я проблем у нас даже на мобильных платформах не получал.
POJO не проверит валидность данных (ловить ошибки вы будете не в том месте, где они совершены).
Надо будет — проверит, не надо — не проверит. Как напишешь. Валидность я буду проверять в первую очередь в момент ввода.
POJO не сообщит об отсутствующем поле (просто вернёт undefined)
Об этом мне сообщат тесты.
После изменения POJO нужно не забывать вызывать $digest для всех зависимых от него скоупов.
Вы тут что-то странное написали. Во-первых, после изменения извне контекста AngularJS — не такое уж частое явление. Во-вторых, вы так написал, как-будто там чуть ли не вручную надо зависимости прописать и каждый раз что-то по-разному вызывать.
Но ваш изначальный пример был про getter-свойство. Вы там память что ли экономили?
Что, куда и когда копируется?
скрывается чуть ли не самая распространенная проблема тормозов AngularJS.
Упереться в количество биндингов — это еще постараться надо.
А вот пересоздавать изрядный кусок DOM на каждый чих у людей получается достаточно часто, чем многие бенчмарки от людей, не очень знакомых с AngularJS, и страдают.
Подробнее в этих ветках:
habrahabr.ru/post/246905/#comment_8207725
habrahabr.ru/post/246905/#comment_8262489
Каждому свое, просто разные подходы. Время покажет, какой выживет :)
HTML по своей сути декларативен, если вам это не нравится, а также вы не приемлете подхода AngularJS по расширению HTML и созданию своего DSL для приложения, то очень странно, что вы его хоть для чего-то выбрали.
Под вторым вопросом я имел в виду — в виде плагина, или еще какой-либо простой путь доустановки Dart-а в уже существующую стандартную установку Chrome. Ладно, время покажет.
И уже сейчас, чем больше в приложении будет использоваться компонентный подход (любая страница, ее часть или повторно используемый виджет — это директива с изолированным scope), тем проще потом будет переход. Подобный подход и в текущей версии хорош, потому что позволяет явно прописать интерфейс взаимодействия между родительскими и вложенными состояниями/страницами/виджетами и т.п.
В этом случае у вас висло все из-за постоянного удаления/добавления большого количества DOM-а. У вас не обновлялись, а пересоздавались элементы.
Вы зачем это в дополнительные кавычки взяли? Я уж испугался, что автор обзора это откуда-то цитирует и что это из документации AngularJS.
Я просто подумал, что Вы случайно ссылку попутали. С AngularJS, действительно, непринципиальное отличие.
Вам впору топик писать по особенностям производительности AngularJS и React :)
Никогда бы не подумал, что они на этой задаче наравне будут.
Надо будет — проверит, не надо — не проверит. Как напишешь. Валидность я буду проверять в первую очередь в момент ввода.
Об этом мне сообщат тесты.
Вы тут что-то странное написали. Во-первых, после изменения извне контекста AngularJS — не такое уж частое явление. Во-вторых, вы так написал, как-будто там чуть ли не вручную надо зависимости прописать и каждый раз что-то по-разному вызывать.