| Mаxmaxmаximus | 29.10.2015 23:02 |
UIjs Альфа 1
Я тут ребят подумал и решил что до юишка будет рендеровой частью изоморфного фреймворка Mega.js по этому она должна уметь рендерить в строку, а для этого ей нужно работать не с реальным дом а с виртуальным. У меня сейчас ассинхронный датабиндинг, что позволяет рисовать огромные коллекции в миллион элементов ассинхронно не тормозя интерфейс, но если бы у меня был виртуальный дом то я например мог бы отрисовать миллион виртуальных элементов а фреймворк бы это учел и понял что браузер столько не потянет и нарисовал бы допустим только тычячу, и вставил бы 2 распорки сверху и снизу, которым бы задал огромную высоту, а когда человек скроллил бы то виртуал дом подрендеривал бы нужное меняя размеры распорок. в общем эти вещи если делать сейчас руками то это мозг взорвется, даже сейчас у меня рендеринг на промисах и их там около квадрилиона создается и код репитера похож на лапшу, приходится учитывать нарисовался уже элемент или еще нет и.т.п. а хочется просто отрисовать типа миллион виртуальных дом элементов а движок уж пусть там сам думает как это нарисовать, я уже молчу что при такой архитекторе он сможет отрендерить все это В СТРОКУ (а значит можно использовать на сервере nodejs в качестве пререндера что круто для поисковиков)
В общем вот текущая архитектура:
А вот рендер 100к элементов, попробуйте писать в инпат во время рендера, ничего не тормозит
Минус такой архитектуры в том что мы упираемся в браузер, когда количество физических элементов хододит до 50 тысяч браузер начинает тормозить при их вставке. И мы с этим ничего не можем поделать. Но нет смысла рисовать физически все элементы если можно вставить див распорку например которая бы высоту тупо давала для скроллбаров и.т.п. Я к тому что то что на экране нужно рисовать, а то что за пределами экрана не нужно, и если у нас есть виртуальный дом то мы можем все это контролировать. Вот какую архитектуру я буду делать для воторй альфы:
Чем это отличается от реакта? Ну тем что в реакте у нас датабиндинг ручной, нам руками приходится генерировать шаблоны из виртуальных дом в функции render. А у меня действуют все те же "директивы" ангуляра, которые внутри себя ЗНАЮТ как надо лучше биндинг сделать, например репитер делает аррей обсерв (я временно полифил подключил, потом кусок из него встрою). И он знает какие элементы изменились и удалились и тиолько их он изменит в виртуал дом, и это лучше чем реактовский бредовый render который нам ЗАНОГО создаст весь миллиард элементов, пусть и виртуальных.
А вот мой туду лист до завершения первой альфы:
всякие валидаторы на data-model всякие классы там добавлять
при верных данных не верных данных всякое такое прочее, сделать
удобным для использования в кастомных инпатах и сделать удобным
для наследования
внедрить виртуальный дом чтобы не было ни промисов ничего,
я работал бы с виртуальными дом обьектами мгновенно, и без промисов
а виртуал дом бы сам решал когда их отрендерить физически.
если несколько одноименных компонентов конструируются на разных уровнях
одного элемента, то при @require() они перекрывают друг друга,
а должны быть каждый на своем... в общем решить эту неопределенность
суспендить еще и события внутри слипинг скоупов
сделать style-prop поддерживающими вендорные префиксы если они есть
SelectionSaver не работает в opera 12
доработать параметры сервиса http такие как таймаут и контент тайп
mouseenter mouseleave не работает в интернет експлорер)
on-wheel не работает в opera 12 (только on-mousewheel)
добавить многим ассинхронным сервисам опцию отключения
сохранения Async контекста, которая по умолчанию должна быть включена.
Так как многие ассинхронные сервисы, например анимейшенФрейм или
Промисы, используются в ядре, и ассинхронка там не нужна и работает
не корректно, так как это абстракция пользовательского левла.
сделать мерджевые атрибуты еще и датабиндинговыми,
чтобы несколько разных датабиндингов с ранных левлов
компонента срабатывали на одном атрибуте и значения рисовали
рядом через пробел. как мердж атрибутов, только динамический.
сделать нормальную передачу ассинхронки в промисах,
ибо теряется ассинхронный контекст в функциях переданных в then
и вообще решить делать лиасинхронку в промисах, они ж
горячее место в коде теперь ;)
А вот мой лист на сегодня:
сделать анимации в data-if
сделать анимации в data-repeat
доделать data-repeat
настроить чтобы таймер троттлинга очищался по завершению рендеринга
А еще у меня всякие наследования компонентов, шаблонов и контроллеров, автоматическая очистка мусора, виртуальная файловая система и модульность, даже кофескрипт в {{выражениях}} есть, а так же блекджек и немного шлюх ;)
А о том что БУДЕТ это я уже молчу, там такие нанотехнологии будут что людям и не снились) особенно мне нравится шеред контролелры которые между вкладами работают, и возможност нарисовать триллион значений из базы данных, при том не думая будет оно тормозить или нет) ну это уже в Mega скорее а не в юишке)
п.с. привет матрешка))))))) как там твои сеттеры)?
В общем вот текущая архитектура:
А вот рендер 100к элементов, попробуйте писать в инпат во время рендера, ничего не тормозит
<script src='//uijs.ru/ui.js'></script>
<script src='//uijs.ru/observe.js'></script>
<script>
ui.controller('User', function(){
function createArr(length){
var arr = []
while(length--) arr.push(Math.random());
return arr
}
return {
arr: createArr(100000),
change: function(){
this.arr[2] = 'ЗАМЕНА ' + Math.random()
},
add: function(){
this.arr.unshift( 'ВСТАВКА ' + Math.random() )
}
}
})
</script>
<div>{{text}}</div>
<input data-model='text' placeholder='Печатай тут пока оно рендерится'>
<hr>
Можно даже <button on-click='User.change()'>изменить</button> или <button on-click='User.add()'>добавить</button> в массив во время рендера и создастся второй поток рендера, у которого приоритет выше потому что изменений меньше ;)
<ul>
<li data-repeat='val in User.arr'>{{val}}</li>
</ul>
Минус такой архитектуры в том что мы упираемся в браузер, когда количество физических элементов хододит до 50 тысяч браузер начинает тормозить при их вставке. И мы с этим ничего не можем поделать. Но нет смысла рисовать физически все элементы если можно вставить див распорку например которая бы высоту тупо давала для скроллбаров и.т.п. Я к тому что то что на экране нужно рисовать, а то что за пределами экрана не нужно, и если у нас есть виртуальный дом то мы можем все это контролировать. Вот какую архитектуру я буду делать для воторй альфы:
Чем это отличается от реакта? Ну тем что в реакте у нас датабиндинг ручной, нам руками приходится генерировать шаблоны из виртуальных дом в функции render. А у меня действуют все те же "директивы" ангуляра, которые внутри себя ЗНАЮТ как надо лучше биндинг сделать, например репитер делает аррей обсерв (я временно полифил подключил, потом кусок из него встрою). И он знает какие элементы изменились и удалились и тиолько их он изменит в виртуал дом, и это лучше чем реактовский бредовый render который нам ЗАНОГО создаст весь миллиард элементов, пусть и виртуальных.
А вот мой туду лист до завершения первой альфы:
всякие валидаторы на data-model всякие классы там добавлять
при верных данных не верных данных всякое такое прочее, сделать
удобным для использования в кастомных инпатах и сделать удобным
для наследования
внедрить виртуальный дом чтобы не было ни промисов ничего,
я работал бы с виртуальными дом обьектами мгновенно, и без промисов
а виртуал дом бы сам решал когда их отрендерить физически.
если несколько одноименных компонентов конструируются на разных уровнях
одного элемента, то при @require() они перекрывают друг друга,
а должны быть каждый на своем... в общем решить эту неопределенность
суспендить еще и события внутри слипинг скоупов
сделать style-prop поддерживающими вендорные префиксы если они есть
SelectionSaver не работает в opera 12
доработать параметры сервиса http такие как таймаут и контент тайп
mouseenter mouseleave не работает в интернет експлорер)
on-wheel не работает в opera 12 (только on-mousewheel)
добавить многим ассинхронным сервисам опцию отключения
сохранения Async контекста, которая по умолчанию должна быть включена.
Так как многие ассинхронные сервисы, например анимейшенФрейм или
Промисы, используются в ядре, и ассинхронка там не нужна и работает
не корректно, так как это абстракция пользовательского левла.
сделать мерджевые атрибуты еще и датабиндинговыми,
чтобы несколько разных датабиндингов с ранных левлов
компонента срабатывали на одном атрибуте и значения рисовали
рядом через пробел. как мердж атрибутов, только динамический.
сделать нормальную передачу ассинхронки в промисах,
ибо теряется ассинхронный контекст в функциях переданных в then
и вообще решить делать лиасинхронку в промисах, они ж
горячее место в коде теперь ;)
А вот мой лист на сегодня:
сделать анимации в data-if
сделать анимации в data-repeat
доделать data-repeat
настроить чтобы таймер троттлинга очищался по завершению рендеринга
А еще у меня всякие наследования компонентов, шаблонов и контроллеров, автоматическая очистка мусора, виртуальная файловая система и модульность, даже кофескрипт в {{выражениях}} есть, а так же блекджек и немного шлюх ;)
А о том что БУДЕТ это я уже молчу, там такие нанотехнологии будут что людям и не снились) особенно мне нравится шеред контролелры которые между вкладами работают, и возможност нарисовать триллион значений из базы данных, при том не думая будет оно тормозить или нет) ну это уже в Mega скорее а не в юишке)
п.с. привет матрешка))))))) как там твои сеттеры)?
