Added support for YModules with backward compatibility

[vovieque]

Added possibility to use YModules in js files from own bem libraries based on bem-bl.

[qfox]

Great thing! :+1: I'm already want to get it ;-)

[arikon]

@rakchaev How and when to use it?

[vovieque]

@arikon We use the next bem libs stack:

• own bem libs
• islands libs
• bem-bl

We write js files from own bem levels with YModules. It gives

• benefits of module system;
• possibility of easy migration to the bem-core library.

[arikon]

@rakchaev But how do you use it? You just write own project blocks using ym and that's it?

[vovieque]

@arikon Yes. We just write own project blocks using ym. Like blocks of bem-core or bem-components. Thank you for your notes.

[arikon]

I think it's not a good idea just because it's a 1-to-1 copy from bem-core. If these lines will change in bem-core it will be easier to move diff here.

@zxqfox The rule is simple: this code is harder to understand for the ordinal reader than simple if block. So it should be rewritten.

I don't support some of the decisions made for bem-core code style. In my opinion, they are for robots, not for humans.

[arikon]

@rakchaev What do you think of next-tick dependency?

[vovieque]

@arikon Yes, we can replace it.

[qfox]

@arikon I'm for wrapping that block to if in bem-core but it would be harder to sync. Anyway, I'm agree with ya. ;-)

[arikon]

bem-bl and bem-core are separate code bases. I think there is no need to focus on future syncronization (that would not happen at all).

13.02.2015, 19:50, "Alexej Yaroshevich" notifications@github.com:

@arikon I'm for wrapping that block to if in bem-core but it would be harder to sync. Anyway, I'm agree with ya. ;-)

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

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

[deeonis]

@dfilatov could you review plz? there are doubts that we can accept this pr as is

[dfilatov]

I think you shouldn't want this ) It's just increasing the entropy, nothing more

[qfox]

@dfilatov Is it blocker?

@arikon Would it fine for you if we add a comment or rewrite code to if statement?

Any chance to see this in the next release?

[dfilatov]

@zxqfox blocker for what?

[qfox]

@dfilatov For mergin'

[dfilatov]

If I were maintainer I wouldn't merge

[qfox]

@dfilatov Thank god you are not ;-)

upd Ловлю себя на мысли, что я бы тоже не влил ;-) Что если унести на отдельный уровень эти правки и подключать уровень только при необходимости? В отдельную библиотеку уносить тоже вариант, но в bem-bl такое не принято.

[deeonis]

@arikon what do you think?

[arikon]

@dfilatov Дима, прокомментируешь реализацию?

19.02.2015, 16:47, "Filatov Dmitry" notifications@github.com:

I think you shouldn't want this ) It's just increasing the entropy, nothing more

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

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

[qfox]

polite ping @dfilatov

[dfilatov]

@zxqfox I can't add to what I said anything else.

[arikon]

@dfilatov Дима, причины идеологические или технологические?

[corpix]

I like this feature. +1 for merge.

[andre487]

+1

[narqo]

@rakchaev @corpix @Andre-487 вы можете описать, про какие именно «преимущества модульной системы» идет речь, с учетом того, что:

1. объект BEM остается в глобальной области видимости;
2. никакие другие блоки из библиотек заворачивать в модульную систему не планируют;
3. jquery (и его плагины) тоже лежат в global.

Что мешает начать, учетом перечисленного выше, начать использовать ym у себя на проекте и оборачивать в modules.define свои блоки?

