关于javascript:自己手写一个redux

提起 Redux 咱们想到最多的应该就是 React-redux 这个库，可是实际上 Redux 和 React-redux 并不是同一个货色, Redux 是一种架构模式，源于 Flux。 React-redux 是 Redux 思维与 React 联合的一种具体实现。
在咱们应用 React 的时候，经常会遇到组件深层次嵌套且须要值传递的状况，如果应用 props 进行值的传递，显然是十分苦楚的。为了解决这个问题，React 为咱们提供了原生的 context API，但咱们用的最多的解决方案却是应用 React-redux 这个基于 context API 封装的库。
本文并不介绍 React-redux 的具体用法，而是通过一个小例子，来理解下什么是 redux。

好了，当初咱们言归正传，来实现咱们本人的 redux。

一、最后

首先，咱们用 creat-react-app 来创立一个我的项目，删除 src 下冗余局部，只保留 index.js，并批改 index.html 的 DOM 构造：

# index.html<div id="root">  <div id="head"></div>  <div id="body"></div></div>

咱们在 index.js 中创立一个对象，用它来贮存、治理咱们整个利用的数据状态，并用渲染函数把数据渲染在页面：

const appState = {  head: {    text: '我是头部',    color: 'red'  },  body: {    text: '我是body',    color: 'green'  }}function renderHead (state){  const head = document.getElementById('head')  head.innerText = state.head.text;  head.style.color = state.head.color;}function renderBody (state){  const body = document.getElementById('body')  body.innerText = state.body.text;  body.style.color = state.body.color;}function renderApp (state){  renderHead(state);  renderBody(state);}renderApp(appState);

此时运行代码，关上页面，咱们能够看到，在 head 中曾经呈现了红色字体的‘我是头部’，在 body 中呈现了绿色字体的‘我是body’。

如果咱们把 head 和 body 看作是 root 中的两个组件，那么咱们曾经实现了一个全局惟一的 state 。这个 state 是全局共享的，随处可调用的。
咱们能够批改 head 的渲染函数，来看下成果：

function renderHead (state){  const head = document.getElementById('head')  head.innerText = state.head.text + '--' + state.body.text;  head.style.color = state.head.color;  state.body.text = '我是通过 head 批改后的 body';}

咱们看到，在 head 渲染函数中，咱们不仅能够取用 body 属性的值，还能够扭转他的值。这样就存在一个重大的问题，因为 state 是全局共用的，一旦在一个中央扭转了 state 的值，那么，所有用到这个值的组件都将受到影响，而且这个扭转是不可预期的，显然给咱们的代码调试减少了难度系数，这样的后果是咱们不违心看到的！

二、dispatch

当初看来，在咱们背后呈现了一个矛盾：咱们须要数据共享，但共享数据被任意的批改又会造成不可预期的问题！
为了解决这个矛盾，咱们须要一个管家，专门来治理共享数据的状态，任何对共享数据的操作都要通过他来实现，这样，就防止了随便批改共享数据带来的不可预期的危害！
咱们从新定义一个函数，用这个函数充当咱们的管家，来对咱们的共享数据进行治理：

function dispatch(state, action) {  switch (action.type) {    case 'HEAD_COLOR':      state.head.color = action.color      break    case 'BODY_TEXT':      state.body.text = action.text      break    default:      break  }}

咱们来从新批改head 的渲染函数：

function renderHead (state){  const head = document.getElementById('head')  head.innerText = state.head.text + '--' + state.body.text;  head.style.color = state.head.color;  dispatch(state, { type: 'BODY_TEXT', text: '我是 head 通过调用 dispatch 批改后的 body' })}

dispatch 函数接管两个参数，一个是须要批改的 state ，另一个是批改的值。这时，尽管咱们仍旧批改了 state ，然而通过 dispatch 函数，咱们使这种扭转变得可控，因为任何扭转 state 的行为，咱们都能够在 dispatch 中找到扭转的源头。
这样，咱们仿佛曾经解决了之前的矛盾，咱们创立了一个全局的共享数据，而且严格的把控了任何扭转这个数据的行为。
然而，在一个文件中，咱们既要保留 state，还要保护管家函数 dispatch，随着利用的越来越简单，这个文件势必会变得简短繁冗，难以保护。
当初，咱们把 state 和 dispatch 独自抽离进去：

用一个文件独自保留 state
用另一个文件独自保留 dispatch 中批改 state 的对照关系 changeState
最初再用一个文件，把他们联合起来，生成全局惟一的 store

这样，不仅使单个文件变得更加精简，而且在其余的利用中，咱们也能够很不便的复用咱们这套办法，只须要传入不同利用的 state 和批改 state 的对应逻辑 stateChange，就能够释怀的通过调用 dispatch 办法，对数据进行各种操作了：参考前端手写面试题具体解答

# 扭转咱们的目录构造，新增 redux 文件夹+ src++ redux--- state.js // 贮存利用数据状态--- storeChange.js //  保护一套批改 store 的逻辑,只负责计算，返回新的 store--- createStore.js // 联合 state 和 stateChange , 创立 store ,不便任何利用援用 --index.js ## 批改后的各个文件# state.js -- 全局状态export const state = {  head: {    text: '我是头部',    color: 'red'  },  body: {    text: '我是body',    color: 'green'  }}# storeChange.js -- 只负责计算，批改 storeexport const storeChange = (store, action) => {  switch (action.type) {    case 'HEAD_COLOR':      store.head.color = action.color      break    case 'BODY_TEXT':      store.body.text = action.text      break    default:      break  }}# createStore.js -- 创立全局 storeexport const createStore = (state, storeChange) => {  const store = state || {};  const dispatch = (action) => storeChange(store, action);  return { store, dispatch }}# index.js import { state } from './redux/state.js';import { storeChange } from './redux/storeChange.js';import { createStore } from './redux/createStore.js';const { store, dispatch } = createStore(state, storeChange)function renderHead (state){  const head = document.getElementById('head')  head.innerText = state.text;  head.style.color = state.color;}function renderBody (state){  const body = document.getElementById('body')  body.innerText = state.text;  body.style.color = state.color;}function renderApp (store){  renderHead(store.head);  renderBody(store.body);}// 首次渲染renderApp(store);

