kobezzza,
мы поместили шаблонизатор в шаблонизатор, чтобы ты мог юзать шаблоны во время юзания шаблонов
Довольно интересный вариант, но, как мне кажется лучше собрать больше мнений, мб выяснятся какие-то +/- такого решения. Да-да, я намекаю на статью :)

kobezzza,
Реакт это не шаблоны, а компоненты. HTML там только в самой начальной точке.

Давай такой пример.

var Btn = React.createClass({
    propTypes: {
      value: React.PropTypes.string.isRequired,
      className: React.PropTypes.string.isRequired
    },
    render: function () {

        return (
            <div className={this.props.className}>{this.props.value}</div>
        )
    }
});

//React.PropTypes.string.isRequired - выдает ошибку, если мы забудем указать свойство


var Board = React.createClass({

    getInitialState: function() {
        return {
            className: "btn",
            value: "Кнопка"
        };
    },

    render: function () {

        return (
	    <Btn className={this.props.className} value={this.state.value} />
            <Btn className="btn-my" value="submit" />
        )
    }
});

:)

Идея стара как мир, тот же XSLT и является таким примером, и его основное применение - это шаблоны миграции данных в XML.

Ну и я сейчас такой трюк юзаю с ангуляром на работе, как писал выше - оч удобно.

Я было взялся переводить всё на инглишь, но внезапный поток дел навалился, 3-ю неделю не продохнуть. А статья в подвешеном виде пока, увы :(

Это я понимаю, но:

1) Во первых SS может генерить любой текст и он точно также спокойно сгенерит текст с компонентом;

2) Это не только куча фишек, но и разделение сущностей, за которые не нужно платить, т.к. всё делается один раз на этапе сборки проекта.

3) Самое главное - это сейчас ну очень просто реализовать :)

return Snakeskin('myFile');

Меня пугает до усрачки...

Подключение шаблонизатора мне видится для ... я даже не знаю для чего.

Эм, а

value: React.PropTypes.string.isRequired,

он тоже сгенерит?

Ну многих и шаблоны пугают до усрачки, я в этом не вижу ничего плохого, мы просто кидаем линк на файл SS (который например лежит рядышком в папочке) и после трансляции этот вызов будет заменён на родной для React и усё.

В SS есть встроенная локализация на уровне синтаксиса, поддержка БЭМ как в Stylus, короткий синтаксис аля Jade или HAML и т.д. Расценивать это нужно только как сахар.

Ну, я имел ввиду генерить только то, что как то связано с разметкой, но вообще - да, SS может сгенерить что угодно, включая другой шаблон для SS :)

Вот например шаблон, генерирующий JS:

#{template foo()}

    function some() {
        return #{1 + 2};
    }

    var a = {
        bar: "#{'ffffuuuuuu'}"
    };

#{/}

***

Вот ещё пример похожей схемы: Stylus и Rework, первый юзается для трансляции .styl в .css, а второй для .css в .сss (полифилы и т.д.)

Хотел много чего написать, но напишу только одно. Не жалко времени, пофикси пересборку шаблонов, если возможно.
Это конечно круто, но нифига не прикольно. Мне приходиться пересобирать все шаблоны через CLI, вместо того, чтобы сборщик при сборке проверил используется ли прототип в шаблонах где-то ещё и пересобрал шаблоны.

Если это критическая бага шаблонки, то вопрос снимается. Просто не понимаю, зачем нужен вотчер, если приходиться пересобирать все вручную.

Стоп, я тебя не понял, какая бага?

Это объяснения я писал для случая, когда ты умышленно уничтожаешь унаследованный прототип в родительском блоке и это абсолютно нормальное и логично поведение и я показал, как можно этого избежать: просто использовать super или явно вынести прототип за пределы родительского блока в родительском или дочернем шаблоне.

Я объяснил ситуацию, привёл примеры и решения, что ты ещё хочешь то?

{template base()}
  {block bar}
    {proto e()}
        1
    {/}
  {/}
{/}

{template child() extends base}
  {block bar}
    fffffuuuu
  {/}
{/}

Неужели ты не видишь, что в дочернем шаблоне ты переопределил блок bar и всё его старое содержимое было законно уничтожено.
Если ты хочешь доопределить - то просто используй super

{template child() extends base}
  {block bar}
     {super}
     fffffuuuu
  {/}
{/}

Это самый логичный способ.

Есть ещё способ 2, который я также уже описывал, но который я бы не рекомендовал, т.к. на мой взгляд он не такой очевидный - это вынести прототип из родительского блока:

{template child() extends base}
  {proto e()}
    {super}
  {/}

  {block bar}
     fffffuuuu
  {/}
{/}

Здесь ты переопределил блок bar, но также явно вынес прототип.

Причём тут вотчер? Я совсем потерял нить твоего вопроса.

Тьфу, не то, мозг отрубается...

http://javascript.ru/forum/project/3...tml#post356968

А если у меня шаблоны разбросаны по разным папкам?

Критические баги я исправляю немедленно, в любое время суток и если ты таковую найдёшь, то она сразу будет исправлена. Я очень серьёзно отношусь ко всем своим разработкам.

Я же про это тоже писал: ты используешь вотчер WebStorm и он работает по принципу: следит за файлами и когда происходит изменения запускает процесс, который после выполнения работы убивается и поэтому я не могу составить граф отношений, чтобы следить за зависимостями. Я давно знаю эту проблему и поэтому давно решил её, но это проблема WebStorm.

Я уже описывал решения проблемы, но ок, опишу ещё раз:

Решение 1: если ты хочешь как и раньше юзать вотчер WebStorm, то зайди в его настройки и просто задай вместо компиляции файла - компиляцию папки, например,

snakeskin myTpls/ -o '%filePath%.js'

Не надо боятся, что это будет долго делаться - не будет, SS не будет перекомпилить файл - если в этом не будет нужды.

Решение 2: В CLI Snakeskin есть свой вотчер, который никак не связан с WebStorm и который знает про граф отношений. Для этого нужно убить вотчер в WebStorm и запустить из консольки SS с флагом --watch.

Решение 3: Использовать вместо вотчера WebStorm вотчер gulp ил grunt - он просто при любом изменении будет перекомпиливать все шаблоны, т.к. решение похоже на пункт 1.

Что тебе удобней - выбирай сам.