Options API 和 Composition API?

Options API 約定：

我們需要在 props 里面設(shè)置接收參數(shù)

我們需要在 data 里面設(shè)置變量

我們需要在 computed 里面設(shè)置計(jì)算屬性

我們需要在 watch 里面設(shè)置監(jiān)聽屬性

我們需要在 methods 里面設(shè)置事件方法

你會(huì)發(fā)現(xiàn) Options APi 都約定了我們該在哪個(gè)位置做什么事，這反倒在一定程度上也強(qiáng)制我們進(jìn)行了代碼分割。

現(xiàn)在用 Composition API，不再這么約定了，于是乎，代碼組織非常靈活，我們的控制代碼寫在 setup 里面即可。

setup函數(shù)提供了兩個(gè)參數(shù) props和context,重要的是在setup函數(shù)里沒有了this,在?vue3.0?中，訪問他們變成以下形式： this.xxx=》context.xxx

我們沒有了 this 上下文，沒有了 Options API 的強(qiáng)制代碼分離。Composition API 給了我們更加廣闊的天地，那么我們更加需要慎重自約起來。

對于復(fù)雜的邏輯代碼，我們要更加重視起 Composition API 的初心，不要吝嗇使用 Composition API 來分離代碼，用來切割成各種模塊導(dǎo)出。

我們期望是這樣的：

importuseAfrom'./a';

importuseBfrom'./b';

importuseCfrom'./c';

exportdefault{

setup?(props)?{

let{?a,?methodsA?}?=?useA();

let{?b,?methodsB?}?=?useA();

let{?c,?methodsC?}?=?useC();

return{

a,

methodsA,

b,

methodsB,

c,

methodsC

}

}

}

就算 setup 內(nèi)容代碼量越來越大，但是始終圍繞著大而不亂，代碼結(jié)構(gòu)清晰的路子前進(jìn)。