Модульная система для js

[dfilatov]

Для решения проблем:

• Избавление от зависимости от jQuery того кода, который от него в реальности не зависит
• Избавление от глобальных неймспейсов
• Реальная асинхронность деклараций модулей
• Возможность писать одни и те же модули для браузеров и серверных движков
• Возможность додекларации модулей

начинаем использовать модульную систему https://github.com/ymaps/modules.

[ikokostya]

Объясните, почему вы не хотите переименовать i-bem в bem, так же как, например, i-jquery в jquery?

[dfilatov]

\cc @veged @arikon @vithar

[veged]

@ikokostya потому что переименование сильнее ломает обратную совместимость с существующим кодом

[mdevils]

@veged Так совместимости уже совершенно не будет. Мало того, что все файлы теперь оборачиваются в модули, так еще и немало депсов меняется. В результате получается, что i-bem единственный блок с префиксом, который вообще остается. Кажется, что это не только можно, но и нужно изменять.

[mdevils]

@veged Кстати, а добавить еще один повод залезть в депсы и поменять их — это очень даже хорошо. Может, разработчики наконец-то синхронизируют реально используемые депсы с тем, что прописано в must/should-deps, не полагаясь на особенности работы технологии deps.js.

[narqo]

А в чем проблема названия i-bem? Теперь есть блок next-tick — «префикс» next- никого не смущает? ;)

ИМХО, i-bem — название не чуть не хухе jQuery, Node.js и пр.

Дальше, offtopic

@mdevils

Так совместимости уже совершенно не будет...

На всякий случай, i-bem это не только клиентский JS — там еще BEMHTML-шаблоны, а на «некоторых» проектах еще и bemtree, BEM.JSON («Блоки первичны — технологии вторичны. БЭМ, все дела...»)

Может, разработчики наконец-то синхронизируют реально используемые депсы с тем, что прописано в must/should-deps, не полагаясь на особенности работы технологии deps.js.

Опиши, как ты это представляешь? У нас 150+ блоков которым нужен базовый шаблон из i-bem__html и им в принципе пофиг откуда (с какого уровня переопределения) он придет.

[ikokostya]

@narqo Модуль next-tick провайдит nextTick. Модуль i-bem провайдит bem, а не iBem. Хорошее название? Что означает i-?

[veged]

@mdevils имя модуля это часть его "API", люди пользуются этим чтобы делать переопределения на своих уровнях -- если переименовывать блок, то людям нужно будет на пустом месте переименовывать файлы

про "Так совместимости уже совершенно не будет." я считал по другому, вроде придумали как обойтись без обёртки для большинства модулей задекларированных через BEM.decl, а депсы меняются только у базовых библиотечных блоков

[veged]

@mdevils про поводы залезть куда-то что-то поправить -- этак можно ваще API перекроить, чтобы разработчики заодно весь свой код на предмет багов прошерстили ;-)

[mdevils]

@narqo Насколько я помню, код из i-bem__html уже переехал в блок bemhtml, который поставляется с пакетом bemhtml, так что здесь проблемы я не вижу.

Опиши, как ты это представляешь? У нас 150+ блоков которым нужен базовый шаблон из i-bem__html и им в принципе пофиг откуда (с какого уровня переопределения) он придет.

Если блок использует BEM.DOM, то он должен от него зависеть. Аналогично с остальными случаями. Сейчас ситуация такова, что некоторые блоки имеют в зависимостях BEM.DOM, а другие не имеют, хоть и используют. Более того, некоторые блоки имеют в зависимостях BEM.HTML, а по факту используют BEM.DOM. То, как сейчас работает deps.js поощряет подобный хаос в зависимостях.

Более того, ситуация с зависимостями сейчас совершенно неверная. Стоит захотеть поменять алгоритм deps.js (например, для ускорения, как я это сделал в ENB), так ломаются не только проекты, но и bem-bl, lego и тп. Получается, мы жестко завязаны на том алгоритме зависимостей, который сейчас присутствует в bem-tools даже при том, что он очень медленный.

Дальше, ситуация с зависимостями сейчас приобретает и совершенно нелепые обороты. Опять же из-за особенностей deps.js. Существуют циркулярные зависимости. Например:

