Согласен только по последнему примеру. В первом выравнивал бы не все (default бы оставил), последний пример вообще бы не выравнивал. Но, как говорится, на вкус и цвет…
2. главное, что дает redis — это возможность горизонтального масштабирования (можно запустить несколько derby-серверов для одного сайта). Но это можно будет включить и потом. Для начала без redis-а — самое то.
Создателем дерби изначально предполагалось, что стили будут подключаться к компонентам так же как и файлы шаблонов, но на данный момент этого так и не сделало. Чтобы понять почему, нужно немножко оглядеться вокруг.
На данный момент дерби поддерживает 3 типа файлов со стилями: чистый css, less и stylus. Самым продвинутым является stylus — его-то все и используют (и создатели дерби в своих приложениях в том числе). Не знаю, как в less-е, но в stylus-е есть один очень удобный механизм замены локальных переменных глобальными.
Сейчас я объяснию на примере, чтобы было понятно. Допустим у нас есть компонент и в файле стиля этого компонента мы определяем переменную с цветом фона $back-color ?= black. Фишка в том, что стилус (когда мы пишем ?= вместо обычного = )позволяет нам сделать это определение не жестким, а как бы поумолчанию. То есть, если мы зададим глобально$back-color = red, то фон у компонента станет красным. Это очень удобно, но для того чтобы это работало, файл стилей компонента должен быть явно импортирован в глобальном файле стилей. Обычно все так и делают.
Глобальный файл стилей получается выглядит как-то так (index.styl):
// Global vars
$back-color = red
// Import components
@import './../components/*/*.styl'
Исходя из этого, пока, создатели дерби не нашли удобного пути, как сделать чтобы можно было подключать стили и так и так.
> Данные в компонент передаются только через шаблон?
По хорошему да, но никто, на самом деле, не мешает запрашивать их уже после подключения компонента, единственное нужно понимать, что метод init синхронен, поэтому всякие-там subscribe, fetch или ajax.get и т.д. невозможно выполнить до начала рендеринга, а, следовательно, серверный рендеринг страдает.
Ну а так вообще, если нужно получать данные уже в процессе работы компонента — нет никаких ограничений — в любом обработчике можно дотягивать что-либо из модели (fetch, subscribe), либо даже тягать что-то ajax-ом, если данные, лежат где-то на стороне.
> Не совсем понятно, почему я не могу сделать компонент, который будет работать с глобальной моделью.
Можете, это просто нарушит идею изолированности, а так вполне:
в js глобальная модель доступна во всех методах компонента, например
Dropdown.prototype.init = fucntion(){
var myGlobalVar = this.model.root.get('_page.myGlobalVar');
}
Примерно то-же самое и в шаблонах. Нужно просто начинать путь с #root
<index:>
{{each #root._page.todos as #todo}}
<!-- ... -->
{{/}}
> Можно ли компоненты подгружать по мере необходимости(lazy load)?
Насколько я знаю — штатных средств для этого нет, но я легко могу себе представить, как это можно сделать :)
Думаю, в общем случае, выбор варианта зависит от задач (нужна ли нам гибкость запросов / производительность ). В случае с mongodb, фильтрация запросов очень даже оправдана, ведь mongodb — документоориентированная база. Она очень сильно отличается от SQL например тем, что не поддерживает join-ы и т.д. Всегда можно точно сказать, что вот эти таблички можно только читать, вот эти править, а вот в этой пользователь может править только свои записи. Подавляющее большинство запросов в mongo идет к какой-то одной конкретной табличке (коллекции в их терминологии), и все можно быстро отфильтровать.
Фактически — да, писать mongo-db запросы на клиенте, которые смогут тянуть только те данные, которые доступны. Границы, например в derby и метеоре разные. В дерби изоморфная часть — это роутер, рендеринг, подписка на данные. Настройка доступа к данным, подключение всяких скриптов клиентских (ну и вообще формирование бандла) — это все серверные задачи. Так же нужно понимать, что даже, не смотря на то, что всевозможные event-handler-ы и входят в derby-приложение (которое изоморфно), срабатывать они будут только на клиенте (я имею ввиду всякие on-click и т.д.). В метеоре, же, например, рендеринг сейчас полностью клиентский — здесь другие границы.
«На заводе Apple в центре Нью Йорка 80 одетых от Дольче Габана бандитов незаметно выкрали 7 фур iphone 6s с новым, ультросовременным эраном ....»
require('coffee-script');надо писатьrequire('coffee-script/register');2. главное, что дает redis — это возможность горизонтального масштабирования (можно запустить несколько derby-серверов для одного сайта). Но это можно будет включить и потом. Для начала без redis-а — самое то.
3. на github, обсуждение на русском (хотя там и много оффтопика), на английском
Создателем дерби изначально предполагалось, что стили будут подключаться к компонентам так же как и файлы шаблонов, но на данный момент этого так и не сделало. Чтобы понять почему, нужно немножко оглядеться вокруг.
На данный момент дерби поддерживает 3 типа файлов со стилями: чистый css, less и stylus. Самым продвинутым является stylus — его-то все и используют (и создатели дерби в своих приложениях в том числе). Не знаю, как в less-е, но в stylus-е есть один очень удобный механизм замены локальных переменных глобальными.
Сейчас я объяснию на примере, чтобы было понятно. Допустим у нас есть компонент и в файле стиля этого компонента мы определяем переменную с цветом фона
$back-color ?= black. Фишка в том, что стилус (когда мы пишем ?= вместо обычного = )позволяет нам сделать это определение не жестким, а как бы поумолчанию. То есть, если мы зададим глобально$back-color = red, то фон у компонента станет красным. Это очень удобно, но для того чтобы это работало, файл стилей компонента должен быть явно импортирован в глобальном файле стилей. Обычно все так и делают.Глобальный файл стилей получается выглядит как-то так (index.styl):
Исходя из этого, пока, создатели дерби не нашли удобного пути, как сделать чтобы можно было подключать стили и так и так.
По хорошему да, но никто, на самом деле, не мешает запрашивать их уже после подключения компонента, единственное нужно понимать, что метод init синхронен, поэтому всякие-там subscribe, fetch или ajax.get и т.д. невозможно выполнить до начала рендеринга, а, следовательно, серверный рендеринг страдает.
Ну а так вообще, если нужно получать данные уже в процессе работы компонента — нет никаких ограничений — в любом обработчике можно дотягивать что-либо из модели (fetch, subscribe), либо даже тягать что-то ajax-ом, если данные, лежат где-то на стороне.
> Не совсем понятно, почему я не могу сделать компонент, который будет работать с глобальной моделью.
Можете, это просто нарушит идею изолированности, а так вполне:
в js глобальная модель доступна во всех методах компонента, например
Примерно то-же самое и в шаблонах. Нужно просто начинать путь с #root
> Можно ли компоненты подгружать по мере необходимости(lazy load)?
Насколько я знаю — штатных средств для этого нет, но я легко могу себе представить, как это можно сделать :)