borschik:include относительно блока. Правильное раскрытие путей

[voischev]

Во всех наших проектах мы вставляем SVG в шаблоны. SVG бывает очень развесистым и переводить его в «строку» руками не очень удобно и быстро.

Мы попробовали вставлять SVG через /*borschik:include:…..*/, но в той схеме сборки, что реализована сейчас, нужно путь к файлу указывать относительно банда, а не блока.

Хочется как то так:

block('link').mod('theme', 'instagram').content()('borschik:include:link_theme_instagram.svg');

Думаю это интересное решение для вставки чего-то в шаблон. У нас есть возможность использовать один SVG файл для блока в шаблоне, в css и в js через такую конструкцию, кажется совершенно неправильным думать о пути к файлу из вне блока.

[tx44]

Нужная фича, плюсуюсь.

[voischev]

сс @blond что скажешь? Очень надо

[blond]

Кажется, что использовать borschik и что-то знать про него xjst-based технологии не должны.

Но кейс вполне годный. Кроме того, наверника, существует ещё ряд годных кейсов про предобработку шаблонов перед компиляцией.

Есть какие-то предложения?

Можно, например, сделать опцию process, которая будет принимать функцию-callback. Запускаться она будет после чтения каждого файла.

[awinogradov]

Я бы все таки думал в сторону инклюда. Это понятно и удобно. @blond зачем функция? Может типо includeCtx('path/to/file.svg') ?

[voischev]

Ну у нас частый кейс — фризить картинки которые вставляются в шаблонах <img src="path/to/file.png"/> (ну или { block : 'image', url : 'path/to/file.png' }, как хотите:)). Мы прокидывали функцию борщика в VM что бы оно работало. Но круто было бы что бы прям из коробки работало. В принципе можно даже инлайнить картинки в стили в base64 прям в шаблонах

[awinogradov]

base64 увеличивает вес svg, а при инклюде даже запроса нет и есть dom

[voischev]

@verybigman я там не про svg. Вообще вот такой кейс

{
    block : 'super-bkg',
    attrs : { style : 'background: url(' + borcshik.link('pach/to/image.png') + ');' }
}

Хотя да это уже не про include, а про link

[qfox]

Можно, например, сделать опцию process, которая будет принимать функцию-callback. Запускаться она будет после чтения каждого файла.

технологии специальные бы уже сделали, которые смогут подготавливать файлы...

[voischev]

:+1:

[blond]

технологии специальные бы уже сделали, которые смогут подготавливать файлы...

Какое у них должно быть API?

[qfox]

@blond я вижу это так:

level1/
  block1/
    block.techA
    block.techB
level2/
  block/
    block.techA
bundles/
  bundle/
    bemdecl: block techA

• Case 1: препроцессим techA и провайдим дальше (например, stylus, less, coffee, etc.)
• Case 2: постпроцессим techA (в т.ч. после препроцесса) и провайдим дальше
• Case 3: из techA и techB делаем techC и после провайдим как реальный файл дальше

Т.е. нечто близкое к gulp.src(...).pipe

Все 3 кейса могут выполняться в любом порядке до того, что сейчас делает ENB.

В ENB можно будет просто склеить подготовленные кусочные файлы — drastically уменьшим кол-во и упростим ENB технологии.

p.s. Это все очень близко к gulp и поэтому мб. стоит не выдумывать велосипедов и добить deps-резолвер модульный. Технически, получается что-то такое:

gulp.src(...).pipe(...).pipe(...) → bemSourceTarget
bemBuild.run() → destTarget1, destTarget2, etc. destTargetN
destTargetN.pipe(...).pipe(...)

Штука, которая покрывает все обозримые кейсы.

p.s. Может быть из file-provider сделать хитрый гульпообразный мундштук, который будет покрывать какие-то кейсы?

[qfox]

@blond вар.2 на идее «вместо file-provider» соберем гульпохрень: Внутри себя оно будет кешировать, принимать на вход наборы функций-преобразователей и конфигов и само будет читать файлы и препроцессить, если заданы функции. Условно это может быть так:

enb.addFilter('techA', function (node, src) {
  // node — блок на уровне
  return src.replace('__', '--'); // тут можно промис вернуть
});
enb.addProvider('techC', ['techA', 'techB'], function (node, srcA, srcB) { // или 
  // node — тот же блок на уровне,
  // и возвращает файл levels/block/block.techC,
  // который не существует на диске
  // можно еще наколдовать, чтобы он запускал это, только если файла нет
  return vowFs.readFile(node.path + this.tech)
    .catch(function (err) { return srcA + srcB; });
});

Вообще, этому место, по логике, в ядре, но ты ж говорил, что коммиты в ядро ENB это плохо, но может попробуем покрыть тестами, а затем повырезаем хардкод, сделаем это внутри ENB и щелкнем мажорную версию?

[voischev]

предложение чумавое)

[voischev]

В какой версии ждать?

[qfox]

Когда ядро покроем тестами — будет гипотетическая возможность это делать. Т.е., точно не раньше.

[voischev]

@zxqfox ты классный

[qfox]

Я вот смотрю на этот issue и не пойму почему оно в enb-bemxjst?