Implemented bh.require

[blond]

Resolved #151

[mishanga]

В документацию добавишь?

[blond]

добавил

[mishanga]

А теперь главный вопрос: зачем это всё? :) Какую задачу решаем?

[blond]

А теперь главный вопрос: зачем это всё? :) Какую задачу решаем?

Вовремя ))

Причины 2:

1. Консистентность с BEMHTML. Там будет или require('dep') или this.require('dep').
2. Интуитивность. Кажется, что если в коде встретить bh.require('dep'), то будет очевидно что он делает.

[mishanga]

Я в целом не против влить эти изменения, но хочу поговорить. Мне не нравится неконсистентность: класть в lib можно только руками прямым присваиванием, а брать оттуда через require.

[qfox]

Как-то этот ваш lib попахивать начинает. ;-( Зачем вообще придумали require в шаблонизаторе?

p.s. в целом, это лучше, чем прямое присваивание, имхо, но действительно ли это нужно?

[blond]

Мне не нравится неконсистентность: класть в lib можно только руками прямым присваиванием, а брать оттуда через require.

Я рассматриваю bh.lib как нечто служебное, нужное только в момент сборки / правильного получения зависимостей из разных модульных систем.

Есть какие-то мысли как это явно выразить в коде? Или хочется нормального интерфейса и для прокидывания зависимостей?

Как-то этот ваш lib попахивать начинает. ;-( Зачем вообще придумали require в шаблонизаторе?

Это вброс по поводу «А зачем кому-то использовать внешние зависимости?». Если так, то просто потому, что постоянно кому-то этого не хватает.

p.s. в целом, это лучше, чем прямое присваивание, имхо, но действительно ли это нужно?

Оно это подключение зависимостей или сахар в виде bh.require?

[qfox]

Это вброс по поводу «А зачем кому-то использовать внешние зависимости?». Если так, то просто потому, что постоянно кому-то этого не хватает.

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

Оно это подключение зависимостей или сахар в виде bh.require?

Сахар, конечно.

[blond]

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

Это же просто агригатор (сахар) из модульных систем.

Тоже самое что подавать конфиг для broweserify или webpack и на выходе получать какую-то сборку. Только там инструмент для всего, а тут ENB-технология для конкретных случаев.

Сахар, конечно.

Так кому сахар может навредить?

[qfox]

Так кому сахар может навредить?

Дело же не в сахаре, а в возможности прокидывать всякую каку в шаблоны. С точки зрения require и, возможно, define, чтобы писать в .lib — сахар слишком сладкий, не?

Только там инструмент для всего, а тут ENB-технология для конкретных случаев.

Но мы же тут не в репе ENB-технологии, а в репе шаблонизатора...

[blond]

Но мы же тут не в репе ENB-технологии, а в репе шаблонизатора...

Считай, что мы говорим о плагине к любому сборщику, ENB это часный случай.

От bh хочется возможности иметь одну точку входа для всякой каки, и одну точку выхода — всё как у людей ;)

Будет странным, если технология сборки будет доопределять BH так, чтобы у него появлялся новый API.

Дело же не в сахаре, а в возможности прокидывать всякую каку в шаблоны.

Если для тебя это зло — то можешь просто этим не пользоваться, ничего же не теряешь.

[mishanga]

@dfilatov что думаешь?

[dfilatov]

Если уж так нужно это, то нельзя ли сделать, как обычно в bh, геттер/сеттер?

bh.lib(name, value);
bh.lib(name);

[blond]

bh.lib(name, value);
bh.lib(name);

По мне норм. Но напомню, что в BEMHTML будет this.require: https://github.com/enb-bem/enb-bemxjst/pull/68

Может сделать геттер/сеттер + алиас?

bh.lib(name, value);
bh.lib(name);
bh.require(name);

[blond]

ping?

[dfilatov]

Я против алиаса. Не надо просто так делать несколько способов достичь одного и тоже результата.

[qfox]

We can do BH.prototype.require = BH.prototype.define = whatever = bh.lib; on the enb-bh level.

Так кому сахар может навредить?

Диабетикам же.