Моё мнение пока не изменилось, нужны контр аргументы с подробностями

Раньше хотелось, но всетаки bemjson.js = 1 одна страница и не нужно это менять :) Оставьте технологию максивально простой.

Может быть вместо магии сделать служебный чернорабочий блок? вместо 'я просто строка' будет {block:'sys', elem:'include', file:'подключи/меня/друг.json'}

Для начала расскажите, какие минусы в том, чтобы пробросить require в контекст выполнения bemjson? Вроде это + одна строка кода и не дорого?

Плюсы прежние: заставить bem make работать с борщиковым инклюдом — это нетривиальная задача с точки зрения конфигурирования сборки (я знаю как ее так настроить, но мне от этого печально).

@voischev Так ведь это ж дело добровольное, всегда можно не пользоваться фичей и иметь все тот же максимально простой bemjson ;)

@zxqfox Магии в том, чтобы позвать require('fs').readFileSync не вижу, но у меня не так давно возникала идея про raw.bemjson.js, из которого бы продуцировался bemjson.js путем сборки blocks/*/*.bemjson.js-файлы и as is подставлялись в соответствующие места в декларации. Но меня убедили, что с этим есть неочевидные моменты и что рано или поздно захочется какой-то кастомной фигни вместо совсем тупого инклюда.

require() пробросить — без проблем. Но вместе с этим я бы сделал bemjson.js файлы CommonJS модулями.

Но мы же начали этот разговор в контексте другого решения — честного асинхронного include. С этим решение действительно не так просто.

15.11.2013, 03:19, "Vladimir Grinenko" notifications@github.com:

Для начала расскажите, какие минусы в том, чтобы пробросить require в контекст выполнения bemjson? Вроде это + одна строка кода и не дорого?

Плюсы прежние: заставить bem make работать с борщиковым инклюдом — это нетривиальная задача с точки зрения конфигурирования сборки (я знаю как ее так настроить, но мне от этого печально).

@voischev Так ведь это ж дело добровольное, всегда можно не пользоваться фичей и иметь все тот же максимально простой bemjson ;)

@zxqfox Магии в том, чтобы позвать require('fs').readFileSync не вижу, но у меня не так давно возникала идея про raw.bemjson.js, из которого бы продуцировался bemjson.js путем сборки blocks//.bemjson.js-файлы и as is подставлялись в соответствующие места в декларации. Но меня убедили, что с этим есть неочевидные моменты и что рано или поздно захочется какой-то кастомной фигни вместо совсем тупого инклюда.

— Reply to this email directly or view it on GitHub.

##

Отправлено из мобильной Яндекс.Почты: http://m.ya.ru/ymail

bemhtml ничего не известно о файле, в котором был написан bemjson. Он не сможет привести относительную ссылку к абсолютной.

14.11.2013, 20:25, "Alex Yaroshevich" notifications@github.com:

Может быть вместо магии сделать служебный чернорабочий блок?

вместо 'я просто строка' будет {block:'sys', elem:'include', file:'подключи/меня/друг.json'}

— Reply to this email directly or view it on GitHub.

##

Отправлено из мобильной Яндекс.Почты: http://m.ya.ru/ymail

есть проблема инвалидации кешей — если контент bemjson вычисляется с помощью всяких require, то уже нельзя просто использовать дату модификации файла, нужно его будет каждый раз выполнять и проверять результат со старым

@arikon @veged Эти две причины + не json формат bemjson файла — предпоссылки для реализации raw.bemjson, про который говорил @tadatuta и я в закрытом ишью bem/bem-tools#271 Если в bemjson будет лежать честный json — это будет commonjs, и его можно будет тупо require(xxx.bemjson) штатными средствами nodejs

@zxqfox честного json-а точно не хочется — мы много где используем map, например, да и писать ключи в двойных кавычках не нравится :)

@tadatuta и значения в одинарных ;-)

Есть ли сейчас возможность вставки в bemjson из json? Если есть, то как реализовать?

А то bemjson вроде как "скелет/чертёж" проекта, но из-за больших контентов при разработке многое становится не так легко читабельно.

@belozyorcev есть, мы ведь вот тут обсудили все возможные варианты ;)

@tadatuta я не мог просто найти )) Тема не однозначно называется, хотя помнил что обсуждали. А поиск на форуме не работает.

Хорошо бы на сайте создать раздел "рецепты"

@gela-d @tormozz48 @tavriaforever нужно что-то делать с поиском по форуму — у нас тут куча полезного контента, а люди его найти не могут :(

нужно что-то делать с поиском по форуму — у нас тут куча полезного контента, а люди его найти не могут :(

Спасибо! Подумаем.

Фича безусловно полезная. По наивности даже делал такую штуку руками. Ад еще тот.

Во-первых сам require кеширует подключаемый файл (и всякие clear-require лично мне не помогли, только touch). Во-вторых половина техник по дороге требуют инвалидации кеша (причем иногда очень странной, хотя возможно это мои кривые руки). Половина багов в моей сборке была как раз из-за этой фичи.

Список зависимостей относительно просто получается через https://www.npmjs.com/package/precinct

Я на одном проекте использую require в bemjson. Бандлы, которые строят html-фрагменты для приложения я включаю в свои тестовые страницы, чтобы разрабатываться на enb-сервере отдельно от приложения. Так удобнее. Кеши правда приходится руками сбрасывать. Благо bemjson - не самая часто редактируемая часть проекта. Если бы у тулзов сборки был свой include, который бы при этом еще и кеши сам инвалидировал - была бы вообще сказка.

есть проблема инвалидации кешей — если контент bemjson вычисляется с помощью всяких require, то уже нельзя просто использовать дату модификации файла, нужно его будет каждый раз выполнять и проверять результат со старым

Например в кешах можно хранить не только дату модификации файла, но и список включаемых в него файлов и даты их модификации (рекурсивно). Это правда накладывает ограничения на условный include и конструкции вида include('../somePath' + someVar). Но безусловный простой include лучше, чем никакого.

@zakaratcha предлагаю использовать вот такой вариант прямо в bemjson-файлах:

var fs = require('fs'),
    path = require('path'),
    nodeEval = require('node-eval');

function include(filename) {
    return nodeEval(fs.readFileSync(filename, 'utf8'), filename);
}

module.exports = {
     block: 'page',
     content: include('../somePath' + someVar)
};