В разделе технологий нет описания технологии "*.priv.js"

[tadatuta]

у нас есть описание двухэтапной шаблонизации как идеи.

при этом не существует какой-то общепринятой реализации технологии priv.js, поэтому не очень понятно, что конкретно о ней написать.

что бы ты написал о priv.js в отрыве от конкретной реализации?

[gorbenko]

Я бы написал как есть, что priv.js — технология для создания view-ориентированной структуры данных. Ну и привел бы ссылки на имеющиеся реализации.

[iamstarkov]

также можно указать на enb-технологию https://github.com/enb-make/enb-priv-js и описать стандарт поддерживаемый ею

[tadatuta]

подумаем над описанием после публикации основного пласта документации по ENB на сайте (хотим успеть его опубликовать к питерскому BEMup-у)

[ilyar]

Полагал что технология для создания view-ориентированной структуры данных это bemtree вместо priv.js, ошибка так думать?

[tadatuta]

@ilyar, так и есть. BEMTREE и priv.js решают одну и ту же задачу: получить на вход данные и вернуть BEMJSON.

Только у BEMTREE существует эталонная реализация в bem-core, поэтому там очевидно, что описывать в документации, а для priv.js общего стандарта не сложилось.

[ilyar]

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

[iamstarkov]

Полагал что технология для создания view-ориентированной структуры данных это bemtree вместо priv.js, ошибка так думать?

нет, не ошибка. и то и другое по сути динамический bemjson.

Только у BEMTREE существует эталонная реализация в bem-core, поэтому там очевидно, что описывать в документации, а для priv.js общего стандарта не сложилось.

у priv.js есть реализация в ENB. Мне больше нравится priv.js так как он без излишнего сахара — если знаешь джаваскрипт, то знаешь и priv.js. Вместе с этим приходит простота использования и скорость работы.

[tadatuta]

@matmuchrapna я не понимаю, что ты подразумеваешь под реализацией в ENB. в ENB есть технология для сборки, которая просто склеивает по депсам файлы с расширением priv.js и к результирующему файлу доклеивает собранный bemhtml.js. она ничего не говорит о том, как реализовывать блоки в технологии priv.js. да, понятно, что это окажутся какие-то js-функции, которые будут принимать некие данные и возвращать bemjson, но я видел по меньшей мере штуки четыре вариации на тему.

но даже если рассматривать конкретную реализацию технологии для сборки, уже возникает вопрос: почему там конкатенируется bemhtml.js, если проекты потенциально могут использовать, скажем, BH или вообще несовместимый шаблонизатор?

[ilyar]

@tadatuta Для priv.js может быть спецификация? Понятие спецификация, может быть применено к технологиям сборки? Спецификация может описывать где вход и где выход, и где можно что то делать зачем то... это возможно?

[tadatuta]

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

тут проблема лишь в том, чтобы договориться и принять одну из реализаций за эталон.

[qfox]

@tadatuta вообще, я думал, что priv.js был временным вариантом на пути к bemtree. Но если уж людям нравится и они его используют — может пусть сами и скажут какая реализация им больше по душе?

Но в любом случае, чтобы их оценивать это надо видеть, а кроме тебя, похоже, эти 4 штуки реализаций мало кто видел :-)

[tadatuta]

@zxqfox, вот пара вариантов, которые нашлись среди старых репозиториев у @mishanga в открытом доступе:

1. https://github.com/mishanga/bemchan/blob/master/blocks/b-chan/b-chan.serve.js (каждый блок экспортирует функцию, получающую глобальный объект, в ключах которого хранятся функции, принимающие контекст и коллбек.
2. https://github.com/mishanga/serp/blob/master/blocks/b-page/b-page.priv.js (каждый блок дописывает в глобальный объект blocks функции, принимающие контекст и возвращающие bemjson.

думаю несложно представить себе прочие варианты: как [1], только синхронно, как [2], только асинхронно, всякие варианты про шаринг кода про генерацию bemjson между сервером и клиентом и т.п.

[qfox]

@tadatuta Ну тогда я вижу только вариант описать обе используемые ;-) Либо описать обе, но одну краем, что мол так тоже бывает, но вот этот вариант предпочтительнее. На мой взгляд асинхронный вариант лучше.

[veged]

есть ещё варианты в https://github.com/bem-node/bem-node и https://github.com/sbmaxx/bem-priv

[iamstarkov]

вариант технологии широко используемой в нескольких группах разработки яндекса https://github.com/maxvipon/priv-js, надо сказать, что он прошёл проверку временем и хорошо и быстро работает, удобен в отладке

[veged]

@matmuchrapna почему в https://github.com/maxvipon/priv-js blocks.declare и blocks.exec? кажется, что надо или decl/exec или declate/execute — иначе неконсистентненько

[veged]

@matmuchrapna а ещё не хватает примера про переопределения с вызовами базовой функциональности

[iamstarkov]

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

[iamstarkov]

@matmuchrapna почему в https://github.com/maxvipon/priv-js blocks.declare и blocks.exec? кажется, что надо или decl/exec или declate/execute — иначе неконсистентненько

справедливо, но мне не приходило это в голову