BEMTREE вместо BEMJSON по умолчанию
belozer opened this issue · 58 comments
С этой проблемой столкнулся лично я. С одной стороны выглядит безумием, а с другой оправданно.
Когда я начинал своё знакомство, то городил длиннющий bemjson. Это ад! Я проклинал БЭМ, но верил в него. Городил различные require для подставки кусков bemjson. Кто работал с большим количеством уровне вложенности блоков, тот поймёт. Это страшно. Затем начинает болеть голова... Как ЭТО ВСЁ ВНЕДРИТЬ В ПРОЕКТ, как это вообще можно контролировать, ГДЕ ХВАЛЁННАЯ ПРОСТОТА БЭМ?? Слышал про bemtree, но как его использовать? Я тут только городить иерархию научился. Это ещё сложнее будет, не зря ведь для более опытных оставляют!
Сверстать что-то только на BEMJSON, достаточно трудно. И тем более это отредактировать потом. Потом мне пришлось искать bemtree, т.к. это было единственным решением, которое я видел. И ОПА! Приплыли! Теперь нужно ещё deps файлы прописывать, а то сборка чёт не собирается.
Почему бы не прививать bemtree сразу, если дело к нему идёт в конечном итоге? Человек уже на первых этапах будет знать, что нужно для того, чтобы собирать проект. Не превращать его в монстра. А так получается, что пришёл из чёрного мира всяких jade, где люди писали код маленькими порциями и радовались жизни. Про BEMJSON достаточно только в документации рассказать, а работать нужно СРАЗУ с BEMTREE!
Немного шрифт повысил, но я действительно вижу в этом большую проблему. Особенно когда вижу, что люди воспевают React и косятся при аббревиатуре БЭМ (что это только для "избранных" или тех, кто из Яндекс).
Почему нельзя сразу работать с bemhtml? Мне кажется выплескивать на людей сразу два типа шаблонов затея так се, когда и с одним разобраться то не просто. Может лучше подумать как написать структуру стаба так чтобы не пришлось писать bemjson большой? На мой взгляд bemtree тут никакое не спасение.
Как по мне, предложение правильное. Если писать только bemhtml, в него начинают пихать работу с данными, что не совсем то, чему хочется учить.
Лучше сразу прививать двухслойную архитектуру шаблонизации и делать это сразу в starter-kit — хорошо на мой взгляд.
@awinogradov с bemhtml можно работать сразу и project-stub это подразумевает, только bemhtml преобразует bemjson, в он откуда-то должен взяться. В текущем варианте предполагается, что его пишут руками, а Сергей предлагает генерировать его из bemtree. Я с ним согласен. Не вижу необходимости учить людей писать полотна bemjson руками.
@belozyorcev я в целом согласен с твоим посылом, но тем не менее считаю, что для статичной верстки зачастую без BEMTREE проще. Представь, насколько усложнится Quick Start, если туда придется добавить всю историю про генерацию BEMJSON.
Мы пытались предоставить сразу несколько вариантов стаба в виде генератора на yo, но не потянули поддерживать это дело. Потому что на самом деле вариативность там гораздо богаче: можно продолжать верстатить статику, но с использованием BEMTREE (при чем в качестве источника данных для страниц можно использовать внешнюю модель или класть по отдельному бандлу на каждую страницу), а можно считать, что заготовка должна поддерживать серверную часть (и тут опять куча вариантов). Ну и так далее.
В итоге я сделал https://github.com/tadatuta/bem-bemtree-static-project-stub и https://github.com/tadatuta/bem-express в своем аккаунте, как способ с одной стороны все-таки предоставить BEMTREE из коробки.
Уже даже всего эти три варианта — это уже требует времени, т.к. помимо обновления кода к каждому при апдейте нужно писать ченджлоги, обновлять документацию и туториалы на bem.info. А по какому принципу выбрать один вариант и назначить его единственно верным я не понимаю :(
@tadatuta блок описывает сам себя. Содержит в себе ветку дерева проекта. Я не говорю про отказ от BEMJSON. Я имею в виду смену приоритета для знакомства с блоками. Чтобы на первом ряду был BEMTREE, Но если люди хотят "быстро", то могут ставить ветку с BEMJSON вместо BEMTREE. Да и в одном блоке BEMTREE может описать весь BEMJSON при желании.
А сейчас BEMJSON идёт на первом плане и создаётся ощущение, что в Яндекс так и делают проекты. Чтобы что-то делать на основе project-stub - его нужно перелопатить.
И люди вязнут в этом, причём очень сильно.
Новый подходит получится по принципу "думай глобально, действуй блокально локально"
@vithar учить правильно это затея ок, но массово не работает. Если есть желание распространять на много народу, то надо упрощать. А давать сразу 100500 сущностей с приставкой bem просто потому что... Прям вот совсем неправильно. Если использовать только одни шаблоны можно аккуратно написать приложение в котором bemjson будет ровно столько:
{ block: 'root' }
Который можно сгенерить автоматически. Мол пишите компоненты, все красиво. А потом уже в другом месте с туториалами давать технологии. И если они нужны людям они возьмут, заставлять не надо. Нужен очень простой вход, который затрагивает сразу несколько проблем: компоненты, компоненты и компоненты. Вот прям без сборки там даже всякой.
Из-за проблематики с параноидальной любовью к двухслойной архитектуре, кстати) Существует проблема того, что БЭМ он для больших. Ни у кого нет понимая, что можно написать простое веб-приложение, ведь БЭМ он же повязан на данные, надо же где-то брать bemjson, без него никак. Руками писать это невозможно, нам это не надо. Шаблоны писать на json? Да вы с ума сошли?) Еще и шаблонизатор свой?) два типа шаблонов?) Что?)
Это вот прям совсем не смешно) Если люди хотят писать как они хотят, не надо их заставлять. Попишут плохо, потом поймут(найдут, расскажут, не важно). Ключевое слово попишут. Мы столько раз видим при общении с заграничкой, что при слове бэм, они просто отазываются даже внутрь смотреть. И это еще менее смешно.
@awinogradov Я не понимаю что именно ты предлагаешь, можешь показать на примере?
@awinogradov вот проблема как раз в том, что технологии разбежались и нужно дать человеку стартовый набор самых необходимых инструментов.
Почему нельзя сразу работать с bemhtml?
На мой взгяд умение работать с BEMTREE на первых парах намного важнее? чем с BEMHTML.
Во первых синтаксис BEMTREE более урезан, во вторых он предназначен для создания именно дерева.
А на следующем этапе людям можно говорить так.
"А теперь смотрите, сейчас будет фокус!". Берём, создаём файл block.bemhtml.js
Пишем в него block('block').tag()('header') и у всех наших блоков теперь Html тэг header
Во первых синтаксис BEMTREE более урезан, во вторых он предназначен для создания именно дерева.
@belozyorcev зачем людям какое-то абстрактное дерево?
@awinogradov вёрстка структуры блока, так менее абстрактно )
В bemhtml Действительно начинают городить то, для чего он не предназначен. А всё потому, что с ним знакомятся в первую очередь.
@belozyorcev найди хотябы пару человек, которым просто надо писать шаблоны, чтобы строить дерево. Не из этого чатика. Прям вот так и спроси)
@vithar держи
How I can start with BEM?
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<script type="text/javascript" src="bem-xjst.js"/>
<title></title>
</head>
<body>
<script type="text/javascript">
var app = BEMHTML.compile(function() {
block('root')(
attrs()(function () {
return { aria: 'aria' };
}),
content()(function () {
return [
{ block: 'header' },
{ block: 'main' },
{ block: 'footer' }
];
})
);
block('header')(
tag()('header'),
content()(function () {
return 'Header for your first app on BEM';
})
);
block('main')(
tag()('main'),
content()(function () {
return [
{ block: 'heading', content: 'Write md here' },
{ block: 'md-editor' }
]
})
);
block('heading').tag()('h1');
block('md-editor')(
content()(function () {
return [
{ elem: 'editor' },
{ elem: 'preview' }
]
}),
elem('editor').tag()('textarea'),
elem('preview').tag()('pre')
);
block('footer')(
content()(function () {
return [
'Footer of your first BEM app',
{
elem: 'copyright',
content: 'All rights reserved'
}
];
})
);
});
document.querySelector('.bem').innerHTML = app.apply({ block: 'root' });
</script>
<div class="bem"></div>
</body>
</html>- Ok, what is the blocks?
- Think about them like about CSS abstraction for pure components way. Look at CSS for this app:
.root {
background: #fff;
}
.header {
color: red;
}
.main {
padding: 20px;
}
.heading {
font-size: 60px;
}
.md-editor {
&__editor {
border: 1px solid #000;
}
&__preview {
background: #ccc;
}
}
.footer {
font-size: 12px;
color: #444;
}- Wow! But what about JS logic? Is it the same?
- Yes, of course! Look at JS for this block...
Это еще больше можно упростить ;)
Если в твоём примере заменить BEMHTML на BEMTREE — будет не менее понятно.
@vithar ага) только html не появится) Надо будет еще столько же шаблонов про логику рендера
@awinogradov можно в bemjson от bemtree указывать tag. А чтобы перевести в html -> просто скормить полученный bemjson в bemhtml
bemtree - это машина
bemhtml - это тюнинг
@belozyorcev конечно можно) и атрибуты туда же) а можно и вовсе не использовать bemhtml. В чем смысл тогда разделения? Что ты будешь тюнинговать, если выразишь html в bemtree?
Связка еще понятнее становится: пишем шаблоны на bemtree, чтобы генерировать bemjson, который надо рендерить через bemhtml.
Сначала приучать людей мыслить блоками и декларациями.
Дальше делать код более гибким и чистым, добавляя в него bemhtml шаблоны.
В общем я солидарен с @tadatuta. В-первую очередь надо людям статический UI научится. bemtree опциональный level-up для динамики, а она у каждого своя.
Вот декларации еще одна штука, которую людям на входе знать не надо точно.
{ block: 'menu', elem: 'item' } -> это уже декларация
Ну не знаю, как по мне так на js объект похоже, чем докажешь?)
Декларация в моём понимание это описание сущности.
Сущностью в данном примере является элемент item блока menu. Это мы и описываем в объекте.
А это { content: 'text' } наверное неопределенная сущность? Мне правда надо все это знать, чтобы сделать компонент? Может это данные, которые используют шаблоны?
данные для компонентов VS декларация сущности
content - это то, что находится в сущности.
В итоге всё что нужно знать на первом этапе о декларациях, чтобы что-то начать строить.
- block
- elem
- content
дальше можно знакомить с модификаторами.
Не надо мне этого знать) Мне надо кнопочки клепать. Пойду в реакт куда-нибудь.
{ block: 'button', content: 'Супер кнопка' }
нужен тэг?
{ block: 'button', content: 'Супер кнопка', tag: 'button' }
А зачем мне bemtree? если и так работает?)
А зачем мне bemtree? если у меня данные с сервера уже приходят?
А мне бы вот еще чтобы в браузере все работало? А с graph-ql как оно?
А зачем мне bemtree? если и так работает?)
Я тебя не пойму. В чём конкретно вопрос?
Я хочу понять зачем мне простому смертному bemtree. Я написал пример где можно избавиться и от bemjson и от bemtree. Напиши такой чтобы стало понятно, что точно прям надо, пожалуйста.
Я тролю потому что эта разница неочевидна людям и не надо им вкладывать это в голову с ходу. Вообще ничего не надо им вкладывать в голову) Просто покажите как клево можно фигачить UI.
Я тролю потому что эта разница неочвидна людям.
Я сам писал bemjson на bemhtml и думал точно также. Не думал о bemtree, думал, что так правильно.
И как я сейчас начинаю осознавать, что проблема была не в том, что bemtree и bemhtml похожи (что иногда сбивает с толку), а в том, что bemtree был "где-то далеко за лесом" и пылился на полке до лучших времён. И когда пишешь на bemhtml структуру начинаешь думать, что bemtree лишний.
А я написал несколько продакшен проектов в банке на bemtree и отказался от него) Дальше то чего? Ты project-stub для себя делаешь? или для кого? Напиши пример, плиз, о котором я попросил. Сразу все понятно станет.
@awinogradov сам пример (удачный) не получится написать. А на словах если буду объяснять, то получится тоже самое, о чём писал я выше.
Проблема понимания bemtree и bemhtml также происходит из-за разного рода проектов, где эти понятия сливаются во едино. Я долго не мог понять зачем bemtree, когда есть bemhtml (смотрел на код bem-forum). И не понимал... О чём это в докладах говорят в Яндекс, как это разделять, если код и там и там одинаковый (практически).
@vithar показал на какие проекты смотреть надо и понимание стало полегче.
А я написал несколько продакшен проектов в банке
Я тоже так хочу )
@awinogradov для лёгкого понимания bemtree, знакомство с ним нужно начинать с самого начала. Иначе эффект ступора такой же (если его изучать после деревьев в bemhtml), как и от ухода от каскадов. Или не использовать bemtree вообще, как ты и предлагаешь.
Без примеров будет сложно понять что ты хочешь и предложить что-то по делу. Предлагаешь абстрактное - получаешь абстрактное ;)
Sent from my iPhone
On 25 Jul 2016, at 20:35, Sergey Belozyorcev notifications@github.com wrote:
@awinogradov сам пример (удачный) не получится написать. А на словах если буду объяснять, то получится тоже самое, о чём писал я выше.
Проблема понимания bemtree и bemhtml также происходит из-за разного рода проектов, где эти понятия сливаются во едино. Я долго не мог понять зачем bemtree, когда есть bemhtml (смотрел на код bem-forum). И не понимал... О чём это в докладах говорят в Яндекс, как это разделять, если код и там и там одинаковый (практически).
@vithar показал на какие проекты смотреть надо и понимание стало полегче.
А я написал несколько продакшен проектов в банке
Я тоже так хочу )
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Проблема сборки с bemjson кроется также в неумении потом работать с deps файлами.
П.Н.
Когда-то настанет день, что их не придётся вручную прописывать... Как по мне так, так это одна из проблем удобства разработки. Сидишь, голову ломаешь час... Почему же не работает???? А проблема банальна. Забыл прописать в deps модификатор блока. А потом вдруг уже не нужно использовать его и он в deps забывается. Нужен постоянный контроль за этим процессом.
Первое правило разработчика по БЭМ) Если что-то не так, смотри в депсы) ну и https://github.com/bemhint/bemhint тебе в помощь. Проблема, что ты описал, никак не связана с текущим issue.
@awinogradov я так не считаю. Это прямой эффект от привычки писать только bemjson (т.к. все депсы сами строятся), потом каждый раз спотыкаешься об это обманчивое мнение. А это негатив.
@awinogradov а по поводу bemhint - видел, но пока не понял как его запускать. В issue видел, что задачи по bemhtml и bemtree открыты.
Тогда давай пиши примеры чтоб все поняли почему ты так считаешь. Напомню, что я не предлагал писать bemjson ;)
Sent from my iPhone
On 26 Jul 2016, at 13:08, Sergey Belozyorcev notifications@github.com wrote:
@awinogradov я так не считаю. Это прямой эффект от привычки писать только bemjson (т.к. все депсы сами строятся), потом каждый раз спотыкаешься об это обманчивое мнение. А это негатив.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
@awinogradov по поводу bemhtml я с тобой частично согласен и с твоим отказом от bemtree.
bemtree на сколько мне известно предназначался для задания дерева из данных. А bemhtml был для того, чтобы легко переносить блоки между проектами. Но по факту я не встречал ещё таких идеальных примеров, чтобы можно было легко перенести блок из проекта в проект. Как по мне манипуляций ни чуть не меньше.
Если "api" блока написано хорошо, то без разницы на чём он (bemtree или bemhtml). Но в случае, когда только одна приоритетная технология - это проще понять. (И да, опять без примеров 🎱 )
upd
Сейчас в мире БЭМ, по моим ощущениям, они равны по приоритету. И это вызывает неразбериху.
по факту я не встречал ещё таких идеальных примеров, чтобы можно было легко перенести блок из проекта в проект
bem-core и bem-components же ;)
@tadatuta я пока слабо представляю это. Можно писать код так, чтобы один был родителем - распределял данные по блокам, а блоки строили бы уже внутри себя дерево на основе входных данных. Тем самым обеспечивая некое api.
При переносе просто можно выводить нужные данные блоком родителем на вход. А сходство/равенство bemtree и bemhtml очень напрягает (при том что у bemhtml ещё и больше возможностей, становится непонятно где строить bemjson)
А почему бы просто не прогонять написанный bemjson через bemtree по умолчанию? Для новичков все останется прозрачно, будто ничего и нет. А те кому это нужно смогут без головной боли писать bemtree и видеть результат в enb server
@kompolom это звучит как дополнительная магия под ковром, но идея интересная, да :)
👍
Набросал технологию для сборки html из bemjson используя bemtree:
var dropRequireCache = require('enb/lib/fs/drop-require-cache');
module.exports = require('enb/lib/build-flow').create()
.name('bemtree-to-html')
.target('target', '?.html')
.useSourceFilename('bemjsonFile', '?.bemjson.js')
.useSourceFilename('bemtreeFile', '?.bemtree.js')
.useSourceFilename('bemhtmlFile', '?.bemhtml.js')
.builder(function(bemjsonFilename, bemtreeFilename, bemhtmlFilename) {
dropRequireCache(require, bemjsonFilename);
dropRequireCache(require, bemtreeFilename);
dropRequireCache(require, bemhtmlFilename);
var BEMTREE = require(bemtreeFilename).BEMTREE,
BEMHTML = require(bemhtmlFilename).BEMHTML,
bemjson = require(bemjsonFilename);
return BEMHTML.apply(BEMTREE.apply(bemjson));
})
.createTech();На самом деле, все отсюда https://github.com/tadatuta/bem-bemtree-static-project-stub/blob/master/.enb/techs/bemtree-to-html.js только добавил bemjson
@kompolom забыл показать как это красиво получается)) Для тех кто только начал работать с технологиями БЭМ
без простыни bemjson))
var theme = 'light',
size = 'l';
const USER = require('./../../data/users.js')[0],
MENU = require('./../../data/admin-menu.js');
module.exports = {
block : 'root',
data : {
bundle : 'admin',
bundleUrl : 'admin-base-content',
page : 'products',
lang : 'ru',
title : 'Базовый контент админки',
data : {
user : USER,
menu : MENU
}
},
mix : [
{ block : 'page', mods : { admin : 'products', theme : 'light' }},
],
};@uradvd85 Все так. Но для новичков вряд ли будет понятно куда спряталась простыня и почему из этого кода получается полноценная страница.
Самое интересное тут то, что в module.exports мог быть обычный bemjson и все бы продолжило работать.
На мой вкус лучше в root использовать replace и выдавать page, а не делать микс:
https://github.com/bem-site/bem.info/blob/master/blocks/common/root/root.bemtree.js
Просто покажите это человеку на улице)
@vithar там и есть replace, микс только чтобы зависимости нужные подтянулись из bemjson.js. И я согласен с @awinogradov - вообще не понятно что за магия происходит. Но, еще раз: новичок может писать спокойно bemjson и все будет работать как обычно.
я просто оставлю это здесь https://github.com/facebookincubator/create-react-app
А я оставлю это:
