т.е. я считаю что styled components это для расширения набора стандартных html тегов

Это что за зверь?

когда в компоненте куча пропсов

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

т.е. я считаю что styled components это для расширения набора стандартных html тегов

Да. Теперь и я так считаю. Точнее до старта проекта я так считал, потом меня убедили в обратном, и теперь я все же понял что буду отстаивать свою точку зрения

когда в компоненте куча пропсов

Ну и такое бывает.

как избежать hella props?

группировать данные

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

которые уже не должны быть стайлед.

ну styled для меня это набор цсс-а вокруг дива по-сути

кстати тут ебался с ними

ну представь, есть у нас такая абстракция как PhotoAsset (словами бизнес языка photo asset). эта штука должна отображать какой-то фото ассет. Соответственно styled-component PhotoAssetTitle вообще не должен существовать

По идее да у тебя должен быть большой такой organism <PhotoAsset /> допустим И вот из каких кусков он внутри устроен уже не важно его можно потом перефигачить как захочется в этом главная суть atomic design ты инкапсулируешь всю сложность

да. у нас произошло смешание с бизнес языком. и это очень дерьмово, если честно

забыл про что )

По идее да у тебя должен быть большой такой organism <PhotoAsset /> допустим И вот из каких кусков он внутри устроен уже не важно его можно потом перефигачить как захочется в этом главная суть atomic design ты инкапсулируешь всю сложность

все, успокоил. спасибо, пойду дальше рефакторить и писать кит

группировать данные

группировать в смысле объекты юзать?

угу

не получится?

да почему, получится

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

то может у тебя компонент дохуя делает?

если они разные

эм

это звоночек — попробуй посмотри, может разнести получится

ну, это такой вот компонент большой

он много где используется

и его разбить не получится

ну да

ну сгрупируй рэнджи в ranges

просто много колбеков )

как избежать hella props?

Покажи

как минимум

ну сгрупируй рэнджи в ranges

ranges?

ну блин, startData end Date - это же диапазон

range

плюс время

ааа

уже эти четыре проперти можно сгруппировать

ты про это

ага

хуево что вот

если 6 пропсов и они имеют одинаковый проптайпс

объединить бы

чтобы не плодить проптайпсы

flow ;)

то может у тебя компонент дохуя делает?

А если у меня компонент берёт много пропсов, но при рендере просто раздаёт их подкомпонентам, это ок?

А если у меня компонент берёт много пропсов, но при рендере просто раздаёт их подкомпонентам, это ок?

вот, так же и у меня

народ кто юзает AssetsPlugin для вебпака?

не могу понять как бандл с хешем в имени динамически подложить в индексный файл

Вот есть «уникальный» дизайн, и думаю. Писать «уникальную» библиотеку компонентов или взять тот же самый react-bootstrap или semantic ui и его «перекрашивать» - где грань?

Вот есть «уникальный» дизайн, и думаю. Писать «уникальную» библиотеку компонентов или взять тот же самый react-bootstrap или semantic ui и его «перекрашивать» - где грань?

семантик скачиваешь полностью и делаешь тему под себя

ну или все компоненты создавать ...

я выбрал уже на 2-х проектах семантик и свою тему — и ни разу не пожалел

ну или все компоненты создавать ...

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

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

та начали мы это как-то делать ... и быстро так свернули. хотя если совсем уникальный дизайн - то вариантов как бы и нет

Всем привет ) Традиция так традиция: 1) Проект — подбор строй оборудования 2) Слишком сильное слово ) 3) Разберемся ) 4) Изучаю React ( + Python), для смены стека (сейчас PHP) #whois

О, мужик. Один из немногих, кто это сделал)

ну это так себе нужно, мне кажется

Господа, а это нормально, если у действия нет редуктора? Вот, например, есть два асинхронных действия ЗагрузитьА и ЗагрузитьБ. Они оба очищают список ошибок загрузки и дёргают асинхронные запросы А и Б. Список ошибок загрузки очищается отдельным действием ОчиститьОшибки с собственным редуктором. Тогда, получается что, раз действия ЗагрузитьА и ЗагрузитьБ кроме вызова асинхронных запросов и вызова ОчиститьОшибки ничего не делают, то им и редукторы не нужны. Тогда и типы действий им не нужны — ведь они нужны только для связи с редуктором. им нужны только свои actionCreator и всё. Где я тут ошибся? Или так и есть?

