bem / bem-core Goto Github PK

https://github.com/domenic/sinon-chai

https://github.com/narqo/bem-pr/blob/master/docs/tests.ru.md

• tech-docs tech that creates level
• docs tech that create level

cc @veged

Depends on #46.

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

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

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

See bem-archive/bem-tools#391

We should download bem-dependencies to libs folder so we will type bem make libs to dowload all libraries.

Я думал вносить i-bem.bemtree.xjst из bem-yana-stub в bem-core, но осознал, что результат вызовава BEMTREE.applyAsync() возвращает Vow-промис.

Внимание, вопрос, в bem-core, все это нужно? Или куда это девать?

\cc @veged @arikon @dfilatov

https://github.com/bem/project-stub/tree/bem-core

By analogy with JS (*.browser.js, *.node.js, *.vanilla.js) we can make *.browser.bemtree.xjst, *.node.bemtree.xjst, *.vanilla.bemtree.xjst.

\cc @veged @arikon

Нужно набросать примерный roadmap на проект (отдельным документом), чтобы было понятно, когда планируется отрывать DEPRECATED-методы и на который потом, можно будет ссылаться для обоснования тех или иных решений.

So we can use BEM.DOM.doc for real document interaction and BEM.DOM.scoupe for live-events and so on. In case without _conflicts_no BEM.DOM.doc === BEM.DOM.scoupe.

\cc @dfilatov @veged

Хочу портировать i-request (и соответственно, его _type_ajax) в bem-core. Но меня смущает название. request неоднозначно описывает, зачем этот блок (по крайней мере в технологии node.js).

Предлагаю назвать блок data-provider и реализовать там базовый интерфейс. Потом от него наследовать http-provider (для AJAX и HTTP -запросов в browser.js и node.js соответственно).

Потом можно реализовывать file-provider и пр.

Что скажите?

We need replacement for deprecated $.browser. Variants:

• port $.browser to bem-core as plugin -- The Easiest One
• add all this stuff to ua block -- The Right One

Add deprecation policy document that will describe how features are maintained, deprecated and deleted.

Start of the discussion #35

We should add bower package description as a part of libraries infrastructure to allow installation of bem libs as a bower packages

Some files from common.docs are missed in v1.

It turned out there's difference between code in v1 and in master (before it was removed).

I recovered documentation (#90) but there's at leat some other differencies in .bem folder:

git st
# On branch issues/81@v1
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   .bem/lib/bemhtml.js
#   modified:   .bem/lib/bemhtml/api.js
#   modified:   .bem/techs/bemhtml.js
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   .bem/lib/ometa/
#   .bem/techs/js-i.js
#   .bem/techs/js.js

I don't understand if it's useful or not, please take a look. Also I'm not sure if everything else was synced at the moment you started work on v1.

Depend on #58.

cc @dfilatov

Like in jQuery .one().

Add documentation (or links) and API reference to README.md