为何运用redux
运用react构建大型运用，势必会面对状况治理的题目，redux是经常使用的一种状况治理库，我们会由于种种原因此须要运用它。
- 差别的组件能够会运用雷同的数据，运用redux能更好的复用数据和坚持数据的同步
- react中子组件接见父组件的数据只能经由过程props层层通报，运用redux能够轻松的接见到想要的数据
- 全局的state能够很轻易的举行数据耐久化，轻易下次启动app时取得初始state
- dev tools供应状况快照回溯的功用，轻易题目的排查
但并非一切的state都要交给redux治理，当某个状况数据只被一个组件依靠或影响，且在切换路由再次返回到当前页面不须要保存操纵状况时，我们是没有必要运用redux的，用组件内部state足以。比方下拉框的显现与封闭。
罕见的状况范例
react运用中我们会定义许多state，state终究也都是为页面展现效劳的，依据数据的泉源、影响的局限大抵能够将前端state归为以下三类：
Domain data: 平常能够理解为从效劳器端猎取的数据，比方帖子列表数据、批评数据等。它们能够被运用的多个处所用到，前端须要关注的是与后端的数据同步、提交等等。
UI state: 决议当前UI怎样展现的状况，比方一个弹窗的开闭，下拉菜单是不是翻开，每每聚焦于某个组件内部，状况之间能够相互自力，也能够多个状况配合决议一个UI展现，这也是UI state治理的难点。
App state: App级的状况，比方当前是不是有要求正在loading、某个联系人被选中、当前的路由信息等能够被多个组件配合运用到状况。
怎样设想state构造
在运用redux的过程当中，我们都邑运用modules的体式格局，将我们的reducers拆分到差别的文件当中，一般会遵照高内聚、轻易运用的准绳，按某个功用模块、页面来分别。那关于某个reducer文件，怎样设想state构造能更轻易我们治理数据呢，下面列出几种罕见的体式格局：
1.将api返回的数据直接放入state
这类体式格局大多会出现在列表的展现上，如帖子列表页，由于背景接口返回的数据一般与列表的展现构造基础一致，能够直接运用。
2.以页面UI来设想state构造
以下面的页面，分为三个section，对应开户中、行将流失、已提交考核三种差别的数据范例。
由于页面是展现性的没有太多的交互，所以我们完全能够依据页面UI来设想以下的构造：
tabData: {
opening: [{
userId: "6332",
mobile: "1858849****",
name: "test1",
...
}, ...],
missing: [],
commit: [{
userId: "6333",
mobile: "1858849****",
name: "test2",
...
}, ... ]
}如许设想比较轻易我们将state映射到页面，拉取更多数据只须要将新数据简朴contact进对应的数组即可。关于简朴页面，如许是可行的。
3.State范式化(normalize)
许多情况下，处置惩罚的数据都是嵌套或相互关联的。比方，一个群列表，由许多群构成，每一个群又包括许多个用户，一个用户能够到场多个差别的群。这类范例的数据，我们能够轻易用以下构造示意：
const Groups = [
{
id: 'group1',
groupName: '连线电商',
groupMembers: [
{
id: 'user1',
name: '张三',
dept: '电商部'
},
{
id: 'user2',
name: '李四',
dept: '电商部'
},
]
},
{
id: 'group2',
groupName: '连线资管',
groupMembers: [
{
id: 'user1',
name: '张三',
dept: '电商部'
},
{
id: 'user3',
name: '王五',
dept: '电商部'
},
]
}
]这类体式格局，对界面展现很友爱，展现群列表，我们只需遍历Groups数组，展现某个群成员列表，只需遍历相应索引的数据Groups[index]，展现某个群成员的数据，继承索引到对应的成员数据GroupsgroupIndex即可。
然则这类体式格局有一些题目：
- 存在许多反复数据，当某个群成员信息更新的时刻，想要在差别的群之间举行同步比较贫苦。
- 嵌套过深，致使reducer逻辑庞杂，修正深层的属性会致使代码痴肥，空指针的题目
- redux中须要遵照不可变动新模式，更新属性每每须要更新组件树的先人，发作新的援用，这会致使跟修正数据无关的组件也要从新render。
为了防止上面的题目，我们能够自创数据库存储数据的体式格局，设想出相似的范式化的state，范式化的数据遵照下面几个准绳：
- 差别范例的数据，都以“数据表”的情势存储在state中
- “数据表” 中的每一项条目都以对象的情势存储，对象以唯一性的ID作为key，条目自身作为value。
- 任何对单个条目的援用都应该依据存储条目的 ID 来索引完成。
- 数据的递次经由过程ID数组示意。
上面的示例范式化以后以下：
{
groups: {
byIds: {
group1: {
id: 'group1',
groupName: '连线电商',
groupMembers: ['user1', 'user2']
},
group2: {
id: 'group2',
groupName: '连线资管',
groupMembers: ['user1', 'user3']
}
},
allIds: ['group1', 'group2']
},
members: {
byIds: {
user1: {
id: 'user1',
name: '张三',
dept: '电商部'
},
user2: {
id: 'user2',
name: '李四',
dept: '电商部'
},
user3: {
id: 'user3',
name: '王五',
dept: '电商部'
}
},
allIds: []
}
}与本来的数据比拟有以下革新：
- 由于数据是扁平的，且只被定义在一个处所，更轻易数据更新
- 检索或许更新给定数据项的逻辑变得简朴与一致。给定一个数据项的 type 和 ID，没必要嵌套援用其他对象而是经由过程几个简朴的步骤就可以查找到它。
- 每一个数据范例都是唯一的，像用户信息如许的更新仅仅须要状况树中 “members > byId > user” 这部份的复制。这也就意味着在 UI 中只要数据发作变化的一部份才会发作更新。与之前的差别的是，之前嵌套情势的构造须要更新全部 groupMembers数组，以及全部 groups数组。如许就会让没必要要的组件也再次从新衬着。
一般我们接口返回的数据都是嵌套情势的，要将数据范式化，我们能够运用Normalizr这个库来辅佐。
固然如许做之前我们最好问本身，我是不是须要频仍的遍历数据，是不是须要疾速的接见某一项数据，是不是须要频仍更新同步数据。
更进一步
关于这些关联数据，我们能够一致放到entities中举行治理，如许root state，看起来像如许：
{
simpleDomainData1: {....},
simpleDomainData2: {....}
entities : {
entityType1 : {byId: {}, allIds},
entityType2 : {....}
}
ui : {
uiSection1 : {....},
uiSection2 : {....}
}
}实在上面的entities并不够地道，由于个中包括了关联关联（group内里包括了groupMembers的信息），也包括了列表的递次信息（如每一个实体的allIds属性）。更进一步，我们能够将这些信息剥离出来，让我们的entities越发简朴，扁平。
{
entities: {
groups: {
group1: {
id: 'group1',
groupName: '连线电商',
},
group2: {
id: 'group2',
groupName: '连线资管',
}
},
members: {
user1: {
id: 'user1',
name: '张三',
dept: '电商部'
},
user2: {
id: 'user2',
name: '李四',
dept: '电商部'
},
user3: {
id: 'user3',
name: '王五',
dept: '电商部'
}
}
},
groups: {
gourpIds: ['group1', 'group2'],
groupMembers: {
group1: ['user1', 'user2'],
group2: ['user2', 'user3']
}
}
}
如许我们在更新entity信息的时刻，只需操纵对应entity就可以够了，增加新的entity时则须要在对应的对象如entities[group]中增加group对象，在groups[groupIds]中增加对应的关联关联。
enetities.js
const ADD_GROUP = 'entities/addGroup';
const UPDATE_GROUP = 'entities/updateGroup';
const ADD_MEMBER = 'entites/addMember';
const UPDATE_MEMBER = 'entites/updateMember';
export const addGroup = entity => ({
type: ADD_GROUP,
payload: {[entity.id]: entity}
})
export const updateGroup = entity => ({
type: UPDATE_GROUP,
payload: {[entity.id]: entity}
})
export const addMember = member => ({
type: ADD_MEMBER,
payload: {[member.id]: member}
})
export const updateMember = member => ({
type: UPDATE_MEMBER,
payload: {[member.id]: member}
})
_addGroup(state, action) {
return state.set('groups', state.groups.merge(action.payload));
}
_addMember(state, action) {
return state.set('members', state.members.merge(action.payload));
}
_updateGroup(state, action) {
return state.set('groups', state.groups.merge(action.payload, {deep: true}));
}
_updateMember(state, action) {
return state.set('members', state.members.merge(action.payload, {deep: true}))
}
const initialState = Immutable({
groups: {},
members: {}
})
export default function entities(state = initialState, action) {
let type = action.type;
switch (type) {
case ADD_GROUP:
return _addGroup(state, action);
case UPDATE_GROUP:
return _updateGroup(state, action);
case ADD_MEMBER:
return _addMember(state, action);
case UPDATE_MEMBER:
return _updateMember(state, action);
default:
return state;
}
}能够看到，由于entity的构造大抵雷同，所以更新起来许多逻辑是差不多的，所以这里能够进一步提取公用函数，在payload内里到场要更新的key值。
export const addGroup = entity => ({
type: ADD_GROUP,
payload: {data: {[entity.id]: entity}, key: 'groups'}
})
export const updateGroup = entity => ({
type: UPDATE_GROUP,
payload: {data: {[entity.id]: entity}, key: 'groups'}
})
export const addMember = member => ({
type: ADD_MEMBER,
payload: {data: {[member.id]: member}, key: 'members'}
})
export const updateMember = member => ({
type: UPDATE_MEMBER,
payload: {data: {[member.id]: member}, key: 'members'}
})
function normalAddReducer(state, action) {
let payload = action.payload;
if (payload && payload.key) {
let {key, data} = payload;
return state.set(key, state[key].merge(data));
}
return state;
}
function normalUpdateReducer(state, action) {
if (payload && payload.key) {
let {key, data} = payload;
return state.set(key, state[key].merge(data, {deep: true}));
}
}
export default function entities(state = initialState, action) {
let type = action.type;
switch (type) {
case ADD_GROUP:
case ADD_MEMBER:
return normalAddReducer(state, action);
case UPDATE_GROUP:
case UPDATE_MEMBER:
return normalUpdateReducer(state, action);
default:
return state;
}
}将loading状况抽离到根reducer中，一致治理
在要求接口时，一般会dispatch loading状况，一般我们会在某个接口要求的reducer内里来处置惩罚相应的loading状况，这会使loading逻辑随处都是。实在我们能够将loading状况作为根reducer的一部份，零丁治理，如许就可以够复用相应的逻辑。
const SET_LOADING = 'SET_LOADING';
export const LOADINGMAP = {
groupsLoading: 'groupsLoading',
memberLoading: 'memberLoading'
}
const initialLoadingState = Immutable({
[LOADINGMAP.groupsLoading]: false,
[LOADINGMAP.memberLoading]: false,
});
const loadingReducer = (state = initialLoadingState, action) => {
const { type, payload } = action;
if (type === SET_LOADING) {
return state.set(key, payload.loading);
} else {
return state;
}
}
const setLoading = (scope, loading) => {
return {
type: SET_LOADING,
payload: {
key: scope,
loading,
},
};
}
// 运用的时刻
store.dispatch(setLoading(LOADINGMAP.groupsLoading, true));如许当须要增加新的loading状况的时刻，只须要在LOADINGMAP和initialLoadingState增加相应的loading type即可。
也能够参考dva的完成体式格局，它也是将loading存储在根reducer，并且是依据model的namespace作为辨别，
它轻易的处所在于将更新loading状况的逻辑被提取到plugin中，用户不须要手动编写更新loading的逻辑，只须要在用到时刻运用state即可。plugin的代码也很简朴，就是在钩子函数中阻拦副作用。
function onEffect(effect, { put }, model, actionType) {
const { namespace } = model;
return function*(...args) {
yield put({ type: SHOW, payload: { namespace, actionType } });
yield effect(...args);
yield put({ type: HIDE, payload: { namespace, actionType } });
};
}其他
关于web端运用，我们无法控制用户的操纵途径，极能够用户在直接接见某个页面的时刻，我们store中并没有准备好数据，这能够会致使一些题目，所以有人发起以page为单元分别store，舍弃掉部份多页面同享state的优点，详细能够参考这篇文章，个中提到在视图之间同享state要郑重，实在这也反映出我们在思索是不是要同享某个state时，思索以下几个题目：
- 有若干页面会运用到该数据
- 每一个页面是不是须要零丁的数据副本
- 修改数据的频次怎样
参考文章
https://www.zhihu.com/questio…
https://segmentfault.com/a/11…
https://hackernoon.com/shape-…
https://medium.com/@dan_abram…
https://medium.com/@fastphras…
https://juejin.im/post/59a16e…
http://cn.redux.js.org/docs/r…
https://redux.js.org/recipes/…
