Вы запросили список юзеров и список журналов и ... еще

Question

Вы запросили список юзеров и список журналов и ... еще

10 наборов разнородных данных. как будет выглядеть функция-редьюсер? будет ли она "редьюсер"? что будет со стейтом, когда изменится список журналов? теперь уложите это в идею редакса. это редакс? , теперь добавьте туда шаред стейт компонентов - как его обрабатывать? вас сильно это спасло от констант?

#frontend #javascript #programming #react.js #russian

0

20.02.2018

1 ответов

9 просмотров

Богдан · Accepted Answer

Попробую объяснить поподробней - я когда писал проект на редаксе решил не дублировать редюсеры и не создавать кучу отдельных экшенов. Потому что в таких редюсерах непременно будет дублирование функционала подобно такому case "CREATE_PROJECT": { return {...state, projects: {...state.projects, [action.id]: action.data} } case "CREATE_TASK": { return {...state, tasks: {...state.tasks, [action.id]: action.data} } case "CREATE_COMMENT": { return {...state, comments: {...state.comments, [action.id]: action.data} } case "UPDATE_PROJECT": { return {...state, projects: {...state.projects, [action.id]:{...state.projects[action.data.id], ...action.data}} } case "UPDATE_TASK": { return {...state, tasks: {...state.tasks, [action.id]:{...state.tasks[action.data.id], ...action.data}} } case "UPDATE_COMMENT": { return {...state, comments: {[action.id]:{...state.comments[action.data.id], ...action.data}} }Из всего этого меняется только имя таблицы и логично не дублировать функционал и передать имя таблицы параметром case CREATE: { return {...state, [action.table]: { ...state[action.table], [action.id]: action.data}} } case UPDATE: { return {...state, [action.table]: { ...state[action.table], [action.id]: {...state[action.table][action.id], ...action.data}}} }Когда с редаксом мы вынуждены нормализировать стор то все данные будут организованы в плоском списке айдишников в хеш-таблицах. И для того чтобы не дублировать код как выше где дублируется весь код кроме имени мне кажется вполне логичным сделать передачу таблицы параметром и тогда (в идеале) количество экшенов и редюсеров у нас сведется к 3 (плюс еще GET но он обработается в миддлварке). Дальше естественно есть некая бизнес-логика которая не затрагивает добавление, удаления или изменение не одного а много объектов. Эту логику можно конечно оставить в редюсерах и создавать отдельные экшены и редюсеры но почему тогда вообще не использовать редакс как базу данных а логику из редюсеров вынести в отдельные функции вроде thunk-ов или обычных функции. Например тот же редюсер и экшен которы можно назвать как UPDATE_POST_AND_CREATE_TASK а можно просто вынести в thunk который задиспатчит экшен UPDATE передав параметром таблицу "posts" и задиспатчит экшен "CREATE" и передаст параметром таблиу "tasks". И таким образом можно реализовать любую бизнес-логику и не ограничивать себя в невозможности выполнять сайд-эффекты как в редюсерах

169 похожих чатов

Вы запросили список юзеров и список журналов и ... еще

1 ответов

Похожие вопросы