乐趣区

关于javascript:原生javascript实现类redux状态管理器

react、vue 将一个利用划分成不同的组件,一个组件的状态可能会影响另一个组件,随着我的项目日渐简单,组件间通信就是一个令人头疼的问题 …

我:qio tto ma tte!我的项目日渐简单导致状态治理艰难?

  • 引起一个 model 变动的因素可能会有很多种:服务器响应、缓存数据、本地数据、ui 状态、用户事件 … 咱们怎么来解决这些状态?
  • 多个组件依赖同一个状态,各组件如何更新、同步状态?

那就是用 redux。

说到 redux,厉害了,她就是来解决这个问题的,所以不晓得的同学须要认真钻研钻研 redux。

开始了开始了

为了跟风前端新技术,为了晋升集体竞争力,必须要去理解一些原理,做一个知其所以然的智慧码农,他日软妹背后炫技,硬核自信不懵逼。

我心目中的状态治理

其实处于前端社会底层的搬砖少年,并没有什么心目中的状态,我就觉着 redux 挺好的,我很观赏

先外表上逢迎:卧槽,这概念,这招式,卧槽,厉害了;实际上心里真心觉着厉害。

我要是本人能实现一个,我是不是一样牛叉?是的!

当初,假如我曾经实现了这个状态管理器,我该怎么来用,什么姿态用的爽,值得思考 …

先创立个 module

const app = {
  namespace: 'app',
  state: {num: 0},
  actions: {change (state, value) {
      this.setState({num: value})
    }
  }
}

而后创立个 store

const store = createStore({modules: [app]
})

这个 store 就是咱们全局的状态,你能够把她类比为 redux 的 store,但请别说是抄的。

那么 store 还应该向外暴露出获取数据和批改数据的办法

store 应该蕴含的 api

const actions = store.mapActions({change: 'app/change'})
const states = store.mapStates({num: 'app/num'})

到这里,所有都那么理所应当,用法简单明了,一度狐疑本人是个蠢才。

const app = {
  namespace: 'app',
  state: {num: 0},
  actions: {change (state, value) {
      this.setState({num: value})
    }
  }
}
const {mapActions, mapStates} = createStore({modules: [app]
})
const actions = store.mapActions({change: 'app/change'})
const states = store.mapStates({num: 'app/num'})
actions.change(1)
states.num // 1

创立逻辑

忽然一下,如同没有了方向,面对本人意淫的假代码示例,再也不能应用 cc、cv 的挫败感油然而生,这种感觉就像是失恋了一样。

没方法,生存还要持续,依稀记得老师们说过:面对苦难,化繁为简,一一击破 …

于是你列下了几个实现步骤:

  1. store 是一个类
  2. 须要装置 app 这个 modules,要留神 modules 可能会有多个
  3. module 通过命名空间来划分
  4. 实现 mapActions
  5. 实现 mapStates
  6. 喝杯水,微信问候一下企慕已久的女神,过粗劣的生存

store 的实现

class Store {constructor (options) {this._state = {}
    this._modules = {}
    this.setModules(options.modules)
  }
  
  setModules (modules) {[].concat(modules).forEach(m => {
      let ns = m.namespace
      let _m = new Module(m, this)
      
      this._module[ns] = _m
      this._state[ns] = _m.state
    })
  }
}
function createStore (options) {return new Store(options)
}

你发现通过简略的组合能够简化 Store 的逻辑,所以你打算实现一个 Module 类以不便扩大

Module 类的实现

class Module {constructor (m, _store) {
    this._store = _store
    this.state = m.state
    this.actions = m.actions
    this.namespace = m.namespace
  }

  setState (state) {Object.assign(this.state, state)
  }
}

当初,store 的构造曾经能够整理出来了,然而办法(actions)、状态(state)还没方法裸露进来,所以当初须要来实现 mapActions、mapState。

dispatch 的必要性

想到之前 mapActions 的调用:

const actions = store.mapActions({change: 'app/change'})

难道,只是把 Module 的对应 actions 找到返回去就行了么,这也太 low 了吧,而 redux 的中间件都是通过批改 dispath 来实现加强和拓展,这太厉害了,借鉴借鉴。

所以,mapActions 应该都是对 dispatch 的封装实现;

dispatch 的实现

class Store {
  // ...
  dispatch = (path, ...args) => {let { ns, key} = normalizePath(path);
    ns = this._module[ns]

    if (!ns) {return}

    let action = ns.actions[key]

    return action.call(ns, ns.state,...args)
  }
}
function normalizePath (path) {const [ns, key] = path.split('/')
  return {ns, key}
}

mapActions、mapStates 的实现

mapActions 返回的所有办法应该都是对 dispatch 的封装,这样所有办法都走的是 dispatch,这样咱们当前增加中间件就极其不便。

class {
  // ...
  mapActions = map => {let res = {}
    forEachValue(map, (path, fkey) => {let fn = (...args) => {this.dispatch(path, ...args)
      }
      
      res[fkey] = fn
    })
    return res
  }
  mapStates = map => {let res= {}
    
    forEachValue(map, (path, fkey) => {const { ns, key} = normalizePath(path);
      const m = this._module[ns]

      res[fkey] = m.state[key]
    })
    return res
  }
}
function forEachValue (obj, fn) {Object.keys(obj).forEach(key => fn(obj[key], key))
}

棘手实现了 mapStates

到这,你看着清单上的最初一条邪魅一笑,心心念:技术扭转世界,扭转本人,感觉本人就是个人生赢家。

刚刚的平凡创举给予你十足的勇气,你开心的关上微信,纯熟的关上与女神的对话框,小心翼翼的发了一句:在吗?

整顿回顾

女神可能又在忙,你打算测试一下本人的代码:

const actions = mapActions({change: 'app/change'})
const states = mapStates({num: 'app/num'})

change(1)
console.log(states.num) // 0
console.log(store._store._state.app.state.num) // 1

const add = val => actions.change(states.num + 1)
const reudce = val => actions.change(states.mum - 1)

发现代码有问题:

  1. states 并不能响应式的批改
  2. mapActions 太局限;上述 actions 应反对如下优化
const actions = store.mapActions({
  change: 'app/change',
  add (dispatch) {dispatch('app/change', states.val + 1)
  },
  reduce (dispatch) {dispatch('app/change', states.val - 1)
  }
})

将 mapStates 返回的值代理到 module 的 state 上

class Store {
  // ...
  mapStates = map => {let res= {}
    
    forEachValue(map, (path, fkey) => {const { ns, key} = normalizePath(path);
      const m = this._module[ns]

      if (!m) {return}
      
      proxyGetter(res, fkey, m.state, key)
    })
    return res
  }
}
function proxyGetter (target, key, source, sourceKey) {sharedPropertyDefinition.get = function () {return source[sourceKey]
  }
  Object.defineProperty(target, key, sharedPropertyDefinition)
}

批改 mapActions 以反对拓展

class Store {
  // ...
  mapActions = map => {let res = {}
    forEachValue(map, (path, fkey) => {
      let fn
      
      if (typeof path === 'function') {fn = (...args) => {path(this.dispatch, ...args)
        }
      } else {fn = (...args) => {this.dispatch(path, ...args)
        }
      }
      
      res[fkey] = fn
    })
    return res
  }
}

到这里,前端状态管理器性能曾经根本实现,你能够在

去这里 查看她的简略用法和源代码;
查看 undo, redo 的简略示例

她曾经能够满足本人的应用,然而她仍存在限度和有余:

  • dispath 对 setState 的不可预知

例如:

const app = {
  namespace: 'app',
  state: {num: 0},
  actions: {async getNumer () {
      // waiting...
      this.setState({num: 'xxx'})
    }
  }
}

能够看到如果 action 是一个异步的办法,那么咱们就不晓得 setState 什么时候会被调用。

  • 代码中没有错误处理的逻辑
  • module 并不反对多级 module,像 vuex 那样;

不过你能够通过命名空间的形式本人来定义:

const app = {namespace: 'app'}
const app = {namespace: 'app:user'}
const app = {namespace: 'app:system'}

这样还能够使得数据更加扁平化不是么?

  • 在 module 的 action 中调用其余 action
const other = {
  namespace: 'other',
  actions: {foo () {this.dispatch('app/getNumber')
    }
  }
}
退出移动版