Comments 18
Если маршрут не указан, то перебрасываем пользователя на маршрут по умолчанию.
Правильно ли я понял, что в истории появится дополнительная запись из-за чего кнопка "назад" перестанет работать (переход к предыдущей странице будет возвращать на текущую)?
Отлично! В тот момент, когда страница станет сателлитом корневого компонента нашего приложения, е набор данных перейдет в состояние DEPRECATED.
Будет ли при это показывается надпись "Идёт загрузка данных" на весь экран или же будут показаны данные из кэша, а обновление будет происходить в фоне?
клиентский код получается довольно линейным из-за отсутствия циклов и большого количества ветвлений.
Однако мы имеет лапшу из промисов.
<b:define name="active" from="selected" type="bool"/>Адский костыль. Без него совсем никак? В целом, я смотрю, фреймворк требует изучения 100500 абстракций. Так Ангуляр не победить. :-)
Правильно ли я понял, что в истории появится дополнительная запись из-за чего кнопка "назад" перестанет работать
Да, правильно – в текущей версии кода все так и будет. Нужно добавить true вторым параметром router.navigate(), тогда переход будет с заменой, то есть router.navigate(defaultRoute, true). Думаю Сергей исправит.
Будет ли при это показывается надпись "Идёт загрузка данных" на весь экран или же будут показаны данные из кэша, а обновление будет происходить в фоне?
Судя по коду, пока грузятся данные, контент страницы не показывается (см. <div{page} b:hide="{loading}"/> в шаблоне). Можно убрать атрибут b:hide из шаблона и будут показаны данные из кеша (с фоновой синхронизацией). В целом сделать любой альтернативный вариант не сложно.
Однако мы имеет лапшу из промисов.
Какую лапшу вы имеете ввиду? Тут вроде промисы приходят только из API ВКонтакте, и дальше адаптера и модели не выходят.
Адский костыль. Без него совсем никак?
Это не костыль. Тут выполняются две функции:
- по сути переименовывается значение, так как значение приходит в шаблон с именем
selected, а в разметку нужно вставить классactive - фиксируется тип значения – так шаблонизатор и инструменты будут знать, что
selectedэто гарантированно булево значение
А выносится отдельно, чтобы было наглядней и не зашумлять основную разметку, да к тому же описанное значение может использоваться в нескольких местах.
Без этого в большинстве случаев можно (если не нужно переименование, но его можно сделать и в компоненте), но не нужно. Так как позволяет сделать разметку более предсказуемой и найти в ней ошибки – опечатки, мертвый код (например, https://youtu.be/IUtbbN9aevU?t=27m15s), безопасно переименовывать классы etc.
Спасибо! Исправил.
Да. Я добавил b:hide для того, чтобы во время показа надписи «загрузка», основной список не сползал вниз и не прыгал в случае быстрой загрузки. Но это уже вопрос UX. Можно убрать b:hide и прикрутить какой-нибудь Line Progress Bar, тогда визуально всё будет гладко
Причины такого решения понятны, но все равно какой-то костыль получается.
по сути переименовывается значение, так как значение приходит в шаблон с именем selected, а в разметку нужно вставить класс active
По сути надо выводить или не выводить определённую строку в зависимости от флага. А тут происходит создание переменной-алиаса для флага и вывод её имени, вместо значения. При этом получается, что поведение фигурных скобок отличается в этих двух случаях:
<button type="button" class="btn btn-default {active}" event-click="click">
{title}
</button>Неконсистентность API — это то, что убило большинство фреймворков.
фиксируется тип значения – так шаблонизатор и инструменты будут знать, что selected это гарантированно булево значение
Весь остальной код даже не на тайпскрипте, но вот именно в шаблонах типы очень важны. :-D А почему тип для title не объявили?
А выносится отдельно, чтобы было наглядней и не зашумлять основную разметку, да к тому же описанное значение может использоваться в нескольких местах.
Ну да, что-нибудь типа { selected ?: "active" } — очень ненаглядно и шумит, а вот <b:define name="active" from="selected" type="bool"/> — сразу понятно, что есть что, да.
Чтобы не повторяться и дать более полную картину – описание работы <b:define>
свойство active назвать было нельзя, поскольку свойство с таким именем используется для в Node для других целей
Можно. Свойства view и биндинги это разные вещи. Стандартного биндинга active нет и его можно задать (и даже если бы был – ничто не мешает поменять его для конкретной ноды или класса). С другой стороны, получается view подстраивается под шаблон – чего мы не хотим. Потому в шаблон передается признак, а что дальше с ним будет для view не важно. Сегодня используется bootstrap и класс нужен active. Завтра другой фреймворк и там будут другие классы, или свои стили напишем, со своими именами – нужно будет поменять только шаблон.
И вы опять все сводите к тому, чтобы выбрать имя для класса – это не единственное. Даже если будет свойство active пробрасываться в шаблон, все равно крайне явно задать тип: <b:define name="active" type="bool"/>
Вот некоторые моменты:
Basis.js имеет более декларативный подход в описании компонентов — налаживание связей между частями приложения и организация потока данных.
При описании шаблона, разработчик действительно описывает только шаблон, без выражений и условных/циклических операторов, т.к. задачи связи представления с данными выполняют отдельный модули, о чем было рассказано в предыдущей статье.
В basis.js нет digest-цикла. Синхронизация данных устроена при помощи токенов, которые были рассмотрены в первой части.
Basis.js «из коробки» поддерживает инструментирование кода, но это тема для отдельной статьи.
Что из этого считать профитом — решайте для себя сами. Я бы рекомендовал попробовать оба фреймворка в разных задачах и сделать собственные выводы.
Делаем крутые Single Page Application на basis.js — часть 3. Клиент для «ВКонтакте»