天天看點
傳回

悟空活動中台 - 微元件狀态管理（上）

本文首發于 vivo網際網路技術 微信公衆号 

連結： https://mp.weixin.qq.com/s/Ka1pjJKuFwuVL8B-t7CwuA

作者：悟空中台研發團隊

一、背景

通過《揭秘 vivo 如何打造千萬級 DAU 活動中台 - 啟航篇》的技術揭秘，相信我們對于 RSC 有了更多的了解。RSC(remote service component) 即遠端服務化元件，通過熱插拔的機制，可視化配置，即插即用，快速建構活動頁面，是活動頁面的核心組成單元。

RSC 是一個高效的對活動頁組成單元的抽象設計方案，最大程度上提升了開發效率，降低了開發者的心智負擔。我們希望開發者在開發中遵循【高内聚，弱耦合】的設計理念，隻需關心 RSC 元件内部的展示和邏輯的處理。

悟空活動中台 - 微元件狀态管理（上）

（圖1）

但在我們實際的業務開發中發現，如上圖1 ，我們每天都要面對大量的相似場景，使用者通過參與【大富翁遊戲】擷取了遊戲的點數，然後【大富翁元件】就需要把遊戲結果點數通知給【集卡元件】，然後【集卡元件】擷取相應卡片，點選【翻卡】，通知【大富翁元件】更新剩餘遊戲次數。在這個活動頁場景中涉及大量的元件之間的協作和資料共享。是以如果把活動看成一個小型的前端系統，RSC 隻是構成系統的一個基本要素，還有一個非常重要的要素不能忽略，那就是 RSC 元件之間的連接配接。當然這種連接配接還和場景上下文相關聯。是以在對 RSC 元件進行治理的過程中，首先需要解決的就是活動頁内元件之間的資料狀态的管理。

二、結果

通過不斷的深入思考問題，探索現象背後的本質原理，從架構設計層面上很好的解決了元件在不同的場景上下文中的連接配接（狀态管理）。例如：

  • 在活動頁内，我們解決了 RSC 元件與元件之間的連接配接。
  • 在平台内，我們解決了 RSC 元件和平台之間的連接配接。業務上 RSC 元件需要感覺到平台的關鍵動作，如活動儲存，編輯器内元件删除等。
  • 在編輯器内的安全沙盒中，我們解決了元件和跨沙盒的配置面闆之間的連接配接。

三、架構演進

今天就重點聊聊，在活動頁内，RSC 元件與元件之間的連接配接。下一篇我們一起聊聊平台和沙箱環境下的 RSC 元件連接配接。

因為我們使用 Vue 作為我們前端的 ui 基礎架構，是以下面技術方案都是基于 Vue 。

四、EventBus 事件總線

悟空活動中台 - 微元件狀态管理（上）

（圖2）

一圖勝千言，如圖 2 。當然我們想到的最簡單的方案，通過實作一個中心化的事件進行中心，來記錄元件内的訂閱者，當需要協同時就通過自定義事件通知到各個相關的元件内部的訂閱者。當然通知中可以攜帶 payload 參數資訊，達到資料共享的目的。其實 Vue 本身也自帶一個自定義事件系統， Vue 元件之間的自定義事件就是基于此來實作，詳細 api 請參與 Vue 文檔。我們可以基于 Vue 本身實作 EventBus 的機制，不需要引入新的依賴，減少 bundle 體積，api使用如下述代碼。

const vm = new Vue()
// 注冊訂閱者
vm.$on('event-name', (payload) => {/*執行業務邏輯*/})
// 注冊訂閱者，執行一次後自動取消訂閱者
vm.$once('some-event-name', (payload) => {/*執行業務邏輯*/})
// 取消某事件的某個訂閱者
vm.$off('event-name'，[callback])
// 通知各個訂閱者執行相對應的業務邏輯
vm.$emit('event-name'，payload)

1、架構上的優點

在實踐中發現基于 EventBus 的資料狀态管理模式的優點：

  • 代碼的實作比較簡單，設計方案容易了解
  • 很輕量的方式就可以完成元件之間的解耦，将元件之間的強耦合變成對 EventBus 的弱耦合。

2、實踐中的痛點

當然EventBus方案的也會有些不足：

  • 因為業務邏輯分散在多個元件訂閱者中，是以導緻業務邏輯的處理變得碎片化，缺乏連貫的上下文。
  • 在閱讀和維護代碼時，需要在代碼中不斷去尋找訂閱者，導緻業務流程了解上的中斷和注意力的分散。

