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 = 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.value = ''
showNewFolder.value = 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 = 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>