Наверное, в некий modules.define('api-client', ..., в который сложить js-файл в отдельном блоке, и его звать в коде, и прописать в зависимости. Наружу отдавать, например, просто объект с пачкой методов — дружелюбные прокси для вызова приватного метода с разными параметрами.

По второму: все зависит от того, насколько это тебе мешает. Технически, часто такое делают в bemtree, но если тебе хватает простого bemjson — вполне нормально. У нас на морде, пока нет полноценных js шаблонов, многое собирается bemer'ом. Тоже bemjson в сыром виде лежит. И удобно ;-) upd Главное, не забыть подгрузить стили и скрипты (или сразу, или когда надо...).

Ну и если не лениво поразбираться — есть еще https://github.com/enb-make/enb-bembundle

Соглашусь с @zxqfox. С разделением на блоки можно пойти еще дальше и сделать блок request, который бы предоставлял низкоуровневое API про ajax-запросы (кэширование, ретраи, обработка ошибок, etc), а api-client в свою очередь будет зависеть от request и предоставлять уже высокоуровневые методы, которые знают про предметную область проекта.

+1 @tadatuta у нас именно так;)

Спасибо всем за ответы!

@zxqfox

многое собирается bemer'ом

Прочитал доку. не понял зачем он нужен. В чем преимущество перед bh например. Или bemer что то другое делает?

@kompolom Просто у нас нет bh ;-) А bemer показался лайтовым таким и независимым от предрассудков. Я ляпнул, и как-то само все понеслось на нем.

@zxqfox

Наверное, в некий modules.define('api-client', ..., в который сложить js-файл в отдельном блоке, и его звать в коде, и прописать в зависимости.

https://ru.bem.info/libs/bem-core/v2.6.0/touch-pad/i-bem/docs/#Блоки-миксы-1 Такие блоки не подойдут? Я, правда из документации не совсем понял в каких ситуациях нужно использовать блоки-миксы.

Это уже дело вкуса, как их собирать.

Достаточно будет и

modules.define('require', function (provide) {
  provide({ get : function ... });
});
modules.define('api-client', ['request'], function (provide, request) {
  provide({ getUsers: function () { return request.get({ 'what': 'users' }); });
});

А после в своих блоках зовешь api-client и дергаешь его методы.

Ок. Представим что спустя какое то время появится другой блок, который будет ходить в другое api. Это решится модификатором на api-client?

Вполне, все зависит от кода внутри api-client. Если будет другое апи, опять же, я бы сделал api2-client, но все это на усмотрение разработчика.

И еще мысль. Если bemjson сильно развесистый. есть вариант его тоже тягать по ajax ? Если есть, то как такую конструкцию лучше организовать. (сервер на php)

В этом случае спасает bemtree или priv.js ;-). Ну и gzip еще.

@zxqfox Я имел ввиду тягать шаблон отдельно от данных.

Шаблоны само собой. Но из данных же bemjson еще нужно собрать, так ведь? Так что и я про них же ;-)

То есть, ты предлагаешь собрать bemjson на сервере, и передавать сразу bemjson?

Не, я предлагал рассмотреть вариант сборки bemjson на морде с помощью bemtree. С другой стороны, можно и на сервере — возможно gzip не так уж и плох.

Пока осознание bemtree так и не пришло ещё :) @zxqfox можешь простой пример "из жизни" привести data -> bemtree -> bemjson или data -> priv.js -> bemjson ?

Ну вот прям из жизни обязательно? ;-)

Свой рандомный код:

function makeBemjson(data) {
  if (typeof data === 'string') return data;
  switch (data.block) {
    case 'block1':
      return { block : data.block, content : renderViaSmarty(data) };
    default:
      return {
        block : data.block,
        content : [].concat(data.content).apply(this).map(makeBemjson);
      };
    case 'page':
      return {
        block: 'page',
        styles: data.url + '.css',
        content: {
          elem : 'wrapper',
          content : [].concat(data.content).apply(data).map(makeBemjson)
        }
      };
  }
}

priv.js: https://github.com/maxvipon/priv-js bemtree: https://github.com/bem/bem-forum/blob/master/wrapper.blocks/page/page.bemtree ;-)

@belozyorcev Основная мысль в том, что есть bemjson, полно отражающий суть содержимого страницы. Это, в какой степени, данные, но не простые, а адаптированные к выводу. Как именно из них сделать html, чтобы браузер смог отрисовать нам страницу, знает трансформация bemhtml. В bemjson, опять же, есть полный набор зависимых блоков, чтобы собрать из кусочков все нужные преобразования, стили, скрипты, но это не сырые данные, которые у нас лежат в базе. И чтобы руками много раз то, что я привел в пример, как «свой рандомный код», люди сначала придумали priv.js, а после придумали, как посредством синтаксиса, близкого к bemhtml, из сырых данных получать bemjson, готовый к отрисовке, или чтобы отдать верстальщику и показать, например, баг ;-).

Из этого и растет «двупроходная шаблонизация» — сначала мы из данных получаем некий промежуточный результат в виде bemjson, который можно отдельно и параллельно разрабатывать и тестировать, а после из этого bemjson уже проверенными методами получаем html, который тоже получается заведомо стабильным. Кроме того, эти преобразования получаются миниатюрными и их можно легко тестировать, не боясь, что тесты сами собой превращаются в кашу. И получается, что выделение bemjson, как необходимого шага (но создающего двупроходность ;-), дает огромное кол-во плюсов.