通过以上的文件拆分，咱们看到，不仅使单个文件更加精简，文件的职能也更加明确：

在 state 中，咱们只保留咱们的共享数据
在 storeChange 中，咱们来保护扭转 store 的对应逻辑，计算出新的 store
在 createStore 中，咱们创立 store
在 index.js 中，咱们只须要关怀相应的业务逻辑

三、subscribe

所有仿佛都那么美妙，可是当咱们在首次渲染后调用 dispatch 批改
store 时，咱们发现，尽管数据被扭转了，可是页面并没有刷新，只有在 dispatch 扭转数据后,从新调用 renderApp() 能力实现页面的刷新。

// 首次渲染renderApp(store);dispatch({ type: 'BODY_TEXT', text: '我是调用 dispatch 批改的 body' }) // 批改数据后，页面并没有主动刷新renderApp(store);  // 从新调用 renderApp 页面刷新

这样，显然并不能达到咱们的预期，咱们并不想在每次扭转数据后手动的刷新页面，如果能在扭转数据后，主动进行页面的刷新，当然再好不过了！
如果间接把 renderApp 写在 dispatch 里，显然是不太适合的，这样咱们的 createStore 就失去了通用性。
咱们能够在 createStore 中新增一个收集数组，把 dispatch 调用后须要执行的办法对立收集起来，而后再循环执行，这样，就保障了 createStore 的通用性：

# createStoreexport const createStore = (state, storeChange) => {  const listeners = [];  const store = state || {};  const subscribe = (listen) => listeners.push(listen);   const dispatch = (action) => {    storeChange(store, action);    listeners.forEach(item => {      item(store);    })  };  return { store, dispatch, subscribe }}# index.js···const { store, dispatch, subscribe } = createStore(state, storeChange)··· ···// 增加 listenerssubscribe((store) => renderApp(store));renderApp(store);dispatch({ type: 'BODY_TEXT', text: '我是调用 dispatch 批改的 body' });

这样，咱们每次调用 dispatch 时，页面就会从新刷新。如果咱们不想刷新页面，只想 alert 一句话，只须要更改增加的 listeners 就好了：

subscribe((store) => alert('页面刷新了'));renderApp(store);dispatch({ type: 'BODY_TEXT', text: '我是调用 dispatch 批改的 body' });

这样咱们就保障了 createStore 的通用性。

四、优化

到这里，咱们仿佛曾经实现了之前想达到的成果：咱们实现了一个全局专用的 store ，而且这个 store 的批改是通过严格把控的，并且每次通过 dispatch 批改 store 后，都能够实现页面的主动刷新。
可是，显然这样并不足够，以上的代码仍有些简陋，存在重大的性能问题，

尽管咱们只是批改了 body 的文案，可是，在页面从新渲染时，head 也被再次渲染。那么，咱们是不是能够在页面渲染的时候，来比照新旧两个 store 来感知哪些局部须要从新渲染，哪些局部不用再次渲染呢？
依据下面的想法，咱们再次来批改咱们的代码:

# storeChange.jsexport const storeChange = (store, action) => {  switch (action.type) {    case 'HEAD_COLOR':      return {         ...store,          head: {           ...store.head,           color: action.color         }      }    case 'BODY_TEXT':      return {         ...store,        body: {          ...store.body,          text: action.text        }      }    default:      return { ...store }  }}# createStore.jsexport const createStore = (state, storeChange) => {  const listeners = [];  let store = state || {};  const subscribe = (listen) => listeners.push(listen);  const dispatch = (action) => {    const newStore = storeChange(store, action);    listeners.forEach(item => {      item(newStore, store);    })    store = newStore;   };  return { store, dispatch, subscribe }}# index.jsimport { state } from './redux/state.js';import { storeChange } from './redux/storeChange.js';import { createStore } from './redux/createStore.js';const { store, dispatch, subscribe } = createStore(state, storeChange);function renderHead (state){  console.log('render head');  const head = document.getElementById('head')  head.innerText = state.text;  head.style.color = state.color;}function renderBody (state){  console.log('render body');  const body = document.getElementById('body')  body.innerText = state.text;  body.style.color = state.color;}function renderApp (store, oldStore={}){  if(store === oldStore) return;   store.head !== oldStore.head && renderHead(store.head);    store.body !== oldStore.body && renderBody(store.body);    console.log('render app',store, oldStore);}// 首次渲染subscribe((store, oldStore) => renderApp(store, oldStore));renderApp(store);dispatch({ type: 'BODY_TEXT', text: '我是调用 dispatch 批改的 body' });

以上，咱们批改了 storeChange ，让他不再间接批改原来的 store，而是通过计算，返回一个新的 store 。咱们又批改了 cearteStore 让他接管 storeChange 返回的新 store ，在 dispatch 批改数据并且页面刷新后，把新 store 赋值给之前的 store 。而在页面刷新时，咱们来通过比拟 newStore 和 oldStore ，感知须要从新渲染的局部，实现一些性能上的优化。

最初

咱们通过简略的代码例子，简略理解下 redux，尽管代码仍有些简陋，可是咱们曾经实现了 redux 的几个核心理念：

利用中的所有state都以一个object tree的模式存储在一个繁多的store中。
惟一能改store的办法是触发action，action是动作行为的形象。