i-common зависит от i-counter, i-counter зависит от i-global, i-global зависит от i-common

Более того, случаются казусы вроде того, что блок logo зависит от своего модификатора logo_lang_ru по mustDeps'ам, рождая не только циклическую зависимость (которую deps.js игнорирует), но и вызывая сомнения в том, является ли это вообще БЭМ-подходом.

[veged]

@mdevils в отдельный пакет переедет только "компиляторная чать", базовые шаблоны останутся в i-bem__html.bemhtml, т.к. их можно переопределять на других уровнях

[veged]

@mdevils проблемы с зависимостями (особенно в LEGO), это отдельный разговор (причём НЕ на внешнем github) -- нужно просто все их поправить -- к переименованию i-bem это отношения не имеет

[mdevils]

@veged Ок. Тогда приведу сжатую мысль: у нас есть шанс поменять многое, сломав обратную совместимость и заставив людей что-то менять в своих проектах. Давайте дожмем-таки и сразу все поменяем, не оставляя костылей, вроде единственного блока с префиксом, чтобы людям не пришлось вновь потом что-то менять.

[veged]

@mdevils Приведу свою сжатую мысль: за несколько лет развития и выпуска новых версий я очень хорошо усвоил один урок -- "если можешь что-то не менять, не меняй" -- любые дополнительные телодвижения по апдейту версии, это дополнительные лучи (не самых хороших субстанций) от пользователей авторам. Давайте будем делать только то, что действительно функционально необходимо (систему модулей, js-синтаксис, новые блоки), а имя трогать вообще не будем, чтобы людям не пришлось что-то менять.

[ikokostya]

@veged Ну вы же затронули уже другие имена (например, jquery, ecma). Оставляя костыли вы только усложняете для пользователей понимание (почему этот блок называется так, а другие иначе). Вы можете ответить на мой вопрос https://github.com/bem/bem-core/issues/4#issuecomment-16289027?

[veged]

@ikokostya jquery и ecma это достаточно низкоуровневые внутренние блоки, их никто особо не использует напрямую (я не знаю случаев, когда их бы переопределяли), поэтому для них сделали исключение (но по хорошему и их можно было оставить со старыми именами)

отвечая на вопрос https://github.com/bem/bem-core/issues/4#issuecomment-16289027 -- прямой связи между именем блока и тем, что он провайдит в глобальный js-спейс, в данном случае, нету (да это выглядит немного неаккуратно, но это не критично)

[ikokostya]

@veged Мы переопределяем оба этих блока. К примеру, jquery блок будет переопределять каждый, кто хочет подключить другую версию jQuery (jquery__config) из своего единого конфига проекта. inherit тоже низкоуровневый блок? Я считаю, что нет, однако у него нет префикса i-. Я так и не получил ответа, что означает i-?

[dfilatov]

На всякий случай упомяну, что потеря обратной совместимости все-таки будет.

[veged]

@ikokostya если есть понимание, что уже сейчас на проектах есть свои определения для i-jquery и i-ecma, то их нужно переименовать обратно в префиксный вариант

@ikokostya что означает i- не так важно, т.к. за время жизни этого префикса он несколько раз менял свою семантику -- формально, последнее: i- это блоки-хелперы без собственного визуального представления

@dfilatov давай выпишем все места про потерю совместимости и ещё раз подумаем, что из них является обязательным, а что можно оставить не меняя

[dfilatov]

Кстати, давайте решим как все-таки правильно именовать то, что провайдят модули, я все-таки в сомнениях. Примеры того, как дело обстоит сейчас:

• есть файл next-tick.js, в нем провайдится модуль с именем nextTick
• есть файл functions.js, в нем провайдится модуль functions
• есть файл functions__throttle.js, в нем провайдится модуль functions.throttle
• есть файл i-bem__dom.js, в нем провайдится модуль с именем i-bem.dom

[dfilatov]

@veged, Примерный changelog того, что произошло:

