Решалось бы

Так это решается полным хмл

СОВСЕМ ПЛОХО

Если у тебя в компоненте 50 дырок под произвольный хтмл, то такое ощущение, что сам компонент ничего не делает)

Или делает слишком много

СОВСЕМ ПЛОХО

Ну объективно флекс был очень удобен

Не надо xlm, плз ?

Как же ты с jsx живешь

Между xml и jsx большая разница

Ну то есть либо у тебя мешанина из xml и кода, либо просто xml

Ещё с ангуляровскими шаблонами сравнить и сказать, что там тоже xml-подобный синтаксис, значит всё такое же)

Ну то есть либо у тебя мешанина из xml и кода, либо просто xml

Нет, jsx — это просто код

Обожди, мы не туда ушли

Вопрос был как передать проперти компоненты в компонент

Что такое проперти компонент?

Коллеги, всем привет. Скажите, насколько порочна практика использования чайлдов компонента в качестве параметров для формирования свойств и вида компонента? Например, когда у вас что-то вроде data table и надо указать колонки запрашиваемые с сервера и вместо не очень читаемого объекта или формирования данных заренее где-то там сверху, мы пишем все в виде очевидных вложенных компонентов, например: <DataTable url="/api/entity"> <DataTableColumn field="name" title="Имя" /> <DataTableColumn field="email" title="Email" /> </DataTable> и т.п.

Вот тут это DataTableColumn

Я спутал немного. Во флексе идея была в том, что можно было любой аттрибут задавать как чайлд-тег, а в нем, соответсвенно, уже указывать значения как чилды Что-то типа <Component> <layout> <VerticalLayout gap="10"/> </layout> ...children as content property... </Component>

Здесь это вертикал лейаут

Вот это и есть зло

Он же вообще ничего не делает

Я про вот такие вот страхи <Component layout={ <VerticalLayout gap="10"/> } > ...children as content property... </Component>

И здесь

Вот это и есть зло

Собственно, вопрос был, что не зло. Какие варианты есть?

Это тег должен быть, а не компонент

Вопрос в том, как их передать в компонент чтобы при этом их различать

Это тег должен быть, а не компонент

Шта?

Сделать нормальный отдельный компонент VerticalLayout, управляющий своими чайлдами, не?

Он же вообще ничего не делает

Делает то, что написано

Не

Это вот как раз плохая идея

Сделать нормальный отдельный компонент VerticalLayout, управляющий своими чайлдами, не?

Вот эта

Чем?

А какая идея хорошая, расскажите плиз)

Чем?

Тем, что это поведенческий паттерн, проперти-компонент отвечает только за часть проведения нашего компонента, причем заменяемая

А в твоем случае это будет только лэйаутинг и все

А какая идея хорошая, расскажите плиз)

Избегать таких сложностей

Но если вперся, то нужно минимальное связывание

А что ты ещё хочешь вложить в свойство layout?

Если тебе нужны пресеты, то это делается иначе и без лишних компонентов вообще

Я не понимаю чем вам не нравится пропс type = 'Vertical' | 'Horisontal'

А что ты ещё хочешь вложить в свойство layout?

Это пока один из вариантов, который удерживает нормальную связность

Но внешне ужасно выглядит и путает код

Связность надо уменьшать, а не удерживать

Но внешне ужасно выглядит и путает код

Очень. При этом совсем не решает поставленных задач

Очень. При этом совсем не решает поставленных задач

Чоэт? какую не решает?

Связность надо уменьшать, а не удерживать

Удерживает ее минимальной

Если нужен вертикальный лейаут с gap = 10 то делать для этого компонент не обязательно

Это оверкилл

Я не понимаю чем вам не нравится пропс type = 'Vertical' | 'Horisontal'

Это очень частно

Да

Это оверкилл

Это задел под библиотеку

Это называется низкая связанность

Это называется низкая связанность

Ни хренашеньки

const mainPreset = { layout: 'Vertical', gap: 10 } <Layout {...mainPreset} />

Это называется низкая связанность

Это ты всю функциональность запихиваешь в наш родительский компонент

Отличная слабая связь, да

const mainPreset = { layout: 'Vertical', gap: 10 } <Layout {...mainPreset} />

А layout ты как кладешь в родительский компонент? В код зашиваешь?

Правильно ли я понимаю, что extractTextPlugin > 2.x.x теперь не поддерживает эту магическую строковую запись для цепочки loader, а хочет все в виде объекта. Если да, то есть ли пример для цепочки?

А layout ты как кладешь в родительский компонент? В код зашиваешь?

Безразлично, для этого можно выбрать один из множества подходов

Можно так же передавать все пропсы дальше, если тебе нужен просто контейнер

Пример?

Подскажите по мультиредьюсеру, он работает если сервер с бэкэндом дергать?

Я тебе его уже написал

Суть в том, что безразлично внутреннее устройство компонента, это подход к внешнему интерфейсу

Я тебе его уже написал

Пропустил, спасибо

Пропустил, спасибо

Не тебе ?

Я не понимаю чем вам не нравится пропс type = 'Vertical' | 'Horisontal'

Horizontal тока :D

простите

ERROR: S client not available

Ок)

Не тебе ?

Ну, посмотрел еще раз, да не нашел :)

Суть в том, что безразлично внутреннее устройство компонента, это подход к внешнему интерфейсу

И какой он? Строку передать?

Подскажите, а как лучше сделать набор одинаковых редьюсеров но с разным префиксом для экшенов? Или стоит использовать мультиредьюсер?

Оригинальный вопрос звучал так

Это зашивание жесточайшее

Набор пропсов?

Он не регламентирован

Эм

Ладно, позже напишу разницу как я ее вижу

Видимо без нормального примера ее не видно

const Component = ({ children, ...props }) => <any><Inner {...props}>{children}</Inner></any>

Плохо, иннер зашит

Внутренняя логика может быть какой угодно. Я не понимаю

Он может хоть рекомпозом на лету генерироваться, это вообще не важно

Я по прежнему не вижу смысла передавать в виде компонента то, что реализуется объектами без нарушения инкапсуляции

Ну лан потом напишу пример, где это играет роль

Можно хоть другие компоненты передавать и внутри рендерить, хоть что) <Dropdown item={Item} />

А другие варианты?

Передавать компоненты в props. В material-ui очень много компонентов так кастомизируются (IconMenu, например)

Я выше как раз такой кейс написал)

А я не читал, я сразу ответил :)

Передавать компоненты в props. В material-ui очень много компонентов так кастомизируются (IconMenu, например)

Ну, когда один компонент заменить - это логично. А когда у тебя свойство это массив, прости господи, других свойств?

Ну, когда один компонент заменить - это логично. А когда у тебя свойство это массив, прости господи, других свойств?

Я выше тоже такой пример привёл)

Хорошо, скажите еще такую штуку, как-то можно в потомков компонента внедрить через сам компонент свойство не передавая его явно в компонент и стоит ли? У https://github.com/jquense/react-bootstrap-modal/ так компонент Dismiss сделан как-то хитро.

Я выше тоже такой пример привёл)

Это какой? Я уже запутался

Это какой? Я уже запутался

const mainPreset = { layout: 'Vertical', gap: 10, icon: { component: UserIcon, colors: scheme } } <Layout {...mainPreset} />

напомните группу по css?

посоны

const mainPreset = { layout: 'Vertical', gap: 10, icon: { component: UserIcon, colors: scheme } } <Layout {...mainPreset} />

А вот теперь представим, что у нас это где-то в начале render объявляется, а кода мы уже написали на пару страниц. И нам надо добавить или поправить эти настройки и нам надо перейти к этой конструкции и вернуться обратно. Это все занимает время. Впрочем, наверное это вкусовщина и другие варианты все слишком спорно-геморройные, чтобы за них тереть.

Казалось бы, что может быть проще?)

Хотим сделать сервер-сайд рендеринг, но возникла проблемка со стилями. У нас есть НЕ НАШИ компоненты внутри которых вот такие конструкции import styles from './styles.pcss'; import classNames from 'classnames/bind'; const cx = classNames.bind(styles); вебпак настроен вот так: module{ loaders: [ { test: /\.p?css$/, loaders: ['style', 'css?modules&localIdentName=[hash:base64:10]!postcss'], }, ... ] После компиляции мы получаем бандл со всеми компонентами, картинками и стилями внутри — всё в одном файле. затем мы юзаем этот "бандл" внутри сервер-сайд рендерера, и получаем ошибку. Стектрейс говорит, что не может найти document.createElement ... зафейкали этот метод, и оказывается оно в <head> пытается присунуть теги <style> с ЦСС-СТИЛЯМИ :(. Вот проблема в том, что не понятно как сервером рендерить стили в этом случае. :( Ведь сервер то не умеет в DOM. подскажите какойнить обходной манёвр ?

напомните группу по css?

@frontend_ru @css_ru

не?