Примерно так выглядит export const MY_REQUEST = 'MY_REQUEST' export function actionMyRequest (data) { return dispatch => { dispatch( { type: MY_REQUEST, } ) dispatch(actionNotificationClear()) return api .add(data) .then( () => dispatch(actionMySuccess(data)) ) .catch( error => dispatch(actionNotificationShow(error)) ); } }

Получается что первый dispatch и не нужен, он всё равно никакой редуктор не запустит

Эмпирическое правило — если ты видишь в своем коде два вызова экшнов подряд, то можно смело создавать issue про технический долг

Эмпирическое правило — если ты видишь в своем коде два вызова экшнов подряд, то можно смело создавать issue про технический долг

Вот я про это и спрашиваю

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

какой-то реально диспатч головного мозга.. это жи экшен-криэтор, причем тут обращение к API, и нотификашки...

Проще говоря, тупо вынеси в экшн что у них общего и не дергай стор чаще нужного)

ERROR: S client not available

Проще говоря, тупо вынеси в экшн что у них общего и не дергай стор чаще нужного)

Я и вынес. Просто получается что у них не осталось отличающегося способа менять state. Поэтому им не нужны собственные редукторы.

какой-то реально диспатч головного мозга.. это жи экшен-криэтор, причем тут обращение к API, и нотификашки...

Кхм, а где ж мне на сервер за данными ходить, как не тут?

Если что то выглядит как утка и крякает как утка, то значит это она и есть

Если что то выглядит как утка и крякает как утка, то значит это она и есть

Можно чуточку раскрыть мысль?

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

обращение к API должно быть в сервисе... сервис можно вызвать из экшен криэтора, но нотификашки точно должны быть во вьюхе (или лэйауте)!! Поэтому мне нравится redux-saga ))) там все оркестрирование сценарием в саге

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

Не совсем так. Я пришёл к выводу что мне нужен actionCreator, который дёрнет асинхронщину и другое действие. Но не нужен редуктор для него. потому что он напрямую не меняет в state ничего. И это очень странно, КМК. Я и спрашиваю совета — насколько это нормально?

Эмпирическое правило — если ты видишь в своем коде два вызова экшнов подряд, то можно смело создавать issue про технический долг

А если мне нужна дата из 2х разных экшенов в вообще 3-с контейнере?

почему плохо вызывать сервис в actionCreator'е? Потому что можно сделать dispatch(ACTION) вручную и что произойдет? Ничего )

Подскажите, как сделать так, чтобы реакт не пихал стили внутрь страницы через <style> Я подключаю import './styles/app.styl'; И в вебпаке указываю, что нужно экспортировать стили в отдельный файл: plugins: [ new ExtractTextPlugin('../css/app.css') ] Но, реакт все равно пихает стили в страницу. Получается, у меня грузятся 2 раза одни и те же стили.

обращение к API должно быть в сервисе... сервис можно вызвать из экшен криэтора, но нотификашки точно должны быть во вьюхе (или лэйауте)!! Поэтому мне нравится redux-saga ))) там все оркестрирование сценарием в саге

что за сервисы?

у меня это обычно выглядит так: fechData () => { return { action: FETCH_DATA, payload: MyService.fetchData() }

ну то есть они должны быть как можно более атомарны

сами экшен криэторы

А если мне нужна дата из 2х разных экшенов в вообще 3-с контейнере?

Дата из экшнов — это нонсенс)

ну то есть они должны быть как можно более атомарны

++

почему плохо вызывать сервис в actionCreator'е? Потому что можно сделать dispatch(ACTION) вручную и что произойдет? Ничего )

Ну я так и делаю

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

Дата из экшнов — это нонсенс)

Надо дернуть экшн, тот передам в редюсер, тот запишет в стор, контейнер замапит в пропсы

у меня это обычно выглядит так: fechData () => { return { action: FETCH_DATA, payload: MyService.fetchData() }

а асинхронно?)

из сервиса можно вызывать другой сервис

Я сократил до 1 действия :)

асинхронно и есть

в payload идет промис

из сервиса можно вызывать другой сервис

точнее не так сказал. Из сервиса можно вызывать другие методы этого сервиса и другие методы других сервисов )

какой-то ангуляр

в payload идет промис

?

короче ты создаешь экшен каждый раз новый на каждое действие - если даже там огромный сценарий есть стартовый экшен...

а резолвится в редьюсере?

Еее асинхронные редюсеры

кто? payload?