• i-bem больше не зависит от jQuery (только i-bem.dom)
• i-bem теперь просто модуль, а не базовый класс для всего-всего
• добавлены модули objects, functions
• $.observable -> модуль events
• $.inherit --> inherit + миксины
• $.throttle --> function.throttle, $.debounce --> function.debounce
• $.decodeURI, $.decodeURIComponent -> модуль url
• channels -- отдельный модуль вместо BEM.channel
• nextTick -- отдельный модуль вместо BEM.afterCurrentEvent
• jQuery теперь грузится не из верстки с помощью модуля loader
• destruct теперь onSetMod js ''
• блок i-system распилен на 2 модуля: idle и tick
• e.data.domElem -> e.domElem
• убраны все deprecated-методы

[ikokostya]

@dfilatov Вроде хотели убрать url из core?

[dfilatov]

@ikokostya, да url не будет в core

[veged]

@dfilatov именование провайдов пока выглядит консистентным -- в чём твои сомнения?

[dfilatov]

конкретно в маппинге имен файлов на имена модулей: next-tick.js --> nextTick i-bem__dom.js --> i-bem.dom

[veged]

ну типа dash-delimited -> camelCase и __ -> .

[ikokostya]

@veged Вот именно, что сейчас i- не имеет смысла, т.к. у блоков больше нет префиксов. Напишите скрипт для миграции депсов. Не вижу проблемы.

[dfilatov]

@veged, еще появятся модули лежащие в модификаторах, какой маппинг для них будем использовать?

[veged]

@ikokostya префиксы никогда не были обязательными и сейчас они не стали запрещёнными — это всё опционально, может быть, а может не быть, никаких проблем

скрипт миграции: 1) не покрывает всего (есть ещё кроме deps завязки); 2) даже со скриптом нужно ещё приглядывать за правильным и полным результатом; 3) название i-bem использовалось в докладах и статьях и там скрипт миграции вовсе бессилен

[ikokostya]

@veged 1,2) Я этого и не отрицаю, все равно придется что-то поправить, но рутинную работу он выполнит. 3) changelog никто не отменял.

[veged]

по чейнджлогу:

• i-bem теперь просто модуль, а не базовый класс для всего-всего
  • что это означает для пользователей?
• добавлены модули objects, functions
  • а какая семантика? хелперы по работе с объектами и функциями?
• $.observable -> модуль events
• $.inherit --> inherit + миксины
• $.throttle --> function.throttle, $.debounce --> function.debounce
• $.decodeURI, $.decodeURIComponent -> модуль url
• channels -- отдельный модуль вместо BEM.channel
  • а старое API через BEM.channel сохранено?
• nextTick -- отдельный модуль вместо BEM.afterCurrentEvent
  • BEM.afterCurrentEvent использует nextTick?
• jQuery теперь грузится не из верстки с помощью модуля loader
  • динамически? а это не медленнее чем раньше?
• destruct теперь onSetMod js ''
  • но остался специальный кейс для указания onSetMod: { js: function() {} }?
• блок i-system распилен на 2 модуля: idle и tick
  • это нужно?

[veged]

@ikokostya повторю основную мысль -- безотносительно того, что что-то прийдётся поправить, наша задача сделать так, чтобы поправлять надо было как можно меньше (плюс некоторые вещи типа записанного видео невозможно поправить, нужно отдельно прикладывать усилия по донесению новой информации)

[veged]

@dfilatov про именование я вдруг осознал, можно провайдить по бэм-идентификаторам:

• есть файл next-tick.js, в нем провайдится модуль с именем next-tick
• есть файл functions.js, в нем провайдится модуль functions
• есть файл functionsthrottle.js, в нем провайдится модуль functionsthrottle
• есть файл i-bemdom.js, в нем провайдится модуль с именем i-bemdom
• есть файл с модификатором my-block_mod_val, в нём провайдится
  • my-block, если мы насыщаем предыдущий модуль
  • my-block_mod_val, если мы провайдим отдельный модуль

[dfilatov]

по чейнджлогу:

• i-bem теперь просто модуль, а не базовый класс для всего-всего
  • что это означает для пользователей?
  • в основном то, чтобы больше можно не делать упячку с наследованием от BEM-блока всех сущностей, когда это не имеет никакого смысла. По факту, надо признать, что ни одного BEM-блока (именно BEM, а не BEM.DOM), который использует BEM-предметную область хоть как-то никто так и не написал.
• добавлены модули objects, functions
  • а какая семантика? хелперы по работе с объектами и функциями?
  • да
