Не работает тест блока с bemhtml

dragn commented 9 years ago

Не работает тест для блока с технологией bemhtml. Вот здесь собран минимальный проект: https://github.com/dragn/enb-bem-specs-test.

По сути не срабатывает рендеринг шаблона bemhtml. Интересно, что если заглянуть в бандл файл desktop.specs/test-block/test-block.bemhtml.js, можно найти такие строки:

    if (__$t === "content") {
        if ($$block === "spec-runner" && !$$elem) {
            ...
        }
        return __$ctx.ctx.content;
        if ($$block === "test-block" && !$$elem) {
            return "hello, world";
        }
    } else if (__$t === "tag") {
        ...

Перед кодом моего блока стоит return! Если копнуть глубже, этот return прилетает из файла bem-core/common-blocks/i-bem/i-bem.bemhtml. Последняя строка оттуда:

...
content()(function() { return this.ctx.content; });

tadatuta commented 9 years ago

@dragn проблема в порядке сборки из-за неполных зависимостей. см. фикс https://github.com/dragn/enb-bem-specs-test/pull/1

dragn commented 9 years ago

О да! Я знал, что что-то не так с зависимостями. Спасибо. Однако, было бы неплохо, если бы в этом случае возникала понятная ошибка...

tadatuta commented 9 years ago

@dragn Непонятно, как это понять. Здесь все в точности, как с CSS:

.block {
    font-size: 18px;
}

.block {
    font: 12pt/10pt sans-serif;
}

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

dragn commented 9 years ago

Тут, в принципе, не в порядке включения зависимостей дело. Просто получается, что bemhtml шаблон блока вообще не сработает, если в зависимостях не указать i-bem, или нет?

Guria commented 9 years ago

@dragn видимо вы правы. Только что обсуждали: https://github.com/bem/bem-components/issues/1351

tadatuta commented 9 years ago

если совсем точно, то шаблон вообще не сработает, если код i-bem.bemhtml не окажется выше. его по зависимостям может позвать другой блок, от которого зависит данный (или даже не зависит и просто повезло).

поэтому проверять на обязательное наличие зависимости от i-bem не факт, что нужно вообще всегда.

Guria commented 9 years ago

@tadatuta если любой bemhtml блок нуждается в i-bem.bemhtml, почему это знание не вынесено на уровень сборщика и требует обязательного указания в зависимостях?

tadatuta commented 9 years ago

@Guria Причин несколько. Во-первых, это поведение является специфичным именно для bem-core. Скажем, в bem-bl базовые шаблоны лежат в i-bem__html.bemhtml. И никто не может гарантировать, что у других ребят не окажется все еще как-то по-другому.

Во-вторых, непонятно, где это выразить на уровне сборщика. Сборщик получает декларацию (bemjson.js или bemdecl.js) и строит по ней bundle.deps.js. Далее на основе полученных депсов он собирает блоки. При этом о существовании bemhtml-шаблонов он узнает уже после того, как депсы построены.

В-третьих, на проектах чаще всего есть page, у которого нужные зависимости прописаны и все потомки будут работать как ожидается. Хотя, конечно, правильнее писать честные зависимости для каждого блока.

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

dragn commented 9 years ago

Не является ли это багом в bem-core? Зачем там вообще эта строчка content()(function() { return this.ctx.content; }); ?

tadatuta commented 9 years ago

эта строка определяет поведение моды content() по умолчанию. без нее поле content в bemjson не будет иметь никакого специального смысла.

dragn commented 9 years ago

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

Guria commented 9 years ago

@dragn Это как раз я и подразумевал в своём вопросе о переносе знания в сборщик. @tadatuta Попробую переформулировать. bemjson, как я понимаю имеет уже устоявшийся формат и по сути шаблоны из i-bem.bemhtml описывают стандартные преобразования. Не понятно почему в случае bemhtml эти шаблоны хранятся в библиотеке блоков, а для BH тоже самое поведение вшито в библиотеку самого BH. Может стоит вынести реализации технологий bemtree и bemhtml как независимые подключаемые технологии?

tadatuta commented 9 years ago

@Guria Подход, при котором базовые шаблоны являются именно шаблонами, а не зашиты в библиотеке, позволяет очень гибко влиять на результат — сейчас есть возможность переопределить буквально все. Более того, любой BEMHTML-шаблон — это и есть переопределение базового шаблона.

Кроме того, такое разделение позволяет отдельно развивать компилятор, который может быть использован не только для нужд БЭМ или шаблонизации (например, на xjst можно написать роутер).

Еще одна причина держать базовые шаблоны в bem-core — это тесная связь шаблонизатора и других технологий. Например, когда мы перешли с использования onclick на data-bem в i-bem.js, нам потребовалось изменить и базовые шаблоны. Аналогично технологии для локализации должны быть ощими между клиентским кодом и шаблонами. И релизить изенения по частям нельзя.

enb / enb-bem-specs

Не работает тест блока с bemhtml #18