3、反思改進

在認識到 EventBus 的架構設計上的不足時，我們也會 Eating our own dog food，實作了一套可視化的機制，通過對代碼的抽象文法樹的分析，提取訂閱者和發送者的資訊，可視化顯示他們之間的關聯關系，幫助我們快速了解問題。

另外，對于複雜的業務邏輯設計出【前置腳本】的改進方案。例如，活動頁面雖然是由多個RSC元件構成，但是請求的服務端接口還是一個，包含了頁面初始化狀态的所有的資料，此時我們就可以在前置腳本中統一處理擷取資料的邏輯，然後再同步到各個RSC元件内部。【前置腳本】的方式，就是抽取一個全局的對象，包含共享的狀态和業務邏輯。多個元件依賴這個全局的對象，架構設計如圖3，是對 EventBus 方案的一個補充。

悟空活動中台 - 微元件狀态管理（上）

（圖3）

4、總結

通過前置腳本，可以解決複雜業務難以維護了解的問題，但是也帶來一些風險點如需要暴露全局對象，有被覆寫或者被修改的風險。經過前置腳本的改進之後，我們越來越清晰的感受到我們需要的狀态管理模式是什麼樣子，那就是 Vuex 。那接下來我們就聊聊Vuex。

五、Vuex 狀态管理

1、背景

Vuex  是什麼？

Vuex 是一個專為 Vue.js 應用程式開發的狀态管理模式。它采用集中式存儲管理應用的所有元件的狀态，并以相應的規則保證狀态以一種可預測的方式發生變化。Vuex 也內建到 Vue 的官方調試工具 devtools extension，提供了諸如零配置的 time-travel 調試、狀态快照導入導出等進階調試功能。

Vuex 有哪些特點？

  1. 集中式的元件狀态管理，支援動态注冊 store
  2. 與 Vue 的比對度高，底層基于 Vue 的響應式資料特性來實作，保持了和 Vue 一樣的資料處理特點
  3. 熟悉 Vue 後可以快速上手 Vuex ，學習成本比較低
  4. 完善的開發體驗，官方的 devtools 和 time-travel 調試等，幫助開發者梳理資料可預測的變化

2、在平台引入對 Vuex 的支援

Vuex 是一個通用狀态管理架構，怎麼無縫融入到我們的 RSC 元件體系中呢？我們需要在項目中引入對 Vuex 的依賴和支援，在頂層的 Vue 中添加對 store 的依賴。

我們項目的基本結構：

.
└── src
    ├── App.vue
    ├── app.less
    ├── assets
    ├── component
    ├── directive
    ├── main.js
    ├── stat
    ├── store
    └── utils
├── babel.config.js
├── package.json
├── public

2.1 添加依賴

根據規範，首先在我們的項目目錄中的 package.json 中添加對 Vuex 的依賴

{
  "dependencies": {
    "vuex": "^3.0.1"
  }
}

2.2 建立 store 對象 

//store/index.js
import Vue from 'vue'
import Vuex from 'vuex'

Vue.use(Vuex)
export const store = new Vuex.Store({
  // 狀态資料
  state() {
    return {}
  },
  getters: {},
  mutations: {},
  actions: {},
})

2.3 頂層 Vue 對象注入 store

将上述建立 store對象注入到頂層的 Vue 對象中，這樣所有的 Vue 元件就會通過 this.$store 擷取頂層的 store 對象。另外， Vuex 還提供了好用的工具類方法 ( mapState , mapActions , mapGetters , mapMutations ) 來進行資料共享和協同。

// App.vue
import { store } from './store'

new Vue({
  // 注入 store
  // 在所有的改 Vue 管理的 vue 對象中都可以通過 this.$store 來擷取
  store,
})

3、使用 Vuex 開發 RSC 元件

3.1 RSC 自有 store

我們還是希望在開發元件時，開發者大部分時間隻關注自己的展現和業務邏輯，隻是在元件在活動頁中被渲染時，才将自身狀态共享到頂層的 store 中去。是以元件具有自身的獨立 store 狀态管理，通過 namespace 命名空間進行子產品的狀态隔離，然後在元件的 beforeCreate 生命周期方法内，通過 Vuex 的 registerModule 進行動态的 store 的注冊。

3.2 StoreMixin 注入

可以通過抽取公共 StoreMixin 來簡化這一過程，還可以自動開啟 namespaced: true 和針對目前的命名空間擴充快捷方法和屬性。代碼如下：

// store-mixn.js
export default function StoreMixin(ns, store) {
  return beforeCreate() {
    // 保證 namespace 唯一性
    // 開發者可以通過函數生成唯一的namespace
    // 架構可以生成唯一的namespace
    const namespace = isFn(ns) ? ns(this) : gen(ns)
    this.$ns = namespace
    store.namespaced = true
    this.$store.registerModule(namespace, store)

    // 擴充快捷方法和屬性
    this.$state = this.$store.state[namespace]
    this.$dispatch = (action, payload) =>
      this.$store.dispatch(`${namespace}/${action}`, payload)
    this.$getter = //...
    this.$commit = //...
  }
}           
//store.js
// 目前元件自有store
export default {
  // 元件自身的狀态
  state() {
    return {}
  },
  mutations: {},
  getters: {},
  //...other things
}

// code.vue
// 元件對外的入口子產品
import store from './store'
export default {
  mixins: [StoreMixin(/*namespace*/ 'hello', /* 元件的 store */ store)],
}

3.3 命名空間沖突，怎麼解？

因為在一個活動中 RSC 元件會被重複加載多次，所有也會導緻相同 namespace 的 store 子產品重複加載導緻子產品覆寫。怎麼保證 namespace 的唯一性呢？我們可以，在 StoreMixin 中進行 namespace 注冊的時候，判斷有沒有相同的 namespace ，如果有就對 namespace 做一次重命名。比如在已經注冊了 hello 為指令空間的 store 時，再次注冊 namspace hello 自動會變成 hello1 ，自動做區分。簡單的算法實作如下，

// gen.js
// 生成唯一的 namespace
const g = window || global
g.__namespaceCache__ = g.__namespaceCache__ || {}

/**
 * 生成唯一的 moduleName, 同名 name 預設自動增長
 * @param {*} name
 */
export default function genUniqueNamespace(name) {
  let cache = g.__namespaceCache__
  if (cache[name]) {
    cache[name].count += 1
  } else {
    cache[name] = {
      count: 0,
    }
  }
  return name + (cache[name].count === 0 ? '' : cache[name].count)
}

另外，開發者可以通過 store-mixin 中傳遞自定義函數來生成唯一的 namespace 辨別。比如，如下代碼，根據 vue-router 中的路由動态參數來設定 namespace

export default {
  mixins: [StoreMixin((vm) => vm.$router.params.spuId), store],
}

3.4 動态命名空間的挑戰

因為動态 namespace 就會帶來不确定性的問題，如下代碼示例，假如hello被重命名為hello1, 另外在 Vuex 中 mapXXX ( mapState , mapMutations 等）方法時，需要精确傳遞 namespace 才能擷取元件内 store 的上下文。

// code.vue
export default {
  mixins: [StoreMixin('hello', store)],
  computed: {
    ...mapGetters('hello', [
      /* hello namespace store getter */
    ]),
    ...mapState('hello', [
      /* hello namespace state property */
    ]),
  },
  methods: {
    ...mapActions('hello', [
      /* hello namespace actions method */
    ]),
    ...mapMutations('hello', [
      /* hello namespace mutations method */
    ]),
  },
}

3.5 擴充 Vuex 支援動态命名空間

怎麼解決 Vuex mapXXX 方法中動态 namespace 的問題？首先我們我們想到的是在 StoreMixin 中将 namespace 設定在 Vue 的 this.$ns 對象上，這樣被 StoreMixin 混入的元件就就可以動态擷取 namespace 。

// store-mixn.js
export default function StoreMixin(ns, store) {
  return beforeCreate() {
    // 保證 namespace 唯一性
    const namespace = gen(ns)
    // 将重命名後的 namespace 挂載到目前 vue 對象的$ns 屬性上
    this.$ns = namespace
    //...
  }
}

雖然我們可以在元件内通過 this.$ns 擷取元件中的 store 的命名空間，假想着我們可以：

// code.vue
export default {
  computed: {
    ...mapGetter(this.$ns, [
      /* hello namespace store getter */
    ]),
    ...mapState(this.$ns, [
      /* hello namespace state property */
    ]),
  },
  methods: {
    ...mapActions(this.$ns, [
      /* hello namespace actions method */
    ]),
    ...mapMutations(this.$ns, [
      /* hello namespace mutations method */
    ]),
  },
}

很遺憾，在這個時刻 this 根本就不是目前 Vue 的執行個體，this.$ns 華麗麗的 undefined。那怎麼辦呢？JS 有很多函數式程式設計的特點，函數也是值，可以作為參數等進行傳遞，其實函數除了具有值特性外還有一個很重要的特性就是 lazy computed 惰性計算。基于這樣的思考，對 mapXX 方法進行擴充，支援動态的 namespace 。然後在 mapXXX 方法中，等到 vm 是目前 Vue 的元件執行個體時，才去擷取目前的元件的 namespace 。

// code.vue
import { mapGetters, mapState, mapActions, mapMutations } from 'vuex-helper-ext'

export default {
  computed: {
    ...mapGetters((vm) => vm.$ns, [
      /* hello namespace store getter */
    ]),
    ...mapState((vm) => vm.$ns, [
      /* hello namespace state property */
    ]),
  },
  methods: {
    ...mapActions((vm) => vm.$ns, [
      /* hello namespace actions method */
    ]),
    ...mapMutations((vm) => vm.$ns, [
      /* hello namespace mutations method */
    ]),
  },
}

3.6 父子元件如何傳遞動态命名空間

我相信你，肯定發現了其中一個問題，this.$ns 隻能 StoreMixin 的元件内擷取到，那該元件的子元件怎麼辦呢？怎麼解決子元件擷取父元件的 namespace ？這個時候我們就需要借助 Vue 強悍的 mixin 的體系了，設計一個全局 mixin ，在元件建立的時候判斷父元件有沒有 $ns 對象，如果存在就将目前的元件的 $ns 設定為父元件一緻，如果沒有就跳過。

function injectNamespace(Vue) {
  Vue.mixin({
    beforeCreate: function _injectNamespace() {
      const popts = this.$options.parent;
      if (popts && popts.$ns) {
        this.$ns = popts.$ns;
        const namespace = this.$ns;

        // 為元件擴充快捷方法和屬性
        this.$state = this.$store.state[namespace]
        this.$dispatch = (action, payload) =>
                            this.$store.dispatch(`${namespace}/${action}`, payload)
        this.$getter = //...
        this.$commit = //...
      }
    }
  });
}
// main.js
Vue.use(injectNamespace);

這樣子元件就會預設擷取父元件設定的 namespace ，有了這個 mixin 的魔力，我們就可以把 mapXXX 方法的設計的擴充更優雅的一點，因為在 mapXX 方法中可以以 $ns 屬性為預設的 namespace 。更清爽一點，保持和官方一緻的風格， 這樣才把 Vuex 更好的融入我們體系中去。

// code.vue
export default {
  computed: {
    ...mapGetter([
      /* hello namespace store getter */
    ]),
    ...mapState([
      /* hello namespace state property */
    ]),
  },
  methods: {
    ...mapActions([
      /* hello namespace actions method */
    ]),
    ...mapMutations([
      /* hello namespace mutations method */
    ]),
  },
}

3.7 最後一個完整的小栗子

通過下面的小栗子，我們可以看到對于開發者來說，隻要按照标準的 Vuex 的開發方式來開發就可以了，好似什麼都沒有發生過 ^_^。其實在内部我們做了很多的努力，架構設計的目的就是【讓簡單的事情變得更加簡單 , 讓複雜的事情變得可能】。

store.js RSC 元件自有 store

export default {
  state() {
    return { mott: 'hello vue' }
  },
  mutations: {
    changeMott(state) {
      state.mott = 'hello vuex'
    },
  },
}           
<template>
  <div @click="changeMott">{{ mott }}</div>
</template>
<script>
import { mapState, mapMutations } from 'vuex-helper-ext'
export default {
  computed: {
    ...mapState(['mott']),
  },
  methods: {
    ...mapMutations(['changeMott']),
  },
}
</script>           
<tempalte>
  <text></text>
</template>
<script>
import store from './store';
import text from './text';

export default {
  mixins: [StoreMixin('hello', store)],
  components: {
    text
  },
  methods: {
    // ....
  }
}
</script>

六、思考展望

活動中台 自由定制 前端RSC元件 線上內建開發
上一篇: php對接極光推送
下一篇: 通知推送是谷歌眼鏡的命根

繼續閱讀