• $.observable -> модуль events
• $.inherit --> inherit + миксины
• $.throttle --> function.throttle, $.debounce --> function.debounce
• $.decodeURI, $.decodeURIComponent -> модуль url
• channels -- отдельный модуль вместо BEM.channel
  • а старое API через BEM.channel сохранено?
  • нет
• nextTick -- отдельный модуль вместо BEM.afterCurrentEvent
  • BEM.afterCurrentEvent использует nextTick?
  • нет
• jQuery теперь грузится не из верстки с помощью модуля loader
  • динамически? а это не медленнее чем раньше?
  • сделаем в этом модуле ветвление, если на странице уже есть jQuery, то будем провайдить его, если нет, то будем пытаться загружать
• destruct теперь onSetMod js ''
  • но остался специальный кейс для указания onSetMod: { js: function() {} }?
  • нет
• блок i-system распилен на 2 модуля: idle и tick
  • это нужно?
  • да, это все-таки разные вещи

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

[dfilatov]

@veged, во всех DOM-блоках будет определение выглядеть примерно так:

modules.define('i-bem__dom', function(provide, DOM) {

provide(DOM.decl('b-my-blocks', { ... }));

});

То есть происходит постоянное насыщение модуля i-bem__dom. Иначе непонятно, кто потом будет реквайрить каждый DOM-блок в отдельности.

[narqo]

@dfilatov а provide(BEM.blocks['b-my-block']) не будет работать?

[narqo]

i-common зависит от i-counter, i-counter зависит от i-global, i-global зависит от i-common

Это нормальная ситуацию, как бы странно это не звучало (и, да, мне это тоже не нравится, поскольку достаточно огребал проблем с этого): частично помогут depsByTech, как только они доберутся до продакшна.

[dfilatov]

@narqo, а как b-my-block окажется в BEM.blocks, если еще никто decl не звал для него?

[dfilatov]

@veged, у меня есть желание оставить i-bem только для DOM-части (то, для чего он оказался реально полезен), то есть -- смержить i-bem и i-bem__dom в один модуль i-bem, отвечающий за DOM-блоки.

[narqo]

@dfilatov, я имел ввиду, сначала в теле define-а BEM.DOM.decl(..), а потом provide(BEM.blocks[..]) — но кажется, я не правильно понял твою мысль выше :(

[dfilatov]

@narqo, так как ты пишешь можно писать, это ровно тоже самое, только длиннее.

[narqo]

@dfilatov, подумал, а DOM-блокам обязательно, что-то провайдить? Разве их нельзя просто оборачивать в

modules.require(['i-bem__dom'], function(DOM) { 

...

})

?

[mdevils]

@narqo В таком случае не написать

modules.require('i-bem__dom', function(DOM) {
    DOM.init();
});

[mdevils]

Вариант обертки bem-controls: https://github.com/ymaps/bem-controls

[narqo]

В таком случае не написать...

@mdevils, объясни, почему? По коду ym я не смог понять принципиальной разницы.

[mdevils]

@narqo Если мы выполняем DOM.init, то необходимо убедиться, что все DOM-декларации были выполнены. Если одна из деклараций зависит от чего-либо, что загружается асинхронно, то надо подождать каждую из таких деклараций. Соответственно, два пути. Либо декларировать все под i-bem__dom, либо писать modules.require(['i-bem__dom', 'input', 'button', 'checkbox', ... ], function(DOM) { DOM.init(); });

[dfilatov]

По итогам сегодняшнего разговора я внес следующие изменения:

• модуль url теперь называется uri
• channels переехал в events__channels
• jquery__cookie переехал в cookie и больше не зависит от jquery
• добавлен модуль vow

Также, скрипя сердцем, я "воскресил" на одну версию и пометил как deprecated следующие методы в i-bem:

• afterCurrentEvent
• changeThis
• channel
• destruct И добавил на одну версию фолбэк для onSetMod_js, преврающий его в onSetMod_js_inited.

[mdevils]

Предлагаю в deprecated-методах писать в консоль варнинг о том, что методы deprecated.

[mdevils]

Не хватает events__channels в shouldDeps i-bem

[veged]

бранч feature/modules замёржил в dev