modules.define('my-block', function(provide) {
  provide(BEM.DOM.decl('my-block', {···});
});

На мой взгляд, ничего кроме увеличения сложности и запутанности кода, этот pr (речь про пользователей внутренних библиотек) не привносит.

Пример про «запутанность»:

// islands/blocks/button.js
BEM.DOM.decl('button', {
  doSomething() {
    ···
  }
});

// prj/blocks/my-block1.js
modules.define('my-block1', ['i-bem__dom'], function(provide, BemDom) {

provide(BemDom.decl('my-block1', {
  doSomethingMore() {
    //! этот код может нормально работать — 
    //  блок `button` задекларирован вне ym и код его `decl`'а уже выполнился к этому моменту!
    this.findBlockInside('button').doSomething();
  }
}));

});

// prj/blocks/my-block2.js
modules.define('my-block2', ['i-bem__dom'], function(provide, BemDom) {

provide(BemDom.decl('my-block2', {
  doSomethingMore() {
    //! а вот тут никто `my-block1` в массив зависимостей (2й аргумент define) не добавил — 
    //  вообще не факт, что этот код будет работать
    this.findBlockInside('my-block1').doSomethingMore();
  }
}));

});

[qfox]

Я не знаю о каких преимуществах идет речь, но этот фикс позволяет начинать писать блоки в рамках ymodules, и постепенно переводить с i-bem из bem-bl на i-bem из bem-core. Т.к. bem-bl развиваться, явно, не собирается — то этот шаг упростить работу по переезду проектов в ymodules.

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

upd Пример хорош для «порезался об ножницы — нужны царапки», имхо.

[andre487]

Да, действительно смысл в облегчении миграции с bem-bl на bem-core.

[narqo]

upd Пример хорош для «порезался об ножницы — нужны царапки», имхо.

Я готов поспорить, что количество людей которые про это даже не задумаются (не то, чтобы попытаются понять), будет соразмерима с количеством людей которые не понимают зачем писать mustDeps от i-bem__html (возможно это NDA, но да, их много)

[..] этот шаг упростить работу по переезду проектов в ymodules

Возможно я не понимаю, но в чем упрощение? Проекту прямо сейчас можно начать использовать ym:

modules.define('my-button', function(provide) {
  provide(BEM.DOM.decl('my-button', {···});
});

Чем драматически помогает наличие BEMDOM в аргументах provide-функции? Можно примеров?

[qfox]

Я готов поспорить, что количество людей которые про это даже не задумаются (не то, чтобы попытаются понять), будет соразмерима с количеством людей которые не понимают зачем писать mustDeps от i-bem__html

Да нет смысла об этом спорить. Просто есть люди, которым надо переезжать, а есть те, которых и так все устраивает. Фикс-то полезный, но возможно просто не для основной ветки. Думаю, об этом и стоит говорить.

Чем драматически помогает наличие BEMDOM в аргументах provide-функции? Можно примеров?

Тем, что когда все блоки будут описаны таким образом, можно будет, грубо говоря, сделать -bem-bl, +bem-core в зависимостях.

[tadatuta]

Тем, что когда все блоки будут описаны таким образом, можно будет, грубо говоря, сделать -bem-bl, +bem-core в зависимостях.

@zxqfox тебе ли не знать, что заворачивание блоков в модульную систему — это самая простая задача из тех, с которыми придется столкнуться при миграции с bem-bl на bem-core?

[qfox]

тебе ли не знать, что заворачивание блоков в модульную систему — это самая простая задача из тех

Да это понятно, просто без таких правок (даже самых простых) переезжать постепенно становится невозможно. Можно, впрочем, вдобавок сделать в bemhtml: data-bem="каксейчас" onclick="return JSON.parse(this.getAttribute('data-bem')), сделать once = onFirst, и т.д. С моей колокольни этого, думаю, на 95% хватит, чтобы начать переезд.

[qfox]

Просто я не думаю, что можно взять и просто заменить bem-bl на bem-core. Нужны какие-то переходные версии, которые позволят сгладить переезд. Есть и другой вариант — сделать версию bem-core совместимую со старым API. Но ведь это сложнее, правда?

[tadatuta]

@zxqfox

• bem-bl поддерживает data-bem="каксейчас" и переключение полностью обратносовместимо
• bem-core 1.0 поддерживал название методов из bem-bl в статусе deprecated, так что такая промежуточная версия есть

[vovieque]

@narqo

вы можете описать, про какие именно «преимущества модульной системы» идет речь

Привет! Да, попробую.

1.

Что мешает начать, учетом перечисленного выше, начать использовать ym у себя на проекте и оборачивать в modules.define свои блоки?

modules.define('my-block', function(provide) {
  provide(BEM.DOM.decl('my-block', {···});
});

Инициализация блоков (запуск BEM.DOM.init из i-bem__dom_init_auto) может выполниться до того момента, когда будет задекларирован такой блок, пока зависимости его модуля еще не зарезолвены. Поэтому в таком использовании никакого смысла нет.

2.

На мой взгляд, ничего кроме увеличения сложности и запутанности кода, этот pr (речь про пользователей внутренних библиотек) не привносит.

Привносит пользователям библотеки:

• benefits of module system;
• possibility of easy migration to the bem-core library.

3.

Пример про «запутанность»:

//! а вот тут никто `my-block1` в массив зависимостей (2й аргумент define) не добавил — 
//  вообще не факт, что этот код будет работать

Инициализация всех блоков выполнится только после резолва всех объявленных модулей, у которых в зависимостях есть i-bem__dom (см. i-bem__dom.js в PR или в bem-core). Поэтому все будет работать.

[vovieque]

В итоге, чтобы использовать на своем проекте модульную систему ym для реализации блоков на фреймворке i-bem, нужно чтобы ядро об этом знало и выполняло инициализацию всех блоков только после того, как будут определены все модули, в которых происходит декларация блоков. Про это этот PR.