по времязатрате не имея наработок

Весь этот https://ru.bem.info/methodology/ раздел точно подойдёт

// block.bemtree.js

block( 'block' )( {
  extend: {
    hello: 'world'
  },
} );

// block_view_preview.bemtree.js

block( 'block' ).mod( 'view', 'preview' ).content()( ( node, { hello } ) => ( {
  elem: 'content',
  content: hello
} ) );

extend расширяет node

Т.е. тебе так нужно

// block_view_preview.bemtree.js

block( 'block' ).mod( 'view', 'preview' ).content()( ({ hello }) => ( {
  elem: 'content',
  content: hello
} ) );

Да, я это уже, кажется, понял 🤦‍♂️

// block_view_preview.bemtree.js

block( 'block' ).mod( 'view', 'preview' ).content()( ({ hello }) => ( {
  elem: 'content',
  content: hello
} ) );

Или так:

block( 'block' )( {
  extend: {
    'ctx.hello': 'world'
  },
} );

// block_view_preview.bemtree.js

block( 'block' ).mod( 'view', 'preview' ).content()( ({ hello }) => ( {
  elem: 'content',
  content: hello
} ) );

Спасибо. 🤙

Кто-то заморачивался над типизацией оформлений из whitepaper (или похожей штуку) в bem-react + ts?
Чтобы не импортировать css напрямую.

https://github.com/bem/bem-react/issues/446

Небольшая дилема...

У input есть 2 псевдокласса valid и invalid....

Вроде логично, сделать модификаторы .Input_valid и .Input_invalid  (сейчас в проекте так реализовано), но они взаимоисключающие.

Можно запихнуть 2 кейса в один модификатор valid, но так менее красиво :)
.Input_valid_yes и .Input_valid_no

Кто-то заморачивался этим вопросом?

Кажется можно было бы сделать что-то вроде такого: .input_status_error .input_status_saccess .input_status_info в этом случае тогда можно не только 2 кейся обработать. Возможно кто-то что-то другое посоветует

.input—state_invalid .input—state_valid

а почему нельзя слушать это состояние через атрибут valid (прим.) имеющие состояния `boolean | undefined' (null), те либо валидный, либо не валидный, либо никакой?

Зависит от поддержки —  iOS совсем недавно «научился» валидировать формы.

@awinogradov @tadatuta вопрос по bem-react. На сколько я понимаю хорошей практикой является создание заготовок блока сразу под нескольких платформ.

Т.е. если мы создаём какой-то блок, например Checkbox



Checkbox.css
Checkbox.tsx

Нужно сразу сделать это и для других платформ

Checkbox@desktop.tsx
Checkbox@touch-phone.tsx

Которые будут просто проксирующими заглушками common.

Тоже самое касается и всех модификторов

_size/Checkbox_size_l.css
_size/Checkbox_size_l.tsx
_size/Checkbox_size_l@desktop.tsx
_size/Checkbox_size_l@touch-phone.css
_size/Checkbox_size_l@touch-phone.tsx

И элементов

Box/Checkbox-Box.css
Box/Checkbox-Box.tsx
Box/Checkbox-Box@desktop.tsx
Box/Checkbox-Box@touch-phone.css
Box/Checkbox-Box@touch-phone.tsx

Т.е. если мы сейчас находимся в рамках платформы touch-phone, то подключение блоков из common является плохим тоном.

// MyBlock@touch-phone.tsx
import { Checkbox } from '../components/Checkbox/Checkbox'
import { withSizeL } from '../components/Checkbox/_size/Checkbox_size_l'

Такое подключение может вести к неожиданным последствиям.
Т.к. где-то внутри дерева (или в другом месте) будут быть подключены стили именно платформы
Либо изначально была одна общая версия Checkbox без разбивки на платформы

// MyDeepBlock@touch-phone.tsx
import { Checkbox } from '../components/Checkbox/Checkbox@touch-phone'
import { withSizeL } from '../components/Checkbox/_size/Checkbox_size_l@touch-phone'

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

В таком кейсе использование @bem-react/di становится практически обязательной частью (но это не точно).

Добрый день! Подскажите насколько безопасно использовать бэм  формы для приемки платежей через checkout, с полным механизмом валидации.

абсолютно безопасно (по сути это не связанные вещи)

Смушает, что в валидации this.getVal(); передает весь массив формы, атрибут "name" выпелен из inputa

или опасения напрасны?

форму же можно настроить как угодно... какой вектор атаки смущает?