-
Notifications
You must be signed in to change notification settings - Fork 22
Next
-
Model. Отличие от дарьевских хэндлеров -- хэндлер это набор моделей с одинаковым id. Т.е., скажем, все списки писем в почте это один хэндлер. В noscript'е -- каждый список писем (т.е. с определенными параметрами) это одна модель. Это инстанс класса Model, со своими методами и т.д. Данные модели можно менять при помощи специальных методов, после чего она генерит на себе события, на которые можно подписывать (например, блок их слушает).
-
Request. Запрос нужных моделей с сервера.
-
View. Block в терминах дарьи. Боксы это части View теперь. В боксе может быть больше одного видимого элемента.
-
Layout. В дарье боксы контролировались через специальные методы (select???), которые по params говорили, какой именно блок они собираются показать. Плюс у каждого блока были описаны его потомки. В noscript'е лэйаут описывается декларативно для каждой страницы. Это устраняет проблему, когда изменение метода select??? для добавления (например) новой страницы, ломает какую-то еще страницу.
-
Router. Решает, какой лэйаут нужно выбрать для данного урла. Плюс парсит урл в набор параметров.
-
Update. Перестраивает страницу в соответствии с новыми параметрами. Вопрос: нужны ли локальные апдейты?
-
Коллекции. Возможно, Model.Collection и View.Collection. Нечто для реализации, например, слайдера для фоток или бесконечного списка писем. Со стороны сервера есть ручки, возвращающие куски списка (постранично или с указанием произвольного диапазона). Модель (Model) умеет хранить "разряженный" список таких кусков, дозапрашивать при необходимости недостающие и формировать данные для шаблонизации. Блок (View) умеет отображать нужные (видимые) куски, дорисовывать недостающее, удалять лишнее (чтобы не хранить в DOM'е тысячи элементов).
-
Многоступенчатая загрузка моделей. Т.е. данные из результатов одного реквеста формируют параметры для следующего.
-
Возможность перерисовывать не весь блок целиком. Плюс для коллекций возможность перерисовать выборочно несколько элементов коллекции. Для обычных блоков нужно уметь перегенерять совсем мелкие куски (флажок в списке писем, новая метка, лайк у фотки и т.д.). Возможно, современные браузеры уже достаточно быстрые, чтобы перерисовывать более крупные куски (померять!). В любом случае, нужно полностью отказаться от ручной модификации html'я блока. Все изменения должны идти через изменения моделей, а блок должен слушать события от соответствующих моделей. Причем, для сложных моделей (фотка, письмо, и т.д.) должны генериться (и слушаться) события не только об изменении модели целиком, но и для изменения части модели (флажок и т.д.).
Как. Примерно так я это себе вижу:
-
В html-е блока размечаются subview. Через соответствующий класс:
<div class="view view-message"> ... <div class="subview subview-message-labels"> ... </div> ... </div>В терминах BEM это в общем-то элемент. Но не совсем. На деле это просто обертка над каким-то количеством DOM-нод, которые нужно уметь перерисовать.
-
В описании view добавляются условия, при которых нужно блок перерисовать. Видимо, проще всего это делать в терминах моделей.
subviews: { // Перерисовать subview labels, если у модели message поменялось что-либо по jpath'у .labels. 'message.labels': [ 'labels' ], // Перерисовать subview labels, если в модели labels поменялась метка с id совпадающим с одной из меток письма из message. 'labels.label[ .id == message.labels.label.id ]': [ 'labels' ] ... }
-
-
Несколько одинаковых блоков на странице. Сейчас в noscript'е нельзя показать одновременно два блока с одним id, но разными параметрами. Что насчет двух одинаковых блоков с одинаковыми же параметрами? По идее может пригодиться.
-
Несколько "ключевых" наборов параметров для блока. Причем в параметрах из урла могут присутствовать параметры из двух и более наборов, так что блок должен уметь выбирать, чем именно параметризоваться.
-
Анимация. Нужны анимации блоков при переходе между страницами. И нужны, возможно, глобальные (страничные) анимации (например, для мобильной почты).
-
Garbage Collector. При этом для блоков он должен быть таким, чтобы в боксах не хранить много элементов, а для моделей должен быть автоматическим -- т.е. если модель не нужна больше никакому блоку, то можно ее прибивать. Тут тонкий момент есть. Если модель напрямую не используется блоком, но она участвовала в построении параметров для него, то после ее прибития мы не сможем перерисовать блок (например, нажав на Back) без перезапроса.
-
"Транзакции" при изменении моделей. Например, мы хотим изменить несколько моделей. Каждое изменение тригерит событие, которые меняет блок (или несколько блоков). Нужно уметь все эти изменения склеить в один апдейт.
-
Undo. В целом вроде несложно. Нужно запоминать копии моделей до изменения. Плюс нужно обратное действие. Видимо, вычислить его из diff'а моделей будет нереально. Т.е. скажем, ставя флажок на письмо, нужно запомнить модель без флажка и действие "снять флажок", которое представляет собой id действия и набор параметров к нему. Не всякое действие обратимо, очевидно.
-
События на блоках а-ля наноблоки. Вообще, неплохо бы заюзать код для развешивания событий на наноблоки и в noscript'е. Помимо DOM-событий, нужны и кастомные события. Как блочные, так и глобальные. Или вообще сделать все блоки одновременно и наноблоками.
-
Наследование лэйаутов.
-
Нужен какой-то объект Page. Для хранения всякого про страницу. А то сейчас оно все размазано непонятно по каким переменным.
-
Клавиатурная навигация.
-
Шоткаты.