Specification for examples' building process

[narqo]

\cc @mishaberezin @arikon @blond

[arikon]

С остальном всё вроде понятно

[blond]

Из описания не очень понятно, что должно получиться в результате, если:

PRJ/
  common.blocks/
    button/
      button.examples/
        10-simple.blocks             [1.3]
        10-simple.bemjson.js         [1.1]
  desktop.blocks/
    button/
      button.examples/
        10-simple.blocks             [1.4]
        10-simple.bemjson.js         [1.2]

[blond]

В спеке не сказано зачем и по какому принципу выбираются префиксы, например 10-, 15- и т.д.

[blond]

Не очень понятно, чем отличаются «примеры для демонстрации функционала» и «примеры для тестирования верстки», если для них действуют одни и теже правила.

[blond]

То, что сейчас называется test больше похоже на fixtures для тестов, т.к. эти сущности не отвечают на вопрос плохо или хорошо, их надо кем-то/чем-то проанализировать, чтобы узнать этот ответ.

[narqo]

Из описания не очень понятно, что должно получиться в результате, если...

Возмется пример с «последнего» уровня сета (desktop.blocks в твоем случае) — так договорились когда делали bem-gen-doc. Про это допишу.

В спеке не сказано зачем и по какому принципу выбираются префиксы, например 10-, 15- и т.д.

Это просто часть имени, к которому привыкли «пользователи/разработчики» Лего. Специального назначения у них нет.

Не очень понятно, чем отличаются «примеры для демонстрации функционала» и «примеры для тестирования верстки», если для них действуют одни и теже правила.

«Примеры для тестов» ты не будешь показывать в документации к блоку на bem.info. Это не часть документации, а возможность разработчику протестировать его блок во всех мыслемых/немыслемых ситуациях.

То, что сейчас называется test больше похоже на fixtures для тестов

Их можно использовать в качестве данных для функциональных тестов (например, тестов скриншотами). Это уже как применить.

[arikon]

Префиксы нужны для сортировки примеров в алфавитном порядке. Можно не использовать в случаях, когда сортировка не нужна. С точки зрения БЭМ это просто часть имени блока-примера.

22.01.2014, 10:58, "Andrew Abramov" notifications@github.com:

В спеке не сказано зачем и по какому принципу выбираются префиксы, например 10-, 15- и т.д.

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

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

[blond]

Из описания не очень понятно, что должно получиться в результате, если

А бандлы должны подключиться оба, вначале common, затем desktop, правильно?

Их можно использовать в качестве данных для функциональных тестов (например, тестов скриншотами). Это уже как применить.

Именно поэтому, как мне кажется, использовать название tests не очень честно и не очень правильно. Например, test-fixtures или просто fixtures было бы понятнее.

Это просто часть имени, к которому привыкли «пользователи/разработчики» Лего. Специального назначения у них нет.

Префиксы нужны для сортировки примеров в алфавитном порядке. Можно не использовать в случаях, когда сортировка не нужна. С точки зрения БЭМ это просто часть имени блока-примера.

Может быть стоит добавить это в спеку, чтобы никого не запутать?

[arikon]

@andrewblond

А бандлы должны подключиться оба, вначале common, затем desktop, правильно?

В bem-pr для каждого сета (set) задаются два списка уровней:

• уровни, где искать примеры блоков (в случае с desktop.examples это будут common.blocks и desktop.blocks)
• уровни, с который брать блоки для сборки примеров (для desktop.examples этот будут common.blocks и desktop.blocks из всех подключённых библиотек + локальный для собираемого примера уровень)

[blond]

@arikon, вопрос, кажется, о другом...

Тут надо подключать и 1.3 и 1.4, причем 1.4 может переопределять 1.3? Или же только 1.4?

PRJ/
  common.blocks/
    button/
      button.examples/
        10-simple.blocks             [1.3]
        10-simple.bemjson.js         [1.1]
  desktop.blocks/
    button/
      button.examples/
        10-simple.blocks             [1.4]
        10-simple.bemjson.js         [1.2]

[narqo]

@andrewblond

Тут надо подключать и 1.3 и 1.4, причем 1.4 может переопределять 1.3? Или же только 1.4?

Для сборки 1.2 нужно передать какой-то набор уровней + 1.4; для 1.1 — какой-то свой набор уровней + 1.3.

См. как собираются примеры в bem-components.

Именно поэтому, как мне кажется, использовать название tests не очень честно.

То, что собралось из tests, само по себе является тестом (smoke-tests, в некотором смысле). Ты 1) тестируешь, что все собралось; 2) тестируешь, что то, что собралось, работает так как ты ожидаешь.

fixture — это, обычно, «some known state», операясь на которое ты что-то тестируешь. Таким «стейтом» является «собственный уровень блоков» — то, что 1.3, 1.4 в твоем комменте.

[blond]

Для сборки 1.2 нужно передать какой-то набор уровней + 1.4; для 1.1 — какой-то свой набор уровней + 1.3.

@narqo, спасибо!

То, что собралось из tests, само по себе является тестом (smoke-tests, в некотором смысле). Ты 1) тестируешь, что все собралось; 2) тестируешь, что то, что собралось, работает так как ты ожидаешь.

1) За правильную сборку отвечает сборщик (bem-tools/enb), а тестировать в библиотеке блоков, правильно ли работает сборщик, как-то странно.

2) Когда ты тестируешь, что собралось - ты и есть тест, если вместо себя написать робота - он будет тестом, а получившиеся bemjson/html/css/js и т.д. - это как раз тот самый «стейт» на который тест (ты или робот) опирается.

P.S. Прошу прощения, если я сошёл с ума :)

fixture — это, обычно, «some known state», операясь на которое ты что-то тестируешь. Таким «стейтом» является «собственный уровень блоков» — то, что 1.3, 1.4 в твоем комменте.

Что «собственный уровень блоков» это тоже fixture я согласен.

[narqo]

За правильную сборку отвечает сборщик (bem-tools/enb)

Надо проверить, что у тебя нет опечатки в bemhtml, deps.js или еще где (теоретически, это может проверить линтер, которого нет). Это самый что ни на есть «smoke test»