Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Логика mod в schema #1

Open
skad0 opened this issue Jul 2, 2016 · 14 comments
Open

Логика mod в schema #1

skad0 opened this issue Jul 2, 2016 · 14 comments
Assignees

Comments

@skad0
Copy link

skad0 commented Jul 2, 2016

В процессе реализации поддержки формата в bem-decl возник вопрос, касательно поведения атрибута mod.
В данный момент по схеме он понимает string значение и может использоваться в паре с val [String|Bool]. В случае его использования считается, что блок не подключается.

Логично предположить, что между mod и mods можно провести параллель с elem и elems. Значит mod должен вести себя аналогично и понимать объект?
@veged @dima117

@blond
Copy link

blond commented Jul 2, 2016

Возможные варианты:

mod: { name: 'foo', val: 'bar' }
mod: { name: 'foo' }
mod: ['mod-name-1', 'mod-name-2']
mods: ['mod-name-1', 'mod-name-2']
mod: [{ name: 'foo', val: 'bar' }]
mods: [{ name: 'foo', val: 'bar' }]

@veged
Copy link

veged commented Jul 4, 2016

между mods и elems есть параллель, а вот между mod и elem нет, т.к. есть ещё поле val — так что можно не усложнять и не делать возможным для mod объект

also, синтаксис с name считается depricated и рекомендуется везде использовать или явное указание block/elem/mod/val или сокращённые записи

@blond
Copy link

blond commented Jul 4, 2016

между mods и elems есть параллель, а вот между mod и elem нет, т.к. есть ещё поле val — так что можно не усложнять и не делать возможным для mod объект

Когда есть возможность записать объект в элемент, легко захотеть записать объект и в mod.

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

also, синтаксис с name считается depricated и рекомендуется везде использовать или явное указание block/elem/mod/val или сокращённые записи

Мы можем его поддерживать и ругаться варнингами.

Такое поведение ок?

@veged
Copy link

veged commented Jul 4, 2016

не понимаю аргументации в стиле «легко захотеть» — это совсем другая вещь, кроме того усложняет всё (например, нужно будет поддержать vals и тоже объектом) — сейчас всё просто: есть «сущности» (блоки и элементы) и они отличаются от модификаторов со значениями

я бы вообще сократил name и ругался бы как на ошибки

@dima117
Copy link
Collaborator

dima117 commented Jul 4, 2016

@veged, @blond Правильно я понимаю, что решили в mod/val писать только строки?

@veged
Copy link

veged commented Jul 6, 2016

@dima117 я сильно настаиваю на этом, но я пока не понял продолжает ли @blond быть не согласным ;-)

@blond
Copy link

blond commented Jul 17, 2016

сейчас всё просто

😆 Просто как жарить колетку...

не понимаю аргументации в стиле «легко захотеть»

Ну это как консистентность в API: ожидать по аналогии с тем, что уже увидел.

mods: ['mod-name-1', 'mod-name-2']

Такое, кстати, поддерживается в текущих реализациях: пруф.

я бы вообще сократил name и ругался бы как на ошибки

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

Исходили из принципа, что лучше приедет что-то лишнее, чем что-то сломается.

Возможно, в будущем стоит превращать эти варнинги в ошибки, когда подавляющее число начнёт пользоваться линтерами, вроде этого.

@dima117
Copy link
Collaborator

dima117 commented Jul 17, 2016

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

Если описания не будет, то ничего не меняем и закрою этот issue.

@veged @blond

@skad0
Copy link
Author

skad0 commented Jul 17, 2016

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

@blond
Copy link

blond commented Jul 18, 2016

Как минимум давайте включим mods: ['mod-name-1', 'mod-name-2'], потому что так работают существующие реализации.

@dima117
Copy link
Collaborator

dima117 commented Jul 18, 2016

Ок, сегодня сделаю. Остальное не меняем?

@blond
Copy link

blond commented Jul 18, 2016

Да.

@dima117 dima117 self-assigned this Jul 18, 2016
@veged
Copy link

veged commented Jul 20, 2016

что означает mods: ['mod-name-1', 'mod-name-2']? этим можно разумно пользоваться только если все перечисленные модификаторы булевские

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

@blond
Copy link

blond commented Jul 23, 2016

что означает mods: ['mod-name-1', 'mod-name-2']? этим можно разумно пользоваться только если все перечисленные модификаторы булевские

Как раз означает булевые модификаторы

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

Так работает в deps и deps-old в ENB. Кажется, во всех версиях.

Т.е. это почти 100% пользователей на данный момент.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants