Day 23 Flux

第 23 天 !

使用 context 来传送，虽然达到了能跟 目标 component 直接对接的功能，

但是这样产生了问题，

由於可以直接传递到 component ， 这样会导致数据混乱，不好维护，

打个比方，

<App>
  <Child1>
    <Child2>
      <Child3></Child3>
    </Child2>
  </Child1>
</App>

当我在 Child1 & Child3 使用 context 获取资料，

当 context 更新， 同时会触发 Child1 & Child2 & Child3 的 re-render ， 这样无疑会增加效能的消耗

另外，由於资料的传送是以广播的形式送出，

当 context 更新，

只要是使用这个 context 的 component ，

都会被强制更新，

就算当下改变的资料跟这个 component 没关系，

还是会做 re-render 的动作

这无疑增加我们的效能成本

那还有其他选择嘛？

有！ 就是我们之後介绍的 Redux

但是我们要先来讨论一下， flux

Flux

什麽是 flux ?

它是由 facebook 提出的 design pattern ，

定义前端如何去做资料的变化＆保存，

核心概念就是 单向资料流，

flux 定义了三种主要部分：

action

定义改变资料的行为，

比如：一个计算机，我目前的动作是加法，那我要把输入的数字做加总

这就是一个 加法动作，

那要完成这个动作会分为 action & action creator，

通常会用 function 定义 action 的 type & 相关需要的参数，

最後把输出的 action 递给 dispatch

like:

const actionCreator = (count)=>{
  const action = {
    type: 'ADD',
    payload:{
      count
    }
  }
  dispatch(action);
}

dispatcher

是连接 action & store 的桥梁，

根据action 的资料做相关的处理， 并保存到 store 里

store

保存资讯的地方，只有 dispatch 可以改变资料，

其他地方只能做读取的动作，

当资料发生变化，

会发出通知告知 View 资料转变

PS. Store 可以不只一个

这是flux 官方的结构图

这样我们可以很清楚的看到，所有的动作都是单向的，

action 告知动作 > dispatcher 针对动作改变资料 > store 保存 > view 显示

这样的好处是，我们可以清晰的知道每个动作会影响的资料，

当发生错误时，我们可以了解在哪个动作发生了状况