Фух, всё правильно работает :)
В test_html.ss.js нет, т.к. там ты объявил прототип, но нигде не вызывал и сборщик мусора SS декларацию выпилил, т.к. она не нужна оказалась. А в test.ss.js нет, т.к. ты переопределил родительский для proto des блок и тем самым удалил его декларацию и сборщик мусора SS обнаружил, что на данный прототип нет больше ссылок и удалил его, т.е. это абсолютно правильное поведение, решать это можно двумя способами: 1) Вызов super в родительском блоке
{template main(param) extends html}
{block body}
{super}
<div class="wrap">
{apply des()}
</div>
{/}
{/template}
2) Явное указание использования прототипа
{template main(param) extends html}
{proto des(des)}
{super}
{/}
{block body}
<div class="wrap">
{apply des()}
</div>
{/}
{/template}
При таком подходе прототип будет вынесен из body, а body будет перезаписан. PS: если не сложно, добавь мне в issue заданице описать это поведение в доке, а то у мя ща нет возможности, а если не добавить, то я забуду :) UPD: повесил тикет по улучшению доки |
Давно хотел спросить.
Настроен watcher snakeskin в webstorm. header.ss тут делаем измененияheader.ss.js меняется, всё ок html.ss
{include 'header.ss'}
html.ss.js Шаблон не знает об изменениях, все плохоЕсли изменения делаются в подключаемом шаблоне, то все файлы в которых подкючается этот шаблон приходиться обновлять вручную. Можно как-то отслеживать изменения в подключаемом файле и пересобирать зависимые от него шаблоны? Может есть команда глобальной пересборки хотябы? Когда зависимый шаблон 1, то такое поведение терпимо, но когда их 10, это уже напрягает. |
Это косяк вотчера WS, насколько мне известно, что у этой проблемы нет решения сейчас :(
НО, ты же можешь использовать вместо WS: 1) Встроенный вотчер Snakeskin (--watch в CLI, натрави SS на папку с этим флагом); 2) Вотчер от Gulp или Grunt. Там таких проблем нет. Цитата:
snakeskin myTpls/ -o '%filePath%.js' Тут компилится папка, а результаты сохраняются рядышком с исходными файлами, подробнее https://github.com/kobezzza/Snakeski...0%BE%D0%B5-API |
kobezzza,
Спасибо за ответ. CLI-нул, все пересобралось норм. А вот такой вопрос. А зачем компилятор пишет в комменты абсолютные пути к шаблонам? Это вроде как плохая практика. |
Цитата:
|
Открыл для себя еще один кейз использования SS :)
Препроцессор для шаблонов под Angular, т.е. на этапе сборки проекта шаблоны компилятся с флагом exec и результатом является уже HTML, с которым работает Angular, а т.к. в SS есть директива {{ }}, то шаблон выглядит естественно и очевидно. В общем, по мне, супер как удобно! Интересно опробовать такой же кейз для React. |
Цитата:
имхо, переизобретаешь но движуха с реактом мне нравится. ты же jsx имел в виду под "реактом" ? |
Цитата:
Как объявлять?:
propTypes: {
value: React.PropTypes.string.isRequired
}
getInitialState: function () {}
И т.д. и т.п. У Реакта очень тесно связано объявление компонентов и обработка их поведения. Зачем туда пихать ещё и шаблонизатор, который будет делать что? |
Цитата:
Цитата:
|
var HelloMessage = React.createClass({
render: function() {
return <div>Hello {this.props.name}</div>;
}
});
VS
var HelloMessage = React.createClass({
render: function() {
return Snakeskin('myFile');
}
});
# template HelloMessage()
#< div
Hello {this.props.name}
И такой шаблон вернёт шаблон React (в примере использован расширенный синтаксис директив #, чтобы можно было спокойно использовать React {}). В шаблонах SS мы можем юзать наследование, макросы, локализацию, БЭМ и кучу прочих фич и бесшовно интегрировать их с React. |
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" />
)
}
});
Цитата:
|
Цитата:
Ну и я сейчас такой трюк юзаю с ангуляром на работе, как писал выше - оч удобно. Цитата:
Цитата:
1) Во первых SS может генерить любой текст и он точно также спокойно сгенерит текст с компонентом; 2) Это не только куча фишек, но и разделение сущностей, за которые не нужно платить, т.к. всё делается один раз на этапе сборки проекта. 3) Самое главное - это сейчас ну очень просто реализовать :) |
return Snakeskin('myFile');
Меня пугает до усрачки...Подключение шаблонизатора мне видится для ... я даже не знаю для чего. Цитата:
value: React.PropTypes.string.isRequired,он тоже сгенерит? |
Цитата:
Цитата:
Цитата:
Вот например шаблон, генерирующий JS:
#{template foo()}
function some() {
return #{1 + 2};
}
var a = {
bar: "#{'ffffuuuuuu'}"
};
#{/}
*** Вот ещё пример похожей схемы: Stylus и Rework, первый юзается для трансляции .styl в .css, а второй для .css в .сss (полифилы и т.д.) |
Хотел много чего написать, но напишу только одно. Не жалко времени, пофикси пересборку шаблонов, если возможно.
Цитата:
Цитата:
Если это критическая бага шаблонки, то вопрос снимается. Просто не понимаю, зачем нужен вотчер, если приходиться пересобирать все вручную. |
Стоп, я тебя не понял, какая бага?
Цитата:
Я объяснил ситуацию, привёл примеры и решения, что ты ещё хочешь то?
{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 А если у меня шаблоны разбросаны по разным папкам? |
Цитата:
|
Цитата:
Я уже описывал решения проблемы, но ок, опишу ещё раз: Решение 1: если ты хочешь как и раньше юзать вотчер WebStorm, то зайди в его настройки и просто задай вместо компиляции файла - компиляцию папки, например, snakeskin myTpls/ -o '%filePath%.js' Не надо боятся, что это будет долго делаться - не будет, SS не будет перекомпилить файл - если в этом не будет нужды. Решение 2: В CLI Snakeskin есть свой вотчер, который никак не связан с WebStorm и который знает про граф отношений. Для этого нужно убить вотчер в WebStorm и запустить из консольки SS с флагом --watch. Решение 3: Использовать вместо вотчера WebStorm вотчер gulp ил grunt - он просто при любом изменении будет перекомпиливать все шаблоны, т.к. решение похоже на пункт 1. Что тебе удобней - выбирай сам. |
Цитата:
Цитата:
Опиши проблему в wiki, люди хотя бы не будут материть тебя. Это реальный геморр выбора вывод ошибок в консоль шторма и запуск отдельного вотчера из консоли. Может тебе так не кажется, но это так. |
У меня открыто обычно штук 5-6 консолей и там что-нибудь да выводится, переключаться в этом хороводе не очень удобно.
|
Цитата:
Про сторонние вотчеры: во многих IDE нет вотчеров, поэтому есть сторонние, включая решение из коробки. *** Я лично уже давно не юзаю вотчеры, а просто запускаю gulp сборку по хоткею: почему я так делаю? Хз, я пришёл к выводу, что мне так удобнее. Цитата:
|
Цитата:
Цитата:
|
Цитата:
snakeskin ./server/tpl/ -o %filePath%.js SnakeskinError: text can't be used in the global space, file: , line: 1 В консоли шторма отрабатывает нормально. |
Цитата:
|
Цитата:
|
Цитата:
Program: C:\Users\kobez_000\AppData\Roaming\npm\snakeskin.cmd Arguments: ./server/tpl/ -o %filePath%.js Working Directory: $FileDir$ Output Path: $FileName$.js У тебя отличия будут только в Program (думаю понятно почему). *** Хотя стой, тебе не надо в кавычки брать, у тяж линух, а я для cmd.exe описал, отбой :) |
snakeskin ./server/tpl/ -o '%filePath%.js' SnakeskinError: text can't be used in the global space, file: , line: 1 |
Цитата:
|
Получилось? А то я спать хочу :)
|
Цитата:
|
Цитата:
|
-s $FileName$ -o $FileName$.js --pretty-print $FileDir$ $FileName$.js Работает нормально ./server/app/tpl -o %filePath%.js $FileDir$ $FileName$.js Не работает (да шаблоны ./server/app/tpl) -o %filePath%.js $FileDir$ $FileName$.js Так зависает (да шаблоны ./server/app/tpl) |
Мы придурки :)
У нас рабочая директория стоит же $FileDir$ :D Вот оно и не работает |
kobezzza,
Я первым делом попробовал заменить аргументы в настройках, вышла фига. Из консоли работало нормально, поэтому пользовался молча. Но сейчас шаблоны усложнились и пользовать стало тяжелее. |
Цитата:
|
Указал полный путь от корня / (вместе с /home/юзер/blabla/..../), завелось. Спасибо что помог. Похоже относительный не понимает совсем ни в каком виде.
Тоже бы в wiki стоило добавить, я полдня убил на переборы, пути подбирал. Еще раз спасибо, у самого бы фиг терпения хватило на добивание. |
Цитата:
Program: C:\Users\kobez_000\AppData\Roaming\npm\snakeskin.cmd Arguments: $ProjectFileDir$/server/app/tpl -o %filePath%.js --pretty-print Working Directory: $FileDir$ Output Path: $FileName$.js Обрати внимание на $ProjectFileDir$, т.е. нужно было явно сказать WebStorm, что пляшем от корня проекта. Цитата:
|
Цитата:
|
| Часовой пояс GMT +3, время: 06:38. |