А айда писать плюсы?:) Ср, 25 марта 2015 г. в 0:50, Alexej Yaroshevich notifications@github.com:

@belozyorcev https://github.com/belozyorcev Основная мысль в том, что есть bemjson, полно отражающий суть содержимого страницы. Это, в какой степени, данные, но не простые, а адаптированные к выводу. Как именно из них сделать html, чтобы браузер смог отрисовать нам страницу, знает трансформация bemhtml. В bemjson, опять же, есть полный набор зависимых блоков, чтобы собрать из кусочков все нужные преобразования, стили, скрипты, но это не сырые данные, которые у нас лежат в базе. И чтобы руками много раз то, что я привел в пример, как «свой рандомный код», люди сначала придумали priv.js, а после придумали, как посредством синтаксиса, близкого к bemhtml, из сырых данных получать bemjson, готовый к отрисовке, или чтобы отдать верстальщику и показать, например, баг ;-).

Из этого и растет «двупроходная шаблонизация» — сначала мы из данных получаем некий промежуточный результат в виде bemjson, который можно отдельно и параллельно разрабатывать и тестировать, а после из этого bemjson уже проверенными методами получаем html, который тоже получается заведомо стабильным. Кроме того, эти преобразования получаются миниатюрными и их можно легко тестировать, не боясь, что тесты сами собой превращаются в кашу. И получается, что выделение bemjson, как необходимого шага (но создающего двупроходность ;-), дает огромное кол-во плюсов.

— Reply to this email directly or view it on GitHub https://github.com/bem/bem-forum-content-ru/issues/314#issuecomment-85707943 .

@verybigman Думаю главный плюс это простые шаблоны, что открывает простор для реиспользования. На самом деле в php, по моим ощущениям подобного инструмента не хватает, чувствуется, что нужна небольшая прослойка.

О да, еще как чуствуется... У нас на велосипеде в модулях каша теперь. Стало сильно проще в шаблонах, но немного сложнее в модулях. И это усложнение явно нужно унести в еще одни шаблоны. Фактически, тот же путь, что и с priv.js/bemtree.

@zxqfox т.е. шаблоны - мы можем тягать с проекта в проект, в bemtree только для конкретного проекта подтачиваются?

@belozyorcev Не обязательно. Тут опять же смотря как их писать.

Вот есть у тебя формы — bemtree будут очень полезны, чтобы из схемы типа:

{
  id : { type: 'integer', caption: '#', default: 1, sequence: 'yolo' },
  name : { type: 'string', caption: 'Name' },
  country : { type: 'integer', viewtype: 'select', data: countries },
  // etc.
}

сделать bemjson для формы. А после, когда приедут данные из формы, отвалидировать, что число в country является существующим id страны из списка доступных стран, например. И алгоритм сборки такой схемы никак не зависит от проекта, но зависит от набора блоков, которые он использует.

А если собирать страницу, и в ней явно указывать блоки, которые нужно отрисовать, то страница тоже будет зависеть от имеющихся блоков, но её структура врядли будет удобна для двух разных сайтов.

Но т.к. bemtree, как и bemhtml/bh, можно доопределять (в теории, совершенно как угодно), то мы легко можем создать такой набор базовых шаблонов для формы, который подойдет большинству, и нужные фичи они либо подключат модификаторами, либо доопределят на уровне проекта. Со страницами, конечно, такое тоже возможно, но боюсь, что сложность будет зашкаливать и, кажется, проще научить писать bemtree, чем учесть даже не все, но какую-то значимую часть различных страниц. Думаю, со страницами еще играет скорость их изменения — кто мог подумать о нестандартно скроллящихся, например, или об SPA лет 10 назад? ;-) С формами, в этом отношении, все намного проще.

В общем, по-разному ;-).

@zxqfox Мне кажется, путь priv.js проще в реализации. Технологией не пользовался, по информации из ШРИ это просто набор функций который принимает данные и выдает bemjson. В проектировании у меня все глухо. Так что вопрос как их впихнуть в проект.

priv.js по архитектуре похож на bh.js. Есть ядро, есть декларации матчеров, есть их функции, есть входные данные, которые проходят по этим матчерам, есть результат. bemtree, на самом деле, технически имеет ту же самую архитектуру, просто выглядит иначе и запустить его чуть сложнее.

Единственное, что важно, это в каком окружении ты хочешь их запускать. На морде — надо будет собирать ядро и шаблоны на морду, с готовыми технологиями для сборщика в этой части беда, но выглядят они не сильно сложными, на мой взгляд — логика один в один с bh.js, просто файлы другие.

В пхп — проще портировать ядро (оно там 100 строк) и писать шаблоны на пхп, опять же, технологии для сборки с bh.php сдернуть, тоже должны подойти (ядро + пачка деклараций матчеров).

p.s. че-то я сам призадумался, может быть с priv-php заморочится ;-)

может быть с priv-php заморочится ;-)

Мне идея нравится. :thumbsup: Интересно, что остальные бэм-пхпшники думают по этому поводу.

в продолжение темы про api-client. В предложенном варианте, будет для каждого блока создаваться новый инстанс api-client. Можно как то этого избежать?

Если нужен один инстанс на всех - то можно сделать примерно так:

modules.define('api-client-instance', ['api-client'], function (provide, ApiClient) {
    provide(new ApiClient);
})

и зависимости прописывать уже от api-client-instance

provide(new ApiClient); только один раз вызовется?

да