Можно)

а как переделать именно часть, а не весь блок?

Насколько мне известно в новом подходе бем реакт никак. Только полное переопределение на блок/элемент с аналогичным интерфейсом.

Ну вот и я так думаю, просто выше сказали можно)

Давайте конкретный пример 🙂 Сложно предлагать решение, не видя проблемы

Всем добрый день! Мня немного беспокоит один вопрос, он больше отом правильно ли я поступил или нет. Дело обстоит так, без скриншота не обойтись так что смотрите скриншот. Значит так: Я сделал список List у него есть элементы, меня интересует элемент list__pic в нем должны быть картинки, но дело втом что картинки разные и они вставляются не через <img>, а используется такая утилита (если можно так её назвать) gulp.spritesmith - короче говоря автоматическое создание спрайтов. Так, как только эта программа отработала на выходе я получаю .scss файл со всеми необходимыми преременными и мексинами из которого я могу сделать @include думаю понятно.  Так в чём моя боль, как видно на скриншоте я для элемента list__pic сделал модификаторы list__pic_like и там так далее _book ... _dialog и в каждый модификатор я сделал определённый @include. Но мне думается что я поступил не совсем целесообразно. Может можно было при миксовать или вообще сделать так list__pic-like далее list__pic-book и не делать модификатор, а сразу в элемент делать @include. Посмотрите скриншот. Мне бы хотелось чтобы Вы поделились опытом, дали рекомендации. Если кратко как это все грамотно оформить. Спасибо

Дайате я немного другое спрошу, как фанант bem-xjst и ibemjs. Может ли так делать react core?

1. HTML фрагмент любого блока может быть переопределен частично или полностью или доопределен на уровне переопределения или с помощью модификатора

2. JS любого блока может быть переопределен частично или полностью или доопределен на уровне переопределения или с помощью модификатора

3. Блоки могут использоваться в других проектах и подстраиваться под требования проекта за счет уровней переопределения и модификаторов

Если блок определён как React компонент-класс, то расширять можно на уровне методов этого класса (заменять некоторые методы новыми реализациями). Если хочешь подменить какую-то часть render() метода, то для этого в базовом блоке удобно разбить render() метод на несколько. Впрочем, если разбиваешь render() на несколько более мелких функций, почему-бы не выделить их (эти sub-render функции) в отдельные компоненты?

Вообще суть BRC@3 в том, что ты делаешь композицию, соответственно ты не можешь менять полностью базовое поведение блока, но можешь добрасывать что-то сверху, как правило в базовой реализации есть минимальный набор методов нужный для работы блока, все остальное добавляется через модификаторы
1. Прям как в bem-xjst не получится, т.к. в первом ты работаешь в json и можешь подлезти куда тебе нужно, в реакте же ты работаешь уже с функциями которые создают этот компонент, поэтому тут нужно на уровне блока поддержать получение всех элементов из реестра, чтобы мочь их переопределить в нужном месте
3. Да

Ответ на 2 вопрос из предисловия

Мы для этого как раз используем DI и добавляем компоненты внутрь из реестра, ты можешь в этом реестре на любом уровне подменить нужный тебе элемент

фактически вы сказали что стек на реакте не такой гибкий как как с  bem-xjst. А по поводу минимального набора методов, можно просчитаться и затем уже придется пилить блок с нуля так как выпилить что-то уже нет возможности

Ну, это очевидно, что bem-xjst это более низкий уровень в отличии от реакта, где абстракция есть

Это справедливо для любого фреймворка

react, angular, vue, ember там везде абстракция над шаблонами в виде html/jsx

Но всегда ли нам нужна такая гибкость, это уже другой вопрос

кажется, что у нас это не такой частый кейс

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