:+1: я буду пилить:)

Единственное. что сильно останавливает, это патчи в ядро enb и sourcemaps, которые надо будет уметь склеивать при сборке. @blond, как думаешь, какой гемор будет с ними?

p.s. думаю в сторону виртуальных файлов при генерации: .es → виртуальные .js, .js.map, а после в сборке .js клеим просто, .js.map клеим умно и ремапим.

надо)

@zxqfox выглядит любопытно С import/export более менее понятно, а вот с классами не очень. Ты пишешь, что они должны стать абстракцией над inherit, а в примере показываешь конкретную реализацию от i-bem.decl. Это тогда любой класс должен стать БЭМ блоком?

А про sourcemap давно пора в ENB самом поддержку сделать. Досадно, что ребятам пришлось делать копии базовых технологий, чтобы в них добавить sourcemap

@Guria штука в том, что объект BEM внутри использует https://github.com/dfilatov/inherit — и у него через X.decl описывается наследование.

Я сильно не думал, но если есть более логичные варианты — предлагай ;-)

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

@zxqfox я может чего не понимаю, но в inherit я ничего не нашёл про decl. Мне кажется decl только в i-bem определён. Т.е. каким-то образом придётся рулить классы которые транспиляться:

• в синтаксис i-bem
• в синтаксис inherit
• что-либо ещё с возможностью наследования

Что-то мне подсказывает, что это не самый перспективный подход.

@Guria почему-то казалось, что decl из inherit приезжает...

Если это делать плагинами, то вопрос встает про плагины к babel (или траншпилеру). Как вариант, bemClass something extends iBemDom, или смотреть в extends и додумывать как траншпилить.

И как у вас будет ассинхронный provide работать? export же только на верхнем уровне разрешен: https://babeljs.io/repl/#?experimental=true&evaluate=true&loose=false&spec=false&code=doSomething(%20(result)%3D%3E%20%7B%0A%20%20export%20default%20result%3B%0A%7D)%20

@just-boris так ведь export somePromise;, и резолвишь его, когда все ок

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

@just-boris это правда. Но в случае ES6 резолвится они будут синхронно, а грузится — асинхронно. То есть все операции по загрузке должны будут проходить заранее.

OMG! Это именно то, что я хочу сделать!

и ещё вместо onSetMod.js использовать constructor

а что если не транспайлить class myBlock extends iBemDom {...} в var myBlock = iBemDom.decl('my-block', {...})

а сделать версию i-bem, который будет с нативными классами работать?

и отказаться от доопределений

вместо повторного создания описания блока на каждом уровне использовать что-то типа class blocknameCommon extends iBemDom {...} class blocknameDesktop extends blocknameCommon {...}

и static было бы круто заюзать. но пока не очень понятно как

@a-x- надо пробовать)

уже пилю пока натолкнулся на такие проблемы: без $.inherit не будет больше __base, нужно будет писать super.названиеТекущегоМетода

ещё не до конца понятно получится ли сделать работу с модификаторами (UPD: BEM.DOM.decl с модификаторами). но примерно понятно в какую сторону копать

в самом начале ещё возникла такая проблема: в i-bem есть метод-заглушка _extractModVal в i-bem__dom он переопределяется

конструктор i-bem__dom сначала по задумке выставлял поля в this, а потом дёргал конструктор i-bem, но в es6-классах нужно сначала вызвать super, а потом уже трогать this. попытка поменять местами super и эти установки в this (в том числе this.domElem) выявила проблему

вот схема вызовов: i-bemdom.constructor(...) -> i-bem.constructor(...) -> i-bem._init(...) -> i-bem.setMod('js', 'inited') -> i-bem._extractModVal(...) -> i-bemdom._extractModVal(...) -> this.domElem <--- ошибка

тут из-за позднего связывания (а раннего как я понимаю в es6 нет) i-bem хочет получить domElem

решил пока выносом логики про setMod('js', 'inited') из i-bem в i-bem_dom

сейчас пилю на esprima замену всех this.__base на super.названиеТекущегоМетода

...

я упоролся, да...

нашёл пристраннейшее место в i-bem.js

    trigger: function(e, data) {
        this
            .__base(e = this.buildEvent(e), data)
            .__self.trigger(e, data);

два раза вызывается суть один и тот же метод trigger из i-jquery__observable

угораю здесь: https://github.com/bem-kit/es6bem

сейчас как-то работает, но большая часть функционала ещё не починена

CC @veged, JFYI

Я вот тоже задумался о том, чтобы es6 транспилить в ymodules. Решая задачу асинхронности и додекларирования пришёл к такому варианту.

// MODULE: MyModule
import provide from "modules:provide";
import prevDecl from "modules:previousDecl"

setTimeout(function(){
  provide("MyModule" + prevDecl);
}, 5000);

Но в таком случае можно вообще не использовать export и превратится это в примерно следующее:

modules.define("MyModule", [], function(provide, prevDecl) {
  setTimeout(function(){
    provide("MyModule" + prevDecl);
  }, 5000);
});

Вот задумался над вопросом, стоит ли допиливать плагин для бабеля или нет.

Лучше:

export Promise.resolve(42);

прикольно было бы под это рабочее время получить :)

Думал тоже сначала использовать промисы, но такой вариант вынуждает использовать then и в других модулях

import promise from "modA";

promise.then(function(modA){
  ...
});

Если модульная система будет резолвить (ей не сложно), то нет.

import x from 'y';
code…

// условно, →
modules.require('y', function(x) {
  Promise.resolve(x).then(function(x) {
    code…
  }));
});

Согласен. Идея интересная. Единственное придется сделать обертку для самой модульной системы и если экспортируется объект, то тогда нужно проверить каждое свойство на наличие промиса. А это как мне кажется повлияет на производительность, хотя я не спец в этом деле. Для примера приведу такой код:

export {a, b, c, d};
let a = Promise.resolve("a");
let b = Promise.resolve("b");
let c = Promise.resolve("c");
let d = Promise.resolve("d");

В реальной практике такое наверное не встретишь, но пытаюсь рассмотреть все возможные варианты.

и если экспортируется объект, то тогда нужно проверить каждое свойство на наличие промиса

Не думаю, что это хорошая идея.

В реальной практике такое наверное не встретишь

Ножницы сделаны не чтобы глаза ковырять, но некоторые и так их применяют.

Если кровь из носа надо то, что ты с объектом написал, то:

export Promise.all([a, b, c, d]).then([a, b, c, d] => ({a, b, c, d}));

И тогда приезжает 1 промис с твоим объектом когда весь внутряк разрезолвится.