Ну вот например вью-модель задачи в списке задач: https://github.com/nin-jin/pms-jin/b...ew_item.jam.js

У него есть свойство current - флаг указывающий, что этот таск сейчас выделен.

Объявляем мы его просто:

$jin.atom.prop({ '$jin.task.view.item..current':
{   pull: function( ){
		return this.list().task() === this.task()
	}
}})

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

ui поддерживает frp :D

Ты так и не рассказал каким образом)

function Controller() {

    a = 10
    b = 20
    c = (a + b)  // 30

    say = function() {
      a++;
      alert( c ) // 31
    }

}

и вообще-то я рассказал, это называется формулы. я же писал в том топике. с это ячейка которая связана с ячейками a и b по формуле a+b


или вот например, ячейка form динамичски пересчитывается при обращении к ней. и выдает заполненный обьект.

function Controller() {

    name = 'Ашот'
    age = 11

    form = ({
      name: name,
      age : age
    })

    sendForm = function() {
      $http( 'api.php?sendForm', form )
    }

}

А, ну это твой собствнный язык. Он хоть тьюринг-полный?)

не сказал бы что это язык) обычные "сниппеты") это можно записать и руками

function Controller() {

    var $$self = this;

    $$self.a = 10
    $$self.b = 20
    $cell( 'c', function() { return $$self.a + $$self.b } )

}

скобочки это просто небольшой сахар) и кстати, я не понял как утверждение "это твой язык" опровергает поддержку FRP? Ведь оно ПОДТВЕРЖДАЕТ поддержку FRP. Я добавил сахарный способ создания формул, и способ этот похож на синтаксис клажуры.

Ой, да у тебя дигест как в ангуляре.. смерть на больших данных)

ну не знай, 5000 ватчеров проверяет 20 миллисекунд на пеньке 4) а вот то что смерть это лишь твоя диванная теория, неболее)

п.с. дайджест блять, дайджест)

а что ты предлагаешь? и приведи пример смерти на больших данных

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

Допустим, задача: есть список на 50000 задач. Задачи имеют название, описание, статус, список ответственных пользователей, запланированную дату, приоритет. Нужно сортировать по алфавиту, по дате с группировками (на сегодня, на этой неделе, просроченные) и (по приоритетам плюс завершенные - самый низкий приоритет). Любой параметр задачи можно в любой момент изменить и задача должна перелетать на правильное место в списке.

Будет от 200мс на каждый чих?)

да, но таких список обычно не бывает по этому это не страшно.
или бывает? я напомню что перелопачивается только то, что собирается рисоваться в html. у тебя и вручную созданные 50000 дивов будут тупить.
По этому это не проблема. На списках размером 1000-2000 перелопачивание не заметно для пользователя. Оно дольше чем в нокаутах но все таки не заметно, так что не страшно. Разумеется в будущем я думаю оптимизировать это, ну так, чтобы приятно было мне. Сделаю полифил для Object.observe геттерами и сеттерами. и буду использовать его за место $digest.

пока такой способ перелопачивания я нахоэу проиемлемым так как в реальности не бывает случаев когда надо перелопатить больше 5000 элементов массива, и такое перелопачивание занимает меньше 10 миллисекунд на моем слабом компьютере pentium 4