redux常见问题答疑

为何使用redux

React的核心是将UI组件化，由数据驱动UI的展示。可是如何管理数据模型、组件与数据模型之间的通讯，react并无很好的解决方案。Redux由flux演变而来，同时简化了Flux的流程。

仅仅使用react进行开发的痛点

1. 组件嵌套层级深，回调地狱。你可能会在一个较深层次的组件里须要更新全局state的某个字段，却无奈只能经过从顶层组件一层一层传递下来的props进行回调。

2. 页面的state不可预测。因为state缺少一种可预测的机制，致使用户在进行一些页面操做(更改state)，或者异步请求有新的数据从服务端返回的时候，state的变化已经不可控制，很容易产生bug

redux是怎么解决痛点的？

一、经过react-redux提供的Provider组件,在根组件外面包一层，这样根组件，以及全部的子组件都能拿到store。实现的原理是基于React自身提供的context属性，可是react官方不推荐直接在组件中使用this.context。因此react-redux提供了另外一种方法connect，经过connect将普通的UI组件升级为容器组件，同时将获取store的细节也一并封装在生成容器组件的代码中，从而容器组件能够直接拿到store

<Provider store={store}>
<App/>
</Provider>

// 定义App组件
class Foo extends React.Component{
    render() {
    const { text } = this.props;
    return <div>{text}</div>;
  }
}
const App = connect(
  mapStateToProps,
  mapDispatchToProps
)(Foo);

二、使用纯函数修改state，保证state变化可预测。每次更改都返回一个全新的state。
三、遵照容器组件与展现组件分离的原则。这是redux一个重要的思想，容器组件和展现组件各司其职。

容器组件

容器组件负责如下几件事情：

1. 处理数据逻辑

2. 将store中的state转变为props传递给展现组件，对应mapStateToProps

3. 将注入了dispatch的函数做为props传递给展现组件，对应mapDispatchToProps

4. 有状态的(展现组件则是无状态的)

5. 发起action，更新state

6. 没有DOM标签，没有样式

展现组件

可复用的组件，又称为“傻瓜组件”，仅仅经过容器组件传进来的props进行UI展现，以及操做回调。感知不到redux的存在，脱离redux框架也能使用，尽可能保持无状态(可包含少许的UI状态)，有如下几条原则：

1. 不理解数据逻辑：不关心数据是如何获得的，也不关心数据是如何改变的

2. 只经过props获取数据和操做回调

3. 基本是无状态的：必须有的话，能够是UI的状态

何时引入容器组件

在引入以前，你能够先只用展现组件来构建App。当你发现有些组件并不会用到传进来的属性，而仅仅只是把它往下传给子组件的时候(而且层级比较深，超过两层)，你就要考虑引入容器组件了。

为何使用immutable.js

首先，在没有immutable.js的状况下，碰到较深层次的数据结构时，更新state会变得很麻烦。

旧的state：

{
  priceInfo: {
    price: 200,
    promotion: {
      offValue: 30
    }
  }
}

如今须要只更新offValue的值为50，该怎么处理呢？

let newState = _.cloneDeep(this.state);
newState.priceInfo.promotion.offValue = 50;
this.setState(newState);

能够看到，须要先深度复制一份this.state，而后修改offValue的值，最后执行setState。除了这个过程的有点复杂，另外深度复制对象是挺耗性能的一件事。而经过Immutable.js，咱们只须要这样作：

let initialState = Immutable.fromJS({
  priceInfo: {
    price: 200,
    promotion: {
      offValue: 30
    }
  }
});
this.setState(initialState.setIn(['priceInfo', 'promotion', 'offValue']), 50);

immutable.js带来的性能提高

React作性能优化时常常用到 shouldComponentUpdate，只有深度比较才能得出正确的值，决定是否render，而深度比较是十分消耗性能的。Immutable 则提供了简洁高效的判断数据是否变化的方法，只需 === 和 is 比较就能知道是否须要执行render()，而这个操做几乎零成本，因此能够极大提升性能。

immutable.js的数据结构如何正确使用...扩展运算符

在jsx的语法中，你已经习惯了使用扩展运算符来传递props，以下所示：

const titleInfo = {
  title: '主标题',
  subTitle: '副标题'
};

...

import Title from 'title';

render() {
  return (
    <Title {...titleInfo}/>
  );
}

可是若是你要传递的数据是Immutable.Map类型的，使用...扩展运算符，获得的数据可能与你指望的不太同样，由于Immutable.Map的实例对象并非plain object。{...titleInfo}等同于Object.assign({}, titleInfo)。Immutable.js提供了一种方法，能够实现这种转换，若是是Map实例，只需调用toObject()(不要调用深度复制的toJS)，就能够将Immutable.js的Map对象转变为可使用...扩展运算符的plain object。