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

пока смуoает, что покапавшись в js можно перехватывать платежные данные, встает вопрос как можно обезопасить js, стек bem-express

@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 становится практически обязательной частью (но это не точно).

@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 становится практически обязательной частью (но это не точно).

Так не поможет?

useContext<{product: IProduct}>(ProductCardContext)

Вроде по тайпингам должно
https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts#L837

Соре, не писал на олдскульном bemxjst) Но писал на реакте, вроде прокидывать данные правильно через компоненты-контейнеры (ProductContainer), а компоненты-отображения (ProductCard) (и вложенные в них другие компоненты-отображения (ProductSkus например)) оставить без логики получения данных. Типа реиспользовать компоненты отображения сможешь потом и рефачить проще, отделяешь данные от логики отображения. В контейнере уже извлекаешь данные, через context, или через коннект к redux, тут вариантов много. Если правильно понял твой вопрос. А про то, что прикидывать пропсы в глубь - это нормально, но не когда все состояние приложения гуляет по компонентам, или вложенность уж сильно большая)

Владимир и Алексей, спасибо за митап и DI идей бэма в частности)) Было действительно интересно!

Коллеги, доброе утро.

У нас есть новость. Вчера на бэмапе мы делились стендом, который можно развернуть локально, чтобы пособирать свои темы.

Свершилось чудо и теперь не нужно устанавливать node.js, клонировать репозиторий и запускать npm install, npm start - стенд доступен всем и сразу, а своими темами вы можете делится в один клик (нужен аккаунт на github, чтобы сохранить ваше творение).

Стенд доступен по ссылке: https://codesandbox.io/s/whitepaper-controls-demo-vcvu6

Хорошего вам настроения)

@yarastqt @awinogradov  Eсть вопрос...

Мы часто используем в bemxjst кейсы с прокидыванием в node данных, чтобы из элементов получить к ним доступ.
А не прокидывать их через каждый элемент..

В React есть context, что вроде как логично использовать.

// ProductCard.tsx

export interface ProductCardProps extends IClassNameProps {
    product: IProduct
}

export type ProductCardContextProps = {
    product: Nullable<IProduct>
}

export const ProductCardContext = React.createContext<ProductCardContextProps>({ product: null });

export const cnProductCard = cn('ProductCard');

export const ProductCard: FC<ProductCardProps> = ({ 
    product, 
    className, 
    children, 
    ...props 
}) => {
    const contextData = { product };

    return (
        <div {...props} className={cnProductCard(null, [className])}>
            <ProductCardContext.Provider value={contextData}>
                {children}
            </ProductCardContext.Provider>
        </div>
    )
}

В элементах используем useContext(ProductCardContext).
Но...  Из-за обязательного default  в api контекста в элементах приходится делать проверку на product



const { product } = useContext(ProductCardContext);
if(product) { ... }

Как вариант, можно сделать свой хук, для вытаскивания данных

useProductCardContext = () => {
  const { product } = useContext(ProductCardContext);
  return { product: product as IProduct };
}

Но правда кажется всё это сомнительным...

Вопросы:
1. На сколько этот подход нормальный?
2. Где лучше хранить хук и контекст?

Сорян, чет не увидел раньше:
1. Подход вполне норм, у нас где-то такое же используется точно, насчет проверок, у тебя же явно в интерфейсе сказано Nullable, для этого и используется ts 🙂 либо укажи, что это свойство есть всегда, тогда бесполезный хелпер с приведением типов тебе не нужен будет
2. Мы обычно создаем технологию внутри компонента Component/Component.hooks | Component/Component.const (если это код только про этот компонент)

Я возможно туплю, но при создании контекста он требует дефолтные данные (а контекст объявляется до кода шаблона).
Но тут нужно либо создавать скелет на основе объетка товара, либо через Nullable.... И далее через хук говорить, что товар есть всегда.