AE
будут разные хеши
Size: a a a
2020 October 06
MK
Только не надо юзать стайлед в рендере
A
Это не стайлд, это просто css-модули
MK
Это не стайлд, это просто css-модули
Ну тогда просто другой класс добавляй если какому то компоненту нужно дополнить общие стили
A
Окей, спасибо
AP
вот меня волнует очень сильно вопрос с точки зрения архитектуры...
Допустим есть компонент "история запросов"...если был уже запрос, то брать результат из stora если нет, то обращаться к api
где писать логику которой решается использовать Thunk(асинхронное получение) или обычнй actionCreator(синхронное получение)??в компоненте контейнерной? или где?
Допустим есть компонент "история запросов"...если был уже запрос, то брать результат из stora если нет, то обращаться к api
где писать логику которой решается использовать Thunk(асинхронное получение) или обычнй actionCreator(синхронное получение)??в компоненте контейнерной? или где?
AK
Aleksandr Potkin
вот меня волнует очень сильно вопрос с точки зрения архитектуры...
Допустим есть компонент "история запросов"...если был уже запрос, то брать результат из stora если нет, то обращаться к api
где писать логику которой решается использовать Thunk(асинхронное получение) или обычнй actionCreator(синхронное получение)??в компоненте контейнерной? или где?
Допустим есть компонент "история запросов"...если был уже запрос, то брать результат из stora если нет, то обращаться к api
где писать логику которой решается использовать Thunk(асинхронное получение) или обычнй actionCreator(синхронное получение)??в компоненте контейнерной? или где?
с чего ты взял что в компоненте вообще должна быть логика?
MK
Aleksandr Potkin
вот меня волнует очень сильно вопрос с точки зрения архитектуры...
Допустим есть компонент "история запросов"...если был уже запрос, то брать результат из stora если нет, то обращаться к api
где писать логику которой решается использовать Thunk(асинхронное получение) или обычнй actionCreator(синхронное получение)??в компоненте контейнерной? или где?
Допустим есть компонент "история запросов"...если был уже запрос, то брать результат из stora если нет, то обращаться к api
где писать логику которой решается использовать Thunk(асинхронное получение) или обычнй actionCreator(синхронное получение)??в компоненте контейнерной? или где?
В санке
AE
Aleksandr Potkin
вот меня волнует очень сильно вопрос с точки зрения архитектуры...
Допустим есть компонент "история запросов"...если был уже запрос, то брать результат из stora если нет, то обращаться к api
где писать логику которой решается использовать Thunk(асинхронное получение) или обычнй actionCreator(синхронное получение)??в компоненте контейнерной? или где?
Допустим есть компонент "история запросов"...если был уже запрос, то брать результат из stora если нет, то обращаться к api
где писать логику которой решается использовать Thunk(асинхронное получение) или обычнй actionCreator(синхронное получение)??в компоненте контейнерной? или где?
компонент не должно волновать кто и откуда ему данные даст
AP
с чего ты взял что в компоненте вообще должна быть логика?
в контейнерной компоненте например
AK
Aleksandr Potkin
в контейнерной компоненте например
компоненте?
AP
компоненте?
да...слыхал про такие "контейнерные или умные"
MK
Aleksandr Potkin
да...слыхал про такие "контейнерные или умные"
Чел не трать время, проверку на наличие данных в редаксе делай в санке и если нету то запрашивай их
AP
В санке
тоесть даже если это будет синхронное получение, все равно в санке писать?
MK
Aleksandr Potkin
тоесть даже если это будет синхронное получение, все равно в санке писать?
Тебе надо будет взять из редакса данные а это в синхронном нельзя сделать
AP
Тебе надо будет взять из редакса данные а это в синхронном нельзя сделать
через обычные actionы
MK
Aleksandr Potkin
через обычные actionы
Тебе будет в кайф прокидывать в каждый экшон большой обект данных с редакса?
MK
Хотя понятие редакса и кайфа наверное росплывчастое)
AP
зачем пихать в payload большой объет данных?туда задумывается передавать id например