@webtehnology в приведенном сниппете пропущен второй аргумент декларации (onInit — это метод класса, он должен быть указан в объекте, передаваемом третьим аргументом):

Modal.declMod({modName: 'has-close'}, { /* вот тут пустой объект */ }, {
    onInit: function() {}
});

Вот тут опубликовал полный код код для модификатора _has-close, где добавляется крестик и в соответствии с его наличием доопределяется метод setContent().

@tadatuta Спасибо большое!!!!!!!! Вставил просто пустые скобки все сработало, вопрос, почему в Вашем примере по ссылке сделано больше действий, с чем это связано? Например в папке папке __close так же файл, который по сути описывает процесс, получается чтобы сделать элементарное действие нужно создать кучу файлов. При этом все работает, к примеру как в коде ниже, Очень хочется понять алгоритм. Так же может есть примеры вкладок и других вещей которые часто встречаются, что их можно было разобрать и на примерах осваивать.

provide(Modal.declMod({modName: 'has-close'},{}, {
    onInit : function() {
        this._domEvents('close').on('click', function() {
            this.delMod('visible');

        });
    }
}
));

});

И еще вопрос, ниже реализован простенький калькулятор на js, вопрос стоит ли переносить его на БЭМ (только не смейтесь, надеюсь я вскоре пойму основы js на БЭМ) http://animator.web-tehnology.ru/index-10.php

В папке __close написано примерно то же самое, что и в вашем вариенте, т.е. с точки зрения количества кода разницы плюс-минус никакой. То, что код про закрывающий крестик написан в файле про сам крестик, а не про целый блок — это просто из желания держать код максимально локально. Аналогией может служить использование глобальных переменных либо использование переменных из замыкания во вложенной функции в случаях, когда вполне можно было бы обойтись локальными. На результат это особо не влияет.

А дополнительный код в файле модификатора, как я и писал выше, именно про доопределение метода setContent() — он уже относится именно к самому блоку и потому попал в файл модификатора, а не элемента.

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

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

ниже реализован простенький калькулятор на js, вопрос стоит ли переносить его на БЭМ

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

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

Будет очень круто тк мне кажется именно живых примеров и не хватает

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

Очень хочется делать проект от и до по методологии, а не сращивать на этапе сборки разные технологии, но видимо пока очень рано замахиваться. Но отступаться не дело. Большое спасибо за поддержку!

@tadatuta Подскажите. Хочу определить текущий элемент по которому кликнули через e.currentTarget на старой сборке была конструкция типа this.setMod($(e.currentTarget),'state','current'); после обновления, как понимаю нужно выносить $(e.currentTarget), перед setMod

this._domEvents('item').on( 'click', function(e) {
    setMod('state','current');
});

В новом мире это выглядит так:

this._domEvents('item').on( 'click', function(e) {
    e.bemTarget.setMod('state', 'current');
});

@tadatuta а где можно прочитать про эти изменения?

Хотел было написать, что про все изменения написано в миграционном гайде, но решил все-таки проверить и оказалось, что таки не все :)

Завел задачу: https://github.com/bem/bem-core/issues/1472

@tadatuta onElemSetMod остался без иземенний?

@webtehnology удалён: https://github.com/bem/bem-core/blob/v4/MIGRATION.ru.md#Удалённые-методы-и-поля