乐趣区

关于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 -- 只负责计算,批改 store
export 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 -- 创立全局 store
export 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 的通用性:

# createStore
export 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)
··· 
···
// 增加 listeners
subscribe((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.js
export 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.js
export 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.js
import {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 是动作行为的形象。
退出移动版