Added support for YModules with backward compatibility by rakchaev · Pull Request #606 · bem/bem-bl

rakchaev · 2015-02-12T11:16:27Z

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

qfox · 2015-02-12T11:32:49Z

Great thing! 👍 I'm already want to get it ;-)

arikon · 2015-02-12T13:52:25Z

@rakchaev How and when to use it?

rakchaev · 2015-02-12T15:06:28Z

@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 · 2015-02-12T16:36:48Z

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

arikon · 2015-02-12T16:37:35Z

Realization -> Implementation

It will be more correct (here and in the other files)

rakchaev · 2015-02-12T17:28:56Z

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

arikon · 2015-02-12T17:44:09Z

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 · 2015-02-12T17:45:20Z

These style @module comments are not used in bem-bl

I've found usage of @module comments in bem-bl:

./blocks-common/i-jquery/__debounce/i-jquery__debounce.js: * @module i-jquery__debounce ./blocks-common/i-jquery/__decodeuri/i-jquery__decodeuri.js: * @module i-jquery__decodeuri ./blocks-common/i-jquery/__observable/i-jquery__observable.js: * @module i-jquery__observable ./blocks-common/i-geolocation/i-geolocation.js: * @module i-geolocation ./blocks-common/i-ecma/__json/i-ecma__json.js: * @module i-ecma__json ./blocks-common/i-ecma/__function/i-ecma__function.js: * @module i-ecma__function ./blocks-common/i-ecma/__string/i-ecma__string.js: * @module i-ecma__trim ./blocks-common/i-ecma/__object/i-ecma__object.js: * @module i-ecma__object ./blocks-common/i-ecma/__array/i-ecma__array.js: * @module i-ecma__array ./blocks-common/i-menu/i-menu.js: * @module i-menu ./blocks-common/i-bem/i-bem.js: * @module i-bem ./blocks-common/i-bem/__internal/i-bem__internal.js: * @module i-bem__internal ./blocks-common/i-bem/__dom/_init/i-bem__dom_init.js: * @module i-bem__dom_init ./blocks-common/i-bem/__dom/i-bem__dom.js: * @module i-bem__dom ./blocks-common/b-menu-vert/__trigger/b-menu-vert__trigger.js: * @module b-menu-vert ./blocks-common/i-system/i-system.js: * @module i-system

arikon · 2015-02-12T17:46:00Z

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

rakchaev · 2015-02-12T18:06:02Z

@arikon Yes, we can replace it.

qfox · 2015-02-13T16:50:40Z

@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 · 2015-02-13T17:00:40Z

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 · 2015-02-18T13:31:24Z

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

dfilatov · 2015-02-19T13:47:02Z

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

qfox · 2015-02-19T15:22:23Z

@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 · 2015-02-19T15:22:53Z

@zxqfox blocker for what?

qfox · 2015-02-19T15:23:16Z

@dfilatov For mergin'

dfilatov · 2015-02-19T15:24:25Z

If I were maintainer I wouldn't merge

qfox · 2015-02-19T15:31:18Z

@dfilatov Thank god you are not ;-)

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

deeonis · 2015-02-19T16:08:13Z

@arikon what do you think?

arikon · 2015-02-19T17:01:45Z

@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 · 2015-03-10T09:38:52Z

polite ping @dfilatov

dfilatov · 2015-03-10T09:55:32Z

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

arikon · 2015-03-25T13:43:39Z

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

corpix · 2015-03-26T13:38:35Z

I like this feature. +1 for merge.

andre487 · 2015-03-26T13:44:19Z

+1

narqo · 2015-03-26T20:21:32Z

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

объект BEM остается в глобальной области видимости;
никакие другие блоки из библиотек заворачивать в модульную систему не планируют;
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 · 2015-03-26T20:30:44Z

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

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

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

andre487 · 2015-03-26T21:14:52Z

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

narqo · 2015-03-26T22:11:08Z

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

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

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

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

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

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

qfox · 2015-03-26T22:14:18Z

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

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

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

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

tadatuta · 2015-03-26T22:17:37Z

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

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

qfox · 2015-03-26T22:21:17Z

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

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

qfox · 2015-03-26T22:24:21Z

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

tadatuta · 2015-03-26T22:43:15Z

@zxqfox

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

rakchaev · 2015-03-27T14:17:06Z

@narqo

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

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

Что мешает начать, учетом перечисленного выше, начать использовать ym у себя на проекте и оборачивать в modules.define свои блоки?
modules.define('my-block', function(provide) {
  provide(BEM.DOM.decl('my-block', {···});
});

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

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

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

benefits of module system;

possibility of easy migration to the bem-core library.

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

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

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

rakchaev · 2015-04-06T12:12:00Z

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

Added support for YModules with backward compatibility

8eb88ff

arikon reviewed Feb 12, 2015
View reviewed changes

Codestyle changes

c71a1d5

arikon reviewed Feb 12, 2015
View reviewed changes

Replaced next-tick with BEM.afterCurrentEvent

f2bca15

Uh oh!

Conversation

rakchaev commented Feb 12, 2015

Uh oh!

qfox commented Feb 12, 2015

Uh oh!

arikon commented Feb 12, 2015

Uh oh!

rakchaev commented Feb 12, 2015

Uh oh!

arikon commented Feb 12, 2015

Uh oh!

arikon Feb 12, 2015

Choose a reason for hiding this comment

Uh oh!

rakchaev commented Feb 12, 2015

Uh oh!

arikon commented Feb 12, 2015

Uh oh!

arikon Feb 12, 2015

Choose a reason for hiding this comment

Uh oh!

rakchaev Feb 12, 2015

Choose a reason for hiding this comment

Uh oh!

arikon commented Feb 12, 2015

Uh oh!

rakchaev commented Feb 12, 2015

Uh oh!

qfox commented Feb 13, 2015

Uh oh!

arikon commented Feb 13, 2015

Uh oh!

deeonis commented Feb 18, 2015

Uh oh!

dfilatov commented Feb 19, 2015

Uh oh!

qfox commented Feb 19, 2015

Uh oh!

dfilatov commented Feb 19, 2015

Uh oh!

qfox commented Feb 19, 2015

Uh oh!

dfilatov commented Feb 19, 2015

Uh oh!

qfox commented Feb 19, 2015

Uh oh!

deeonis commented Feb 19, 2015

Uh oh!

arikon commented Feb 19, 2015

Uh oh!

qfox commented Mar 10, 2015

Uh oh!

dfilatov commented Mar 10, 2015

Uh oh!

arikon commented Mar 25, 2015

Uh oh!

corpix commented Mar 26, 2015

Uh oh!

andre487 commented Mar 26, 2015

Uh oh!

narqo commented Mar 26, 2015

Uh oh!

qfox commented Mar 26, 2015

Uh oh!

andre487 commented Mar 26, 2015

Uh oh!

narqo commented Mar 26, 2015

Uh oh!

qfox commented Mar 26, 2015

Uh oh!

tadatuta commented Mar 26, 2015

Uh oh!

qfox commented Mar 26, 2015

Uh oh!

qfox commented Mar 26, 2015

Uh oh!

tadatuta commented Mar 26, 2015

Uh oh!

rakchaev commented Mar 27, 2015