Comments 28
На tutorial не тянет ((
Не соглашусь — на том уровне, на котором идёт речь — вполне доходчиво и ярко расписано. Картинку. правда, можно под спойлер, потому что не у всех на работе стоит адблокер.)
Контрольный вопрос к туториалу:
(Вот таких тройки вопросов после статьи, в самом деле, не хватает, но и за один пример автору спасибо )).
Контрольный вопрос к туториалу:
- Взяли Backbone, который реализует MVP и добавили к нему плагин, который реализует двустороннее декларативное связывание данных — Backbone.ModelBinding. Вопрос: станет ли этот комплект достаточным для того, чтобы проект считался MVVM? Что надо написать в подтверждение? (Для полной постановки тут целый проект надо придумать.)
(Вот таких тройки вопросов после статьи, в самом деле, не хватает, но и за один пример автору спасибо )).
Конечно, есть такая штука как Object.observe(), но эта вещь, пока еще, не является частью стандарта.Или уже, т.к. автор фичи в прошлом году грозился её закрыть и вырезать её из хрома.
Например, для text input вешается слушатель на событие keyup.Используется событие «input» (keyup может применяться для поддержки IE6, хотя ангуляр с ним не дружит)
что $timeout ждет, пока закончится текущий $digest-цикл, затем выполняет кодТут используется setTimeout, он уже и вызывает код когда другой код не выполняется (один поток же)
Что такое $digest-цикл?Скорее между ViewModel и View, но все равно это частный случай, $digest-цикл — это процесс поиска изменений (dirty-checking) данных и вызов подписчиков (обработчиков). А что они будут синхронизировать (или не будут) это уже дело десятое.
В AngularJS это как раз и есть процесс синхронизации значений между Model и View.
Object.observe отменили в пользу Proxy, на которых можно реализовать то же самое.
Согласен. Но, опять же, пока что это не входит в утвержденный стандарт ;)
Только в ES6.
На данный момент, ES6 поддерживается ох как не везде )
На данный момент, ES6 поддерживается ох как не везде )
Даже последний хром(не Canary) ничего не знает про Proxy
Ну так мы и говорим про стандарт. Object.observe выкинули, потому что есть Proxy. Proxy есть в ES6. ES6 — утвержденный стандарт. Таким образом, утверждение «Но, опять же, пока что это не входит в утвержденный стандарт ;)» не соответствует истине.
Да, извиняюсь. Перефразирую: Proxy входит в утвержденный стандарт ES6. Но сам ES6, судя по http://kangax.github.io/compat-table/es6/, полностью нигде не поддерживается
Не совсем тоже самое, у каждого свои минусы, когда O.O работает с самим объектом, с Proxy вам придется работать с proxy интсансом, а не исходным объектом. В итоге если вам нужно отслеживать изменения в объекте который вам прислали из вне, вам нужно сделать для него proxy обертку и как то передать обратно (т.е. источник должен это поддерживать), с О.О такой проблемы нет.
Ну народ как-то вроде полифиллит O.o на Proxy.
Посмотрел 2 первых попавшихся O.O полифила, один сделан через defineProperty + setTimeout, второй просто через setTimeout.
Где вы видели полифил на Proxy?
Где вы видели полифил на Proxy?
https://www.npmjs.com/search?q=object.observe, второй пакет сверху.
3. The variables pointing to objects that are being observed must be re-assigned to point to a proxy returned by the call to Object.observe, e.g.Про что я выше и написал, что придется работать с proxy оберткой, а не с исходным объектом.
вам нужно сделать для него proxy обертку и как то передать обратно
Да я, собственно и не отрицал.
Суть-то в том, что можно реактивно реагировать на изменения в объекте. А уж как это реализовано — все равно, лишь бы не как в ангуляре:)
Суть-то в том, что можно реактивно реагировать на изменения в объекте. А уж как это реализовано — все равно, лишь бы не как в ангуляре:)
можно реактивно реагировать на изменения в объектеМногие фреймворки всю реактивность складывают в «беклог» и по таймауту (либо nextTick) вызывают обработчики (это «защищает» при множественном изменении одной переменной), кстати O.O как раз по дефолту так и работает, так что «немедленная» реактивность не так уж и нужна.
все равно, лишь бы не как в ангуляре:)Подход ангуляра не так уж и плох (есть свои плюсы), при том что это один из самых быстрых методов для большинства UI (см. бенчмарки).
В чем проблема реализации ангуляра?
P.S. Реактивное программирование — это совсем другое. Так, к слову.
P.S. Реактивное программирование — это совсем другое. Так, к слову.
lega
В целом — да, согласен.
В итоге — да. Но судя по исходникам, последовательность получается такая:
Опять же судя по исходникам, $apply(), помимо прочего, пытается запустить $digest
всё верно ;)
Используется событие «input» (keyup может применяться для поддержки IE6, хотя ангуляр с ним не дружит)
В целом — да, согласен.
Тут используется setTimeout, он уже и вызывает код когда другой код не выполняется (один поток же)
В итоге — да. Но судя по исходникам, последовательность получается такая:
- ждет, пока закончится текущий потом выполнения ($browser.defer — это суть setTimeout)
- выполняет наш код
- вызывает $rootScope.$apply()
Опять же судя по исходникам, $apply(), помимо прочего, пытается запустить $digest
Скорее между ViewModel и View, но все равно это частный случай, $digest-цикл — это процесс поиска изменений (dirty-checking) данных и вызов подписчиков (обработчиков). А что они будут синхронизировать (или не будут) это уже дело десятое.
всё верно ;)
Кто ангуляр используется знает что лучше вызвать scope.$digest чем $apply если известно что изменения касаются только конкретного scope. То есть запускается обычный таймаут вместо $timeout и потом внутри scope.$digest. А есть еще $evalAsync метод.
UFO just landed and posted this here
MVP, MVVM… Еще несколько лет назад это называлось MVC with data bindings!
Sign up to leave a comment.
Динамическое связывание данных в HTML и JS