+1

Не подскажешь нужно отдельно стартовать или мобилку или десктоп?

npm run start-desktop

np

m run start-mobile

```Есть возможно реализоавть механику как project-stub:
Выбираем в devTools нужное устройство и перезагружаем страницу.

А то перезапускать каждый раз приложение при прототипировании не очень удобно.

npm run start-desktop

m run start-mobile

Есть круче, особенно при использовании StroryBook

Изолированная среда + перезагружать страницу не нужно

Можно сделать чтобы в CRA не нужно было перезагружать?

Очень хочу такой же экпириенс как в project-stub в 2015. Пару команд и заряженная инфраструктура для прототипирования: демки с уровнями, PostCSS плагины нужные, bem-components завезены.

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

Это из коробки работает

В project-stub (PS) есть плюс и минус одновременно связанный с подключением блоков.
В PS не нужны были deps файлы. Просто делаешь портянку из bemjson и она работает.
Про минус этого подхода я описывал здесь https://github.com/bem/project-stub/issues/159

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

В плане всяких Hot Reload - в большинстве инструментов на React это работает из коробки (create-react-app, nextjs, storybook, и т.д.).
Просто поправил что-то в коде, а в браузере уже исправленный код.

На счёт bem-react/di, возможно вам он даже не понадобится (как мне кажется).
Т.к. di просто позволяет использовать механизм слотов. Т.е. есть какой-то блок MyBlock, состоящий из элементова Icon и Text, через DI можно вместо Text вставить, например, кнопку. DI скорее всего больше для разработчиков подходит, чем для дизайнеров.

В плане переопределений что конкретно хочется? Если чисто CSS специфичный для платформ - то это на раз плюнуть.

// Block.tsx
import 'Block.css'

// Block@desktop.tsx
export * from './Block'
import 'Block@desktop.css'

// Block@phone.tsx
export * from './Block'
import 'Block@phone.css'

Если разная вёрстка, то здесь либо 2 разных шаблона использовать, либо DI (если позволяет вёрстка).

В части случаев важно держать общий CSS и переопределять под платформы.

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

С импортами постепенно смирился, хотя вещь изнурительная.

Относительно стилей пока решили подключать собранный  библиотечный CSS целиком в корень.

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

Путь прошлой недели (дизайнерский взгляд):

1. Пересмотр видео Антона (звучит бодро, но то что происходит на экране настораживает);
2. Развертка CRA (отдельный мир и дока Реакта);
3. Установка  в него трёх БЭМ-пакетов (вроде тут всё чётко);
4. Разбиваем все интерфейсные сущности (думаем каким образом лучше организовать структуру, по понятным причинам один в один как было в project-stub не повторить);
5. Пишем пару компонентов (вроде что-то отрисовалось, но нейминг компонента, результирующего класса и его директории вызывает вопросы);
6. Подключение whitepaper (женим нейминг, чтобы подхватывалисть стили [спасибо за плагин по конвертации стилей]);
7. Переписываем созданные блоки: разметку, импорты, стили (сборка ругается, ищем где накосячили);
8. Вспоминаем про демо-репозиторий чтобы сравнить организацию компонентов (структур вроде верная и разбивка вроде сходиться, НО тут что за огромный кусок кода в каждом компоненте, который никак не задействован в отображений [привет TS])
9. Вспомни про уровни переопределениям под платформы (не понятно как это сразу воспроизвести [спасибо за демку] — будем пробовать дальше)
10. Копирую кусок стилей из старого блока (чёт всё сломалось, а в CRA же нет PostCSS сразу подключённого с базовым  плагинами)

Чтобы воспроизвести прежний опыт требуется значительное количество телодвижений, через который предстоит пройти прежде чем начнёшь выдавать интерфейс и оперировать прежними концепциями, по сравнению с тем же project-stub.

Очевидно, что нам над этим нужно крепко поработать

Есть возможность подсказать какой порядок действий нужно совершить чтобы прикрутить PostCSS в CRA?


Что прописывать какие пути прописывать в package json?
Должно ли всё склеиваться в один файл?
...

Задача описывать математику цвета/нестинг/итд в стилях компонент? https://github.com/opencharge/opencharge.tech/tree/header/src/Components

Может есть какой boilerplate, чтобы ориентироваться

Дополню вопрос, можно ли сделать это без eject

По сути можно и с eject

UPD: @kolebayev Знаешь как сделать с eject?

не пробовал, разобраться можно

Кажется достаточно базовая вещь, адекватного туториала не нашёл. Смог собрать все приобразованные стили с компонент в отдельный дист. Но какие дальше манипуляции делать не совсем понятно. Не импртить же в компоненты CSS из этого диста?

Подскажи пожалуйста это все можно воспроизвести Без TS?

Достаточно воспроизвести аналогичную структуру и забрать код или какие-то более хитрые манипуляции нужно выполнить?

Нет, всё будет работать и без TS. А 2 команды для запуска там чтобы разделить бандл на 2 части и собирать поплатформенно. Можно объединить desktop.tsx и mobile.tsx в один и через условие подставлять нужный реестр

Про postcss и eject - удобно для этого использовать parcel для сборки, ничего конфигурить не надо

Если у тебя будет возможность можешь пожалуйста глянуть, что нужно, чтобы твой пример завёлся c jsx?