悟空活動中臺 - 微組件狀態管理（上）

本文首發於 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 有哪些特點？

集中式的組件狀態管理，支持動態註冊 store
與 Vue 的匹配度高，底層基於 Vue 的響應式數據特性來實現，保持了和 Vue 一樣的數據處理特點
熟悉 Vue 後可以快速上手 Vuex ，學習成本比較低
完善的開發體驗，官方的 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'
    },
  },
}

text.vue text 子組件，mapState 自動動態獲取命名空間

<template>
  <div @click="changeMott">{{ mott }}</div>
</template>
<script>
import { mapState, mapMutations } from 'vuex-helper-ext'
export default {
  computed: {
    ...mapState(['mott']),
  },
  methods: {
    ...mapMutations(['changeMott']),
  },
}
</script>

code.vue

<tempalte>
  <text></text>
</template>
<script>
import store from './store';
import text from './text';

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

六、思考展望

本文寫到了這裏，漸進尾聲，感謝相伴。我們一起回顧了RSC組件化方案，在解決悟空活動中臺實際業務場景上走過的路，團隊在技術上爲努力解決 RSC 組件與組件之間狀態管理上的思考。下一篇我們聊聊 RSC 組件與平臺之間，與跨沙盒環境的連接上的狀態管理，歡迎一起交流討論。

悟空活動中臺 - 微組件狀態管理（上）

一、背景

二、結果

三、架構演進

四、EventBus 事件總線

1、架構上的優點

2、實踐中的痛點

3、反思改進

4、總結

五、Vuex 狀態管理

1、背景

2、在平臺引入對 Vuex 的支持

2.1 添加依賴

2.2 創建 store 對象

2.3 頂層 Vue 對象注入 store

3、使用 Vuex 開發 RSC 組件

3.1 RSC 自有 store

3.2 StoreMixin 注入

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

3.4 動態命名空間的挑戰

3.5 擴展 Vuex 支持動態命名空間

3.6 父子組件如何傳遞動態命名空間

3.7 最後一個完整的小栗子

六、思考展望

.Net 8.0 下的新RPC，IceRPC之試試的新玩法"打洞"

完美替代postman的軟件

Vue mockjs mock.js

關於遊戲付費的一點想法

我通過CKA和CKS啦！

安裝chromadb注意事項

《最新出爐》系列入門篇-Python+Playwright自動化測試-42-強大的可視化追蹤利器Trace Viewer

大數據怎麼學？對大數據開發領域及崗位的詳細解讀，完整理解大數據開發領域技術體系

圖解 Promise 實現原理（三）—— Promise 原型方法實現

圖解 Promise 實現原理（二）—— Promise 鏈式調用

悟空活動中臺 - 微組件狀態管理（上）

圖解 Promise 實現原理（一）—— 基礎實現

vivo 大規模特徵存儲實踐

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結