Комментарии 4
Мы можем определять любые свойства для элемента через “config”. Значения переданные через это свойство будут иметь высший приоритет.
Наоборот лучше передавать конфиг и оверрайдить его тем что в конкретных свойствах. Обычный юзкейс, когда есть большая дефолтная конфигурация и оверрайд на месте.
Вообще это выглядит как попытка решить проблему инкапсуляции стилей. Как-то больше не получается осознать для чего это нужно. Я не вижу что это решает какую-то боль. (Может быть потому что я в основном пишу на Angular и Vue, стараясь избегать React)
Обычный юзкейс, когда есть большая дефолтная конфигурация и оверрайд на месте.
Согласен, обычно так и делается. На первый взгляд может показаться, что и здесь такой подход более уместен.
Если рассмотреть контекст использования данного инструмента(библиотеки), то можно заметить, что он используется для создания разметки и стилей фронтенд разработчиком. Если оставить инлайн свойства с высшим приоритетом, то разработчику придется использовать именно свойство config для кастомизации элементов разметки, чтобы задавать дефолтные(aka с низшим приоритетом) значения.
UPD: Также можно переопределять свойства переданные инлайн, например 'спредить' пропсы переданные выше...или найти еще 100 других способов) Но идея этого подхода как раз и заключается в том, чтобы дать наиболее простой и однозначный способ решить эту задачу.
Тогда весь код будет выглядеть примерно так:
<CE.Block config={{ className: 'daily-card' }}>
<CE.Image config={{ src: image, modifiers: ['card-image'] }} />
<CE.Block config={{ modifiers: ['card-info'] }}>
<CE.Text config={{ modifiers: ['card-title'] }}>{title}</CE.Text>
</CE.Block>
</CE.Block>
На мой взгляд, такой синтаксис только ухудшает читабельность кода. Для сравнения:
<CE.Block className='daily-card'>
<CE.Image modifiers={['card-image']} src={imageSrc} />
<CE.Block modifiers={['card-info']}>
<CE.Text modifiers={['card-title']}>{title}</CE.Text>
</CE.Block>
</CE.Block>
Config, возможно, не самое удачное имя для названия пропса и вводит в заблуждение. Это в первую очередь - альтернативная, дополнительная точка входа, в случае если это по каким-то причинам будет необходимо.
Вообще это выглядит как попытка решить проблему инкапсуляции стилей.
Не понимаю, почему это так выглядит.
Я не вижу что это решает какую-то боль.
Web Content Elements(WCE) - это подход к созданию разметки и организации системы стилей.
React Content Elements(RCE) - это реализация принципов WCE подхода для конкретной среды.
WCE предлагает частичную стандартизацию как некоторых шагов(этапов) для создания HTML и CSS, так и готового результата(DOM tree, styles). Проще всего ощутить пользу можно будет при применении этого подхода на проектах с большой кодовой базой и большими командами.
На мой взгляд, применение принципов WCE может частично унифицировать как работу на этапе разработки, так и конечный результат.
Пример готовой разметки:
UPD: Если вернуться к проблеме инкапсуляции стилей, то на изображении выше можно заметить, что JSX свойство className используется скорее как неймспейс для группы вложенных элементов, а не селектор для конкретного элемента. Да, это является в какой-то степени решением проблемы инкапсуляции стилей, но это скорее сайд эффект данного подхода, чем его основная или даже второстепенная цель.
Когда-то каждый инженер при необходимости (при действительно необходимости) "отрефакторить" узел, должен был ответить для себя на вопросы
.как я могу упростить его
.станет ли работать надежнее вся конструкция в итоге
Отсутсвие инженеров в профессии — настолько страшная беда, что мы даже не можем оценить ее масштабы...
Честно говоря так и не понял (возможно статья плохо раскрывает преимущества) какие преимущества у данного подхода. Но вот разработчикам, работающим в команде (а так же новым разрабам, пришедшим на проект), придется изучать дополнительную библиотеку и как по мне это скорее минус.
React Content Elements