Composition API

github地址 https://github.com/ch-zgh-1993/know-vue3/blob/master/docs/Composition API直譯.md
發布轉載請附原文鏈接 https://www.cnblogs.com/zgh-blog/articles/composition_api.html

這兩天初步了解了下 vue 3.0 相關的一些內容，對于 Composition API 的指導檔案過了一遍 (當然根據經驗，有些重要的地方可能需要在實踐程序中反復思考)，依據自己的理解，對 Composition API 做了一下中文的說明，這里放一下，方便大家在學習的時候能更直接的閱讀和理解，如果有誤或者有更好的理解，歡迎指出評論～

一套新增的， 基于函式的 api 讓組件邏輯更加靈活，

原因，動機

邏輯復用和代碼組織

過去使用 vue 的原因是快速，簡單的構建中小型專案，隨著 vue 使用者的發展，被用來構建大型專案，這會使團隊對專案進行迭代需要耗費更長的時間，過去的時間我們見證了這些專案被 vue 當前的 api 的編程模型所限制，大概有兩類問題：

• 復雜組件在不斷擴展中，變得難以理解，特別在我們讀別人寫的代碼時，根本原因是 現有 API 強制按 options 組織代碼，沒有邏輯關系，實際上，按邏輯關系組織代碼更有意義，
• 缺少一個干凈，無成本的機制，在多個組件之間提取和重用邏輯，

新增 API 的目的是提供更靈活的組件組織代碼方式，現在不使用 options，而是使用 function 組織代碼，使多個組件復用邏輯的提取更直接，甚至是外部的組件，

更好的型別檢查機制

另一個來自大型專案開發者的聲音是對 TS 的支持，當前 的 api 和 TS 整合使用時帶來了一些挑戰，大部分原因是 vue 依賴 this 背景關系來暴露屬性，在組件中 this 使用更多比簡單的 js，(例如： 在方法中我們用 this 指向 組件本身，而不是 methods 物件，) 現有 API 設計時沒有考慮型別推斷，這使得當你使用 TS 造成了大量的復雜性，

大多人在 vue 中使用 TS 用 vue-class-component. 允許組件被命名為 TS class. 在 3.0, 我們提供了 built-in Class API 更好的解決之前的型別問題，在設計方面的討論和迭代中，我們發現 Class API 解決型別問題，依賴裝飾器，這在實作細節中增加了很多不確定的提議，這是一個危險的基礎，

相比較，本 API 大多使用簡單的變數和函式，對型別更友好，新的 API 可以享受完整的型別推斷，使用新的 api 撰寫的代碼在 TS 和 JS 看起來幾乎相同，即使你不用 TS , 也可以獲得更好的 IDE 支持，

詳細設計

API 介紹

新的 API 沒有新的概念，而是將 VUE 的核心功能暴露為獨立的函式，比如 創建狀態回應機制，這里將介紹一些最基本的 API，如何用這些 API 代替 2.x 選項來表示組件邏輯，這里介紹幾本思想，不是所有的 API.

狀態回應和一些作用

宣告回應狀態: reactive 等同于 2.x 的 Vue.observable(), 重命名避免和 RxJS observates 混淆， 監測資料變化： watchEffect 類似于 effect, 不需要分離監控資料源， Composition API 提供 watch function 類似于 2.x.

我們之前回傳的 data ,內部使用 reactive 創建回應狀態，模版編譯在一個渲染函式 watchEffect，使用了這些回應狀態，

我們不需要關注 innerHTML 或者 eventListeners. 我們用 假定的API renderTemplate 使我們把關注放在回應方面，

import {reactive, watchEffect} from 'vue'

// 宣告回應狀態
const state = reactive({
    count: 0
})

function increment() {
    state.count++
}

const renderContext = {
    state,
    increment
}

// 監聽回應狀態的改變
watchEffect(() => {
    // hypothetical internal code, NOT actual API
    renderTemplate(
        `<button @click="increment">{{ state.count }}</button>`,
        renderContext
    )
})

computed: 一個狀態依賴另一個狀態， 那么 computed 是如何實作的呢？如果直接監控原始資料型別，或者物件屬性的值，直接監測時不起作用的，那么很自然的，我們會把他包裝為一個物件，使用物件替代，此外，我們還需要攔截物件的屬性讀寫操作，便于我們執行跟蹤和執行資料渲染變更，現在我們使用參考型別，不用擔心丟失回應性， 類似于 dobule 我們稱為 ref，是對內部的參考， 你已經意識到之前內部屬性 refs 參考 dom element/component, 現在還可以包括 邏輯狀態，

除了 computed ， 我們還可以直接創建 ref

import { reactive, computed, watchEffect, ref } from 'vue'

const state = reactive({
    count: 0
})

const double = computed(() => state.count * 2)

watchEffect(() => {
    console.log(double.value)
})

state.count++ // -> 2

// 內部簡單代碼
function computed (getter) {
    const ref = {
        value: null
    }
    watchEffect(() => {
        ref.value = https://www.cnblogs.com/zgh-blog/p/getter()
    })
    return ref
}

const cc = ref(0)
console.log(cc.value) // 0

ref 內部: 在渲染背景關系暴露 ref 屬性， 在內部， vue 對 ref 進行特殊處理，在遇到渲染背景關系時，直接公開 ref 的內部值，也就是在 template 中，直接使用 count 而不是 count.value.

此外，ref 在作為屬性在一個回應物件中，也會自動展開，

import { ref, watch, reactive, computed } from 'vue'

const state = reactive({
    count: 0,
    dobule: computed(() => state.count * 2)
})
console.log(state.dobule) // 不是 state.dobule.value

const count = ref(0)

function increment() {
    count.value++
}

const renderContext = {
    count,
    increment
}

watchEffect(() => {
    renderTemplate(
        `<button @click="increment">{{ count }}</button>`,
        renderContext
    )
})

components 重用: 如果想要重用邏輯，下一步是將其重構為一個函式，

生命周期鉤子: 除了這些，我們還需列印，發送 ajax, 增加事件在 window.這些在一下的時間完成：

• 當狀態改變時， watch, watchEffect.
• 當組件 mounted, updated, unmounted. （on XXXAPI)

lifecycle methods 將總是在 setup 鉤子中呼叫，將自動計算出呼叫 setup 鉤子的當前實體，這個設計使得將邏輯提取到外部函式時，減少分歧，

代碼組織

現在我們已經通過匯入的函式復制了組件 API, 那用選項定義似乎比函式中混合更有條理? 回到動機，我們試著去理解其中的原因，

什么是代碼組織

組織代碼的目標是使我們更容易的閱讀和理解代碼，我們知道他的選項就理解了嗎？你是否遇到過別人寫的大型組件，你很困難去清晰的理解？

我們向別人描述這個組件，會說 這個組件處理什么事， A，B，C. 而不會說這個組件包含 這些 data, computed, methods. options 在告訴組件做了什么上，處理的不好，

邏輯問題 vs options

我們更多的時候定義組件使用邏輯問題，可讀性問題通常不在小型，單一功能的組件中，在大型的組件中問題更加突出，比如 Vue CLI UI file explorer 處理更多不同的邏輯問題:

• 跟蹤當前檔案狀態，顯示內容
• 處理檔案狀態，打開，關閉，重繪
• 創建新的檔案
• 彈出最喜歡的檔案
• 顯示隱藏的檔案
• 當前作業檔案夾改變

你去查看時很難識別這些邏輯問題部分通過選項， 這些邏輯問題通常是零散并且散落在各處，比如創建新的檔案用到了兩個 properties, 一個 computed prop, 一個 method. 這些距離相差甚遠，這使得復雜的組件維護和理解變得更加困難， 通過選項強制分割掩蓋了邏輯問題，當我們關注一個邏輯時，不得不在 options 中來回跳轉，確實是，

如果我們能把同一個邏輯問題的代碼收集在一塊就好了，這剛好就是我們的 Composition API 做的，創建新的檔案可以被重寫: 將邏輯收集到一個 function 中，他的命名有些自檔案化，我們稱它是 composition function, 建議在函式名開頭使用 use 表明它是一個結構函式，

每個邏輯問題都收集在一起，減少了我們來回跳，在一個大的組件中， Composition functions 在編輯器中折疊，更容易被掃描查找，

function useCreateFolder (openFolder) {
    // originally data properties
    const showNewFolder = ref(false)
    const newFolderName = ref('')

    // originally computed property
    const newFolderValid = computed(() => isValidMultiName(newFolderName.value))

    // originally a method
    async function createFolder () {
        if (!newFolderValid.value) return
        const result = await mutate({
            mutation: FOLDER_CREATE,
            variables: {
                name: newFolderName.value
            }
        })
        openFolder(result.data.folderCreate.path)
        newFolderName.valuehttps://www.cnblogs.com/zgh-blog/p/= ''
        showNewFolder.value = https://www.cnblogs.com/zgh-blog/p/false
    }

    return {
        showNewFolder,
        newFolderName,
        newFolderValid,
        createFolder
    }
}

setup 作為呼叫所有函式的入口，
setup 函式 讀起來像是對組件做的內容的口頭描述，這是基于 options 版本無法做到的，還可以根據引數看到 Composition function 之間的依賴關系流， return回傳的內容可以用來檢查 template 中使用的內容，

給定相同的功能， options 和 composition function 定義的組件表達了相同底層邏輯的兩種不同方式， 一個基于 option type, 一個基于 logic concerns.

export default {
    setup () {
        // Network
        const { networkState } = useNetworkState()

        // Folder
        const { folders, currentFolderData } = useCurrentFolderData(networkState)
        const folderNavigation = useFolderNavigation({ networkState, currentFolderData })
        const { favoriteFolders, toggleFavorite } = useFavoriteFolders(currentFolderData)
        const { showHiddenFolders } = useHiddenFolders()
        const createFolder = useCreateFolder(folderNavigation.openFolder)

        // Current working directory
        resetCwdOnLeave()
        const { updateOnCwdChanged } = useCwdUtils()

        // Utils
        const { slicePath } = usePathUtils()

        return {
              networkState,
              folders,
              currentFolderData,
              folderNavigation,
              favoriteFolders,
              toggleFavorite,
              showHiddenFolders,
              createFolder,
              updateOnCwdChanged,
              slicePath
        }
    }
}
function useCurrentFolderData(networkState) { // ...
}

function useFolderNavigation({ networkState, currentFolderData }) { // ...
}

function useFavoriteFolder(currentFolderData) { // ...
}

function useHiddenFolders() { // ...
}

function useCreateFolder(openFolder) { // ...
}

邏輯提取和重用

Composition API 在提取和重用邏輯時，更加的靈活，比起依賴 magical this context ， composition function 依賴引數和 vue 全域 api. 你能用組件的任何一部分通過匯入 function. 甚至可以匯出擴展 setup 來實作同樣的組件，

類似邏輯重用，我們可以通過現有的 mixin, 高階組件(higher-order components)， renderless components 無渲染組件(作用域插槽)， 這些和 composition function 相比，都有缺點:

• context prop 來源不明確，比如使用多個 mixin, 那么很難判斷一個屬性從哪注入，
• 命名沖突， 混入可能在屬性和方法名上發生沖突，高階組件可能在屬性名發生沖突，
• 性能， 高階組件和無渲染組件需要額外的 狀態組件實體，這就浪費性能，

相比較之下，使用 composition api:

• 公開到模版的屬性有明確的來源， returns，
• composition function 回傳的值可以任意命名，因此不存在命名沖突，
• 不需要創建額外的組件實體，

// example
import { ref, onMounted, onUnmounted } from 'vue'

export function useMousePosition() {
    const x = ref(0)
    const y = ref(0)

    function update(e) {
        x.value = https://www.cnblogs.com/zgh-blog/p/e.pageX
        y.value = e.pageY
    }

    onMounted(() => {
        window.addEventListener('mousemove', update)
    })

    onUnmounted(() => {
        window.removeEventListener('mousemove', update)
    })

    return { x, y }
}


//  在組件中使用
import { useMousePosition } from './mouse'

export default {
    setup() {
        const { x, y } = useMousePosition()
        // other logic...
        return { x, y }
    }
}

和現有 API 一起使用

Composition API 可以和 options-based API 一起使用，

• composition api 在 2.x options(data, computed, methods) 之前決議，并且不能訪問 options 定義的屬性，
• setup 回傳的 prop 將被掛在 this 上，在 2.x options 中時可用的，

插件開發

一些插件今天注入屬性在 this, 例如 Vue Router this.$route/this.$router Vuex this.$store. 這使得型別推斷變得困難，因為每個插件都需要用戶為注入的屬性增加 vue 型別，在使用 composition api 時， 沒有 this, 插件將相應的 provide/inject 暴露在 composition function.

在任何組件中，通過 inject 使用 app provide 的任何依賴，

const StoreSymbol = Symbol()
export function provideStore(store) {
    provide(StoreSymbol, store)
}

export function useStore() {
    const store = inject(StoreSymbol)
    if(!store) {
        throw new Error('no store provide')
    }
    return store
}


// 使用

// 根組件中提供 store
const App = {
    setup () {
        provideStore(store)
    }
}

// 這里使用 store
const Child = {
    setup () {
        const store = useStore()
    }
}

缺點

引入 refs 的開銷

從技術上來說， ref 是 composition api 引入的唯一的新概念， 引入 ref 是為了將 回應值作為變數傳遞，不必依賴 this.這里的缺點是:

• 我們需要始終區分 refs 來自簡單值和物件，增加了我們要考慮的事情，
  • 使用命名約定可以大大減少我們的負擔（比如所有的 ref 變數命名為 xxxRef），或者通過型別系統，另一方面，由于提高代碼組織的靈活性，組件邏輯通常會被分割成一些小的函式，在這些函式中，背景關系比較簡單， ref 的開銷也容易管理，
• 現在由于需要使用 .value, 使用 refs 變得更加繁瑣，冗長，
  • 有人建議使用編譯時提供語法糖去解決這個問題，就像 Svelte 3， 雖然在技術上可行，但我們認為作為 vue 的默認值，這是沒有意義的，就是說，通過 Babel 插件在用戶方面，技術上是可行的，

我們已經討論了，是不是可以避開使用 ref 概念，只使用 回應物件，然而：

• 計算屬性可以返原始型別，因此使用物件，類似于 ref 的容器是不能避免的，
• composition function 期望回傳原始型別總是需要被包裝在 object 中為了回應的目的，如果沒有框架提供標準的實作，用戶很可能最侄訓發明自己的 (ref-like) 模式(導致生態系統崩潰).

ref vs reactive

正常滴，用戶可能會對使用 ref 和 reactive 之間的使用感到困惑，首先，你要理解這兩個內容，去更高效的使用 composition api. 只使用一個將很可能導致難以理解的代碼，或者重復造輪子，

使用 ref 和 reactive 之間的一些區別可以與如何寫標準的 js 邏輯進行比較，

• 如果使用 ref, 我們在很大程度上，使用 refs 將樣式 1 轉換為更加詳細，繁瑣的等效的值(為了使原始型別具有回應性)
• 使用 reactive 更接近樣式 2， 我們僅需要使用 reactive 創建物件，

然而，當僅使用 reactive 問題是 composition function 必須保持回傳物件的參考 為了保持回應性，這個物件不能進行解構和擴展，

提供 toRefs API 用來處理約束 - 它將把每一個屬性在可回應物件上轉換成一個對應的 ref.

總結： 有兩種可行的方式：

• 使用 ref 和 reactive 就像在 js 中宣告原始資料型別和物件變數一樣，推薦使用支持型別的 IDE 系統，
• 盡可能的使用 reactive, 在 composition function 回傳 回應物件時使用 toRefs. 這會減少使用 refs 的心理負擔，但并不能消除這個概念的必要性，

在這個階段，我們認為想要一個最佳實踐關于 ref 和 reactive 之間言之尚早，我們建議從上面的兩個選項中選取更符合你的心理模型的一種，我們將收集用戶的真實反饋，在對這一話題提供更加明確的指導，

// style 1:  分離變數 
let x = 0
let y = 0
function updatePosition(e) {
    x = e.pageX
    y = e.pageY
}

// --- compared to ---

// style2: 單一物件
const pos = {
    x: 0,
    y: 0
}

function updatePosition(e) {
    pos.x = e.pageX
    pos.y = e.pageY
}

// composition function 
function useMousePosition () {
    consst pos = reactive({
        x: 0,
        y: 0
    })
    return pos
}

// consuming component
export default {
    setup () {
        // 丟失回應性
        const {x, y} = useMousePosition()
        return {
            x,
            y
        }
        // 丟失回應性
        return {
            ...useMousePosition()
        }

        // 這是唯一保持回應性的方式，回傳 pos，在 template 中使用 pos.x, pos.y
        return {
            pos: useMousePosition()
        }
    }
}

// ToRefs API
function useMousePosition() {
    const pos = reactive({
        x: 0,
        y: 0
    })

    return toRefs(pos)
}

// x & y are now refs!
const {x, y} = useMousePosition()

回傳陳述句的復雜，冗長程度

一些用戶已經注意到 setup 的回傳陳述句將稱為冗長的就像范例一樣，我們認為簡潔的 return 陳述句 將有利于維護，他讓我們能明確控制暴露在 template 中的內容，并跟蹤組件中定義的模版屬性時充當起點，

有人建議自動暴露 setup 中宣告的變數，使 return 陳述句可選，但我們不認為這應該被默認，因為違背了 js 的直觀，這有一些方法可以讓他不那么麻煩:

• 使用 IDE 擴展，根據 setup 中宣告的變數自動生成回傳陳述句，
• 隱式生成并插入回傳陳述句的 babel plugin.

更靈活的 需要 更多紀律性，要求

許多用戶指出，雖然 composition api 提供了更多的靈活性，但他也需要開發人員更多的遵守，如何正確的做，一些人擔心會導致缺乏經驗的人使用意大利面代碼，換句話說，當 composition api 提供代碼質量的同時，也降低了下限，

我們在一定程度上同意，但是，我們也相信:

• 上界的收益遠遠大于下界的損失，
• 通過恰當的檔案和社區指導，我們能有效的解決代碼組織問題，

一些用戶使用 angular1 controller 作為怎么設計會導致不良的代碼的實體，composition api 和 angular1 controller 之間最大的區別是不依賴共享作用域背景關系，這使得幾那個邏輯分解為單獨的函式非常容易，這也是 js 組織代碼的核心機制，

任何 js 專案開始于一個入口檔案 (就好像一個專案的 program), 我們組織專案通過基于邏輯問題，分離函式/模塊， composition api 使我們可以做類似的處理在 vue component code. 換句話說，撰寫組織良好的 js 代碼能直接轉換為使用 composition api 撰寫組織良好的 vue 代碼的技能，

選用策略

composition api 是純粹的添加，不影響/不支持 任何現有的 2.x api. 已經通過 @vue/composition 庫作為 2.x 的插件提供， 這個庫的主要目標是提供一種方式來測驗 api 和收集用戶的反饋， 當前實作和建議是最新的，但由于差勁啊技術的限制，可能包含一些細微的不一致，可能會接受一些改變就像這個建議更新一樣，因此我們不建議在現階段生產中使用，

我們打算在 3.0 內置此 API. 將和 2.x 的 options 一起存在，

對于在 app 中只使用 composition api， 可以提供編譯時的選項去洗掉 2.x 的 options 以減少庫的大小，當然，這完全可選，

本 api 將被定義為一個高級特性，因為他要解決的問題出現在大規模的應用程式中，我們不打算修改檔案將它用作默認值，相反，他在檔案中將有自己的專用部分，

附錄

class api 的型別問題

引入 class api 的主要目標是提供可選的 api 處理更好的 TS 推斷支持，然而， vue 組件需要從多個源宣告的屬性合并到單一的 this 背景關系中，即使使用基于 class 的 api, 也存在一些挑戰，

一個例子是屬性型別， 為了合并屬性到 this，我們需要泛型引數到組件的 class, 或者使用 decorator.

使用泛型引數: 由于傳遞泛型引數的介面是 in type-land only, 用戶仍然需要提供一個 runtime 屬性宣告為 this 上的屬性代理， 這兩次宣告是多余的，尷尬的，

裝飾器 decorators: 使用裝飾器會產生對 stage-2 的依賴，這種依賴有很多的不確定性，特別是當 TS 當前的實作和 TC39 協議完全不同步時，此外，沒有方法使用裝飾器在 this.$props 公開宣告屬性的型別， 這會 破壞 TSX 的支持，用戶還可能設定默認值，比如 @prop message: string = 'foo'， 但技術上無法按照預期作業，

此外，目前沒有方法利用背景關系型別來處理 class 方法的引數，這意味著傳遞給類的 render 函式的引數，不能基于類的其他屬性做型別推斷，

// 泛型引數
interface Props {
    message: string
}

class App extends Component<Props> {
    static props = {
        message: string
    }
}


// decoratore
class App extends Component<Props> {
    @prop message: string
}

和 react hooks 比較

基于函式的 api 提供了相同級別的邏輯組合功能類似于 react hooks，但是有一些重要的不同點，不像 react hooks, setup 函式僅僅被呼叫一次，這意味著代碼使用 composition api：

• 一般來說，更符合 js 代碼的表達方式，
• 對于呼叫順序不敏感，可以是有條件的，
• 不會重復呼叫在每次渲染時，減少垃圾處理的壓力，
• 不被影響： 為了防止行內處理程式導致子組件的過度重新渲染問題，幾乎總是需要使用 useCallback.
• 不受影響： 如果用戶忘記傳遞正確的依賴陣列，那么 useEffect 和 useMemo 或許會捕獲過時的變數， vue 的自動依賴跟蹤確保 watchers 和 computed 值將總是正確的，

我們承認 React Hooks 的創造性，他是這個提議的主要靈感來源，然而，上面提到的這些問題確實存在于他的設計中， Vue 的回應模型提供了一種解決這些問題的方法，

和 Svelte 比較

盡管走的路線不同，但是 composition api 和 svelte3 的 compiler-based 方法實際上有大量的共同點，下面是一個例子:

Svelte 代碼看起來更加的簡潔，因為他在編譯時做了一下內容：

• 隱式的將 script block (除了 import 陳述句) 包裝到函式中，這個函式被每個組件實體呼叫，而不是只執行一次，
• 隱式注冊回應屬性在變數改變時
• 隱式向渲染背景關系暴露作用域變數，
• 將 $ 陳述句編譯為重新執行的代碼，

技術上來說，這些我們也可以在 vue 中做(通過 babel plugin 實作),我們沒有做的主要原因是和標準的 js 對齊，如果從 vue file 提取 script block 的代碼，我們希望他的作業方式和標準的 ES 模塊相同，另一方面，在 svelte script block 中，技術上不再是標準的 js， 這種基于編譯的方法有很多問題:

• 代碼在 編譯/沒有編譯時 的作業方式不同， 作為一個漸進式框架，許多 vue 用戶可能 希望/需要/必須 在沒有構建設定的情況下使用它， 所以編譯版本不能被默認， 另一方面，Svelte 是一個編譯器，這是兩個框架的本質區別，
• 代碼在 內部/外部 組件作業方式不同， 當從 Svelte 組件中提取邏輯到標準的 js 檔案中，我們將丟失 magical 簡潔的語法，必須后退到一個更詳細的低級 api，
• Svelte 的回應編譯僅僅作業在頂級變數，不包括函式內的變數宣告，因此我們不能在組件內部宣告的函式中封裝回應狀態，這就給函式的代碼組織設定了約束，正如我們在 RFC 中演示的，這對于保持大型組件的可維護性非常重要，
• 不標準的語意使得和 TS 集成存在問題，

這里沒有任何說 Svelte3 不好，事實上他是一個非常創新的方法，我們高度尊重 Rich 的作業，但是基于 vue 的設計約束和目標，我們必須做出對應的權衡，

// vue
<script>
import {ref, watchEffect, onMounted} from 'vue'

export default {
    setup () {
        const count = ref(0)

        function increment() {
            count.value++
        }

        watchEffect(() => console.log(count.value))
        onMounted(() => console.log('mounted'))

        return {
            count,
            increment
        }
    }
}
</script>


// svelte
<script type="text/javascript">
import {onMount} from 'svelte'

let count = 0
function increment() {
    count++
}

$: console.log(count)

onMount(() => console.log('mounted'))
</script>

標籤：其他

上一篇：翻譯官方檔案或文章小姿勢

下一篇：8款最好的WooCommerce虛擬主機