Deep clone как !important в css, признак проблем)

можно ли сделать :hover в параметре style={} ?

Какую либу с редаксом юзаете для запросов к серверу?

Axios

можно ли сделать :hover в параметре style={} ?

http://stackoverflow.com/questions/1033156/how-to-write-ahover-in-inline-css я не уверен на счет ответа, так как почти не юзал реакт, но если style={} это инлайновый css, то нельзя. Поправьте меня если я не прав :)

http://stackoverflow.com/questions/1033156/how-to-write-ahover-in-inline-css я не уверен на счет ответа, так как почти не юзал реакт, но если style={} это инлайновый css, то нельзя. Поправьте меня если я не прав :)

да, я прочитал уже это. вынес нужный класс наружу в css

http://stackoverflow.com/questions/1033156/how-to-write-ahover-in-inline-css я не уверен на счет ответа, так как почти не юзал реакт, но если style={} это инлайновый css, то нельзя. Поправьте меня если я не прав :)

ты прав

Какую либу с редаксом юзаете для запросов к серверу?

request-promise (request + bluebird)

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

немного не по реакту, но вопрос: как в graphql mutation сделать параметр как list? например, мне надо перечислить список ids, относящихся к записи. не строкой же передавать разделенные через запятую upd. сделал так input Post { users: [Int!] }

я тоже не въезжал, сделал пару скринкастов на ютубе и взлетело.

Скинь скринкастов

Всем привет. Подскажите, а правильно я понимаю. Допустим мне нужно отправить запрос в апи. Это делаем в экшне и ретурним респонс. А в редьюсере уже обрабатываем этот респонс и пихаем в стору?

Всем привет. Подскажите, а правильно я понимаю. Допустим мне нужно отправить запрос в апи. Это делаем в экшне и ретурним респонс. А в редьюсере уже обрабатываем этот респонс и пихаем в стору?

почти

в редьюсере тебе нужно получить payload в определенном action.type

и уже засунуть в стор в той структуре, как тебе надо

ну то есть dispatch => axios.post(/api).then(res => dispatch({type:..., payload: res.data}))

так?

+

axios сильно лучше чем isomorphic-fetch?

axios сильно лучше чем isomorphic-fetch?

Удобнее

Ребята, никто не хочет сделать пример css in js, для этого репозитория: https://github.com/AleshaOleg/holy-grail-markup? Мы там собрали, все примеры верстки на CSS и css-in-js смотрелся бы там очень круто.

Как в SPA форсить пользователя обновить страницу? Например, после релиза. Пока есть идея как-то по вебсокетам слать сигнал, после которого клик по любой ссылке будет совершать реальный переход

показать глобал нотис что вышла новая версия и надо обновить страницу для корректной работы

самовольное обновление страницы ни есть гуд = ошибка

гильермо рош писал об этом

window.location.reload(true); ?

window.location.reload(true); ?

как ты узнаешь, когда это делать?

reload это жестко

window.location.reload(true); ?

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

https://rauchg.com/2014/7-principles-of-rich-web-applications#push-code-updates

вот здесь он говорит про апдейты кода

Как в SPA форсить пользователя обновить страницу? Например, после релиза. Пока есть идея как-то по вебсокетам слать сигнал, после которого клик по любой ссылке будет совершать реальный переход

посмотри ссылку что я дал

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

у нас не кешируется index.html, а все скрипты в имени файла имеют свой хеш, потому такое невозможно

посмотри ссылку что я дал

спасибо, посмотрю

сервис воркер

захуярь

По обновлению сервис воркера - он сам обновит клиента

https://cs7065.vk.me/c638218/v638218025/2282d/tdr8oR7Yt9E.jpg

?

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

Если есть по этому поводу что-то почитать, с радостью ознакомплюсь.

Это ок, если весь проект так построен

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

Вполне нормальный вариант, если компоненты без костылей. В основном для колонок юзаю подобных. Беда начинается, когда чтобы вывести компонент тебе нужно хитро вывести 5 дочерних компонентов в опеределенной последовательности.

И, наверное, проблемы начинаются, когда тебе надо помимо колонок добавить какие-то фильтры и прочие настройки отличного от единого типа дочерних елементов.

Кстати, если этот вариант использовать, можно как-то нормально определить тип компонента в прод билде?

А то он в разработке type.name нормально имя компонента дает, а в прод билде нет)

Вполне нормальный вариант, если компоненты без костылей. В основном для колонок юзаю подобных. Беда начинается, когда чтобы вывести компонент тебе нужно хитро вывести 5 дочерних компонентов в опеределенной последовательности.

Через React.Children.map можно

Через React.Children.map можно

Не, нифига. Думаю, что React.Children. map от React.Children.toArray не сильно отличается.

Не, нифига. Думаю, что React.Children. map от React.Children.toArray не сильно отличается.

Ну да, а в чём тутт пробема то?) Я просто не очень понимаю

Фильтр — через айдишники в redux или state

Ну нет, если здесь redux или стейт юзать, то такое усложнение не имеет особого смысла.

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

Впрочем, наверное если усложнять до нескольких типов потомков овчинка выделки не стоит.

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

Ой, не

Не - не стоит?)

Ну в плане что мне не оч нравится такой вариант сам по себе) Если нужно присвоить потомку неопределенный набор свойств, то можно сделать` <Child {...childProps} />` остальное я бы вычислил где-нибудь до этапа рендеринга

Был такой паттерн во флексе - лейаут. Так вот, ты делал контейнер, а потом передавал в него такой вот проперти-компонент. Было удобно

Но там все было завязано на наследование

Так и сейчас можно) Ток без наследования

Доберусь до твердой поверхности, скину подробности

Так и сейчас можно) Ток без наследования

Есть разница, насколько я помню

ERROR: S client not available

Всем привет. Кто-нибудь делал авторизацию через oAuth на create-react-app?

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

В реакте так будет сделать сложновато, я знаю только вариант через атрибуты

Либо как-то в проперти компоненте указывать его тип и по нему резолвить поведение

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

Типа layout: ILayout

А почему не прокидывать компоненты в пропсы просто? Без чайлдов

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

Typescript / Flow

Typescript / Flow

Спскп

Проблема с переносом атрибутов в теги остается пока

Ну в плане что мне не оч нравится такой вариант сам по себе) Если нужно присвоить потомку неопределенный набор свойств, то можно сделать` <Child {...childProps} />` остальное я бы вычислил где-нибудь до этапа рендеринга

Нет, я не про случайные свойства говорю, я говорю про разные типы компонентов, каждый со своим набором свойств в качестве потомков. И вот тут встает вопрос, как определить, какого типа потомки были переданы. Резолвить на основе набора пропсов как-то адово выглядит :)

А почему не прокидывать компоненты в пропсы просто? Без чайлдов

А как ты их будешь различать?

А почему не прокидывать компоненты в пропсы просто? Без чайлдов

Нативный синтаксис для разметки — когда вкладываешь через <Container> <Child /> </Container>

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

А, понял про что ты

А почему не прокидывать компоненты в пропсы просто? Без чайлдов

Я здесь вижу не очень очевидную для моей задачи конструкцию.

Это мы опять к XML возвращаемся, нее, лучше уж атрибуты))

Ребята, никто не хочет сделать пример css in js, для этого репозитория: https://github.com/AleshaOleg/holy-grail-markup? Мы там собрали, все примеры верстки на CSS и css-in-js смотрелся бы там очень круто.

зачем плодить репозитории ? такой уже есть

Это мы опять к XML возвращаемся, нее, лучше уж атрибуты))

Это когда хмл внутри кода внутри хмл внутри кода?

Возможно в каких-то других случаях можно, у меня так работает рендер компонентов зависящих от данных, вроде <ComponentLoader url="..." component={result => <SomeComponent data={result}} />} />

Однозначно лучше

Это когда в layout вкладывается <VerticalLayout gap="10"/> просто для задания свойств

Однозначно лучше

Но вот в изначальном варианте вопроса, мне тогда проще сделать так: <DataTable columns={{name: 'Имя', email: 'Email'}} />

Но вот в изначальном варианте вопроса, мне тогда проще сделать так: <DataTable columns={{name: 'Имя', email: 'Email'}} />

так неудобно будет задавать порядок столбцов

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

Это не совсем то, над чем был мой саркози

так неудобно будет задавать порядок столбцов

Вот, да, еще один подводный камент. Тогда просто [{field: 'name', title: 'Имя'}, ...]}

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

Ешё хуже)

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

Ну это понятно. Когда их там с пол сотни, там тоже каша получается. Хотя в таких случаях надо выносить в компоненты все это безобразие. Где та грань...

По обновлению сервис воркера - он сам обновит клиента

Можно подробнее о том как это происходит?

Ешё хуже)

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