કોમ્પોઝિશન (Composition) API FAQ (વારંવાર પુછાતા પ્રશ્નો)
TIP
આ FAQ Vue સાથેના અગાઉના અનુભવને ધારે છે - ખાસ કરીને, મુખ્યત્વે Options API નો ઉપયોગ કરતી વખતે Vue 2 સાથેનો અનુભવ.
Composition API શું છે? (What is Composition API?)
Composition API એ APIs નો એક સેટ છે જે આપણને ઓપ્શન્સ (options) જાહેર કરવાને બદલે ઇમ્પોર્ટ કરેલ ફંક્શન્સનો ઉપયોગ કરીને Vue ઘટકો લખવાની મંજૂરી આપે છે. તે એક છત્ર શબ્દ છે જે નીચેના APIs ને આવરી લે છે:
રિએક્ટિવિટી API (Reactivity API), દા.ત.
ref()અનેreactive(), જે આપણને સીધા રિએક્ટિવ સ્ટેટ, કોમ્પ્યુટેડ સ્ટેટ અને વોચર્સ (watchers) બનાવવાની મંજૂરી આપે છે.લાઇફસાયકલ હૂક્સ (Lifecycle Hooks), દા.ત.
onMounted()અનેonUnmounted(), જે આપણને પ્રોગ્રામેટિક રીતે ઘટકના લાઈફસાયકલ સાથે જોડવા દે છે.ડિપેન્ડન્સી ઇન્જેક્શન (Dependency Injection), એટલે કે
provide()અનેinject(), જે આપણને Reactivity APIs નો ઉપયોગ કરતી વખતે Vue ની ડિપેન્ડન્સી ઇન્જેક્શન સિસ્ટમનો લાભ લેવાની મંજૂરી આપે છે.
Composition API એ Vue 3 અને Vue 2.7 ની બિલ્ટ-ઇન સુવિધા છે. જૂના Vue 2 વર્ઝન માટે, સત્તાવાર રીતે જાળવવામાં આવેલ @vue/composition-api પ્લગિનનો ઉપયોગ કરો. Vue 3 માં, તે મુખ્યત્વે સિંગલ-ફાઇલ કમ્પોનન્ટ્સમાં <script setup> સિન્ટેક્સ સાથે ઉપયોગમાં લેવાય છે. અહીં Composition API નો ઉપયોગ કરતા ઘટકનું મૂળભૂત ઉદાહરણ છે:
vue
<script setup>
import { ref, onMounted } from 'vue'
// રિએક્ટિવ સ્ટેટ (reactive state)
const count = ref(0)
// ફંક્શન્સ જે સ્ટેટ બદલે છે અને અપડેટ્સ ટ્રિગર કરે છે
function increment() {
count.value++
}
// લાઇફસાઇકલ હૂક્સ (lifecycle hooks)
onMounted(() => {
console.log(`પ્રારંભિક કાઉન્ટ ${count.value} છે.`)
})
</script>
<template>
<button @click="increment">કાઉન્ટ છે: {{ count }}</button>
</template>ફંક્શન કમ્પોઝિશન (function composition) પર આધારિત API સ્ટાઇલ હોવા છતાં, Composition API એ ફંક્શનલ પ્રોગ્રામિંગ નથી. Composition API Vue ના મ્યુટેબલ, ફાઇન-ગ્રેઇન્ડ રિએક્ટિવિટી મોડલ પર આધારિત છે, જ્યારે ફંકશનલ પ્રોગ્રામિંગ ઇમ્યુટેબિલિટી (immutability) પર ભાર મૂકે છે.
જો તમને Composition API સાથે Vue નો ઉપયોગ કેવી રીતે કરવો તે શીખવામાં રસ હોય, તો તમે ડાબી સાઇડબારની ટોચ પરના ટૉગલનો ઉપયોગ કરીને સાઇટ-વાઇડ API પ્રેફરન્સ Composition API પર સેટ કરી શકો છો અને પછી શરૂઆતથી માર્ગદર્શિકા વાંચી શકો છો.
Composition API શા માટે? (Why Composition API?)
બહેતર લોજિક રીયુઝ (Better Logic Reuse)
Composition API નો પ્રાથમિક ફાયદો એ છે કે તે Composable functions ના સ્વરૂપમાં સ્વચ્છ, કાર્યક્ષમ લોજિક રીયુઝને સક્ષમ કરે છે. તે મિક્સિન્સ (mixins) ની તમામ ખામીઓ ને હલ કરે છે, જે ઓપ્શન્સ API માટે પ્રાથમિક લોજિક રીયુઝ મિકેનિઝમ (logic reuse mechanism) છે.
Composition API ની લોજિક રીયુઝ ક્ષમતાએ VueUse જેવા અદભૂત સમુદાય પ્રોજેક્ટ્સને જન્મ આપ્યો છે, જે કમ્પોઝેબલ યુટિલિટીઝનો સતત વધતો જતો સંગ્રહ છે. તે સ્ટેટફુલ થર્ડ-પાર્ટી સેવાઓ અથવા લાઇબ્રેરીઓને Vue ની રિએક્ટિવિટી સિસ્ટમમાં સરળતાથી એકીકૃત કરવા માટે સ્વચ્છ મિકેનિઝમ તરીકે પણ કામ કરે છે, ઉદાહરણ તરીકે ઇમ્યુટેબલ ડેટા, સ્ટેટ મશીન્સ, અને RxJS.
વધુ લવચીક કોડ ઓર્ગેનાઈઝેશન (More Flexible Code Organization)
ઘણા વપરાશકર્તાઓ ઓપ્શન્સ API સાથે ડિફોલ્ટ રૂપે વ્યવસ્થિત કોડ લખવાનું પસંદ કરે છે: દરેક વસ્તુ તેના અનુરૂપ વિકલ્પ (option) મુજબ તેની જગ્યાએ હોય છે. જો કે, જ્યારે એક જ ઘટકનું લોજિક ચોક્કસ જટિલતાથી વધી જાય ત્યારે ઓપ્શન્સ API ગંભીર મર્યાદાઓ ઉભી કરે છે. આ મર્યાદા ખાસ કરીને એવા ઘટકોમાં મુખ્યત્વે જોવા મળે છે કે જેમને બહુવિધ લોજિકલ બાબતો (logical concerns) સાથે વ્યવહાર કરવાની જરૂર હોય છે, જેનો અમે પ્રોડક્શન Vue 2 એપ્સમાં જાતે અનુભવ કર્યો છે.
Vue CLI ના GUI ના ફોલ્ડર એક્સપ્લોરર ઘટકને ઉદાહરણ તરીકે લો: આ ઘટક નીચેની લોજિકલ બાબતો માટે જવાબદાર છે:
- વર્તમાન ફોલ્ડર સ્ટેટને ટ્રેક કરવું અને તેનું કન્ટેન્ટ દર્શાવવું
- ફોલ્ડર નેવિગેશન હેન્ડલ કરવું (ઓપનિંગ, ક્લોઝિંગ, રિફ્રેશિંગ...)
- નવું ફોલ્ડર બનાવવાનું હેન્ડલ કરવું
- ફક્ત ફેવરિટ ફોલ્ડર્સ બતાવવાનું ટૉગલ કરવું
- છુપાયેલા (hidden) ફોલ્ડર્સ બતાવવાનું ટૉગલ કરવું
- વર્તમાન વર્કિંગ ડિરેક્ટરી ફેરફારોને હેન્ડલ કરવા
ઘટકનું મૂળ સંસ્કરણ (original version) ઓપ્શન્સ API માં લખવામાં આવ્યું હતું. જો આપણે કોડની દરેક લાઇનને તે જે લોજિકલ બાબત સાથે કામ કરી રહી છે તેના આધારે રંગ આપીએ, તો તે આ રીતે દેખાય છે:

નોંધ કરો કે સમાન તાર્કિક બાબત સાથે કામ કરતો કોડ કેવી રીતે અલગ-અલગ વિકલ્પો (options) હેઠળ વિભાજિત થાય છે, જે ફાઇલના વિવિધ ભાગોમાં સ્થિત છે. સેંકડો લાઇનો લાંબા ઘટકમાં, એક એક તાર્કિક બાબતને સમજવા અને નેવિગેટ કરવા માટે સતત ફાઇલને ઉપર અને નીચે સ્ક્રોલ કરવાની જરૂર પડે છે, જે તેને જોઈએ તે કરતાં ઘણું મુશ્કેલ બનાવે છે. વધારામાં, જો આપણે ક્યારેય રીયુઝબલ યુટિલિટીમાં લોજિકલ બાબત કાઢવાનો ઇરાદો રાખીએ છીએ, તો ફાઇલના વિવિધ ભાગોમાંથી કોડના યોગ્ય ટુકડા શોધવા અને કાઢવા માટે ઘણું કામ લાગે છે.
અહીં તે જ ઘટક છે, Composition API માં રીફેક્ટર (refactor) કર્યા પહેલા અને પછી:

નોંધ કરો કે હવે સમાન તાર્કિક બાબત સાથે સંબંધિત કોડ કેવી રીતે એકસાથે ગ્રુપ કરી શકાય છે: વિશિષ્ટ લોજિકલ બાબત પર કામ કરતી વખતે આપણે હવે વિવિધ ઓપ્શન્સ બ્લોક્સ વચ્ચે કૂદવાની જરૂર નથી. તદુપરાંત, હવે આપણે કોડના જૂથને ન્યૂનતમ પ્રયત્નો સાથે એક્સટર્નલ ફાઇલમાં ખસેડી શકીએ છીએ, કારણ કે હવે આપણે કોડને એક્સટ્રેક્ટ કરવા માટે તેને આમતેમ ફેરવવાની જરૂર નથી. મોટા કોડબેઝમાં લાંબા ગાળાની જાળવણીક્ષમતા માટે રિફેક્ટરિંગ માટેનું આ ઘટતું ઘર્ષણ (friction) ચાવીરૂપ છે.
બહેતર ટાઇપ ઇન્ફરન્સ (Better Type Inference)
તાજેતરના વર્ષોમાં, વધુને વધુ ફ્રન્ટએન્ડ ડેવલપર્સ TypeScript અપનાવી રહ્યા છે કારણ કે તે આપણને વધુ મજબૂત કોડ લખવામાં મદદ કરે છે, વધુ આત્મવિશ્વાસ સાથે ફેરફારો કરવા દે છે અને IDE સપોર્ટ સાથે ઉત્તમ ડેવલપમેન્ટ અનુભવ પ્રદાન કરે છે. જો કે, ઓપ્શન્સ API, જે મૂળ ૨૦૧૩ માં કલ્પના કરવામાં આવ્યું હતું, તે ટાઇપ ઇન્ફરન્સને ધ્યાનમાં લીધા વગર ડિઝાઇન કરવામાં આવ્યું હતું. ઓપ્શન્સ API સાથે ટાઇપ ઇન્ફરન્સ કામ કરવા માટે અમારે કેટલાક અત્યંત જટિલ ટાઇપ જિમ્નેસ્ટિક્સ (gymnastics) લાગુ કરવા પડ્યા હતા. આ બધા પ્રયત્નો છતાં, ઓપ્શન્સ API માટે ટાઇપ ઇન્ફરન્સ હજુ પણ મિક્સિન્સ અને ડિપેન્ડન્સી ઇન્જેક્શન માટે તૂટી શકે છે.
આના કારણે ઘણા ડેવલપર્સ કે જેઓ TS સાથે Vue નો ઉપયોગ કરવા માંગતા હતા તેઓ vue-class-component દ્વારા સંચાલિત Class API તરફ ઝુક્યા હતા. જો કે, ક્લાસ-આધારિત API ભારે રીતે ES ડેકોરેટર્સ (decorators) પર આધાર રાખે છે, જે ભાષાનું ફીચર હતું જે ૨૦૧૯ માં જ્યારે Vue 3 વિકસાવવામાં આવ્યું હતું ત્યારે માત્ર સ્ટેજ ૨ પ્રસ્તાવ હતો. અમને લાગ્યું કે અસ્થિર પ્રસ્તાવ પર ઓફિશિયલ API નો આધાર રાખવો ખૂબ જોખમી છે. ત્યારથી, ડેકોરેટર્સ પ્રસ્તાવ હજુ પણ સંપૂર્ણ સુધારણામાંથી પસાર થયો છે, અને અંતે ૨૦૨૨ માં સ્ટેજ ૩ પર પહોંચ્યો છે. વધારામાં, ક્લાસ-આધારિત API ઓપ્શન્સ API જેવી જ લોજિક રીયુઝ અને ઓર્ગેનાઈઝેશન મર્યાદાઓથી પીડાય છે.
તેની સરખામણીમાં, Composition API મોટે ભાગે સાદા વેરિએબલ્સ અને ફંક્શન્સનો ઉપયોગ કરે છે, જે કુદરતી રીતે ટાઇપ-ફ્રેન્ડલી છે. Composition API માં લખાયેલા કોડમાં મેન્યુઅલ ટાઇપ ટિપ્સ (type hints) ની બહુ ઓછી જરૂરિયાત સાથે સંપૂર્ણ ટાઇપ ઇન્ફરન્સનો આનંદ મળી શકે છે. મોટાભાગનો સમય, Composition API કોડ TypeScript અને સાદા JavaScript માં લગભગ સમાન દેખાશે. આ સાદા JavaScript વપરાશકર્તાઓ માટે આંશિક ટાઇપ ઇન્ફરન્સનો લાભ મેળવવો પણ શક્ય બનાવે છે.
નાનું પ્રોડક્શન બંડલ અને ઓછો ઓવરહેડ (Smaller Production Bundle and Less Overhead)
Composition API અને <script setup> માં લખાયેલ કોડ પણ ઓપ્શન્સ API કરતા વધુ કાર્યક્ષમ અને મિનીફિકેશન-ફ્રેન્ડલી છે. આ એટલા માટે છે કારણ કે <script setup> ઘટકમાં ટેમ્પલેટ એ <script setup> કોડના સમાન સ્કોપમાં ઇનલાઇન ફંક્શન તરીકે કમ્પાઇલ કરવામાં આવે છે. this પરથી પ્રોપર્ટી એક્સેસ કરવાથી વિપરીત, કમ્પાઇલ કરેલ ટેમ્પલેટ કોડ વચ્ચે ઇન્સ્ટન્સ પ્રોક્સી (instance proxy) વગર <script setup> ની અંદર જાહેર કરેલા વેરિએબલ્સને સીધો એક્સેસ કરી શકે છે. આ વધુ સારા મિનીફિકેશન તરફ દોરી જાય છે કારણ કે તમામ વેરિએબલ નામો સુરક્ષિત રીતે ટૂંકા કરી શકાય છે.
ઓપ્શન્સ (Options) API સાથેનો સંબંધ
ટ્રેડ-ઓફ (Trade-offs)
ઓપ્શન્સ API માંથી આવતા કેટલાક વપરાશકર્તાઓને તેમનો Composition API કોડ ઓછો વ્યવસ્થિત મળ્યો અને નિષ્કર્ષ કાઢ્યો કે કોડ ઓર્ગેનાઈઝેશનના કિસ્સામાં Composition API "ખરાબ" છે. અમે આવા અભિપ્રાય ધરાવતા વપરાશકર્તાઓને તે સમસ્યાને અલગ દ્રષ્ટિકોણથી જોવાની ભલામણ કરીએ છીએ.
એ વાત સાચી છે કે Composition API હવે એવા "કંટ્રોલ" પૂરા પાડતું નથી કે જે તમને તમારા કોડને સંબંધિત બકેટ્સમાં મૂકવા માટે માર્ગદર્શન આપે છે. બદલામાં, તમે સામાન્ય JavaScript કેવી રીતે લખો છો તે રીતે ઘટક કોડ લખી શકો છો. આનો અર્થ એ છે કે તમે તમારી Composition API કોડમાં પણ કોઈપણ કોડ ઓર્ગેનાઈઝેશન પ્રેક્ટિસિસ લાગુ કરી શકો છો અને કરવી જોઈએ જે તમે સામાન્ય JavaScript લખતી વખતે કરો છો. જો તમે સારી રીતે વ્યવસ્થિત JavaScript લખી શકો છો, તો તમારે સારી રીતે વ્યવસ્થિત Composition API કોડ પણ લખી શકવો જોઈએ.
ઓપ્શન્સ API જ્યારે ઘટક કોડ લખતી વખતે ખરેખર તમને "ઓછું વિચારવા" દે છે, જેના કારણે ઘણા વપરાશકર્તાઓ તેને પસંદ કરે છે. જોકે, માનસિક ઓવરહેડ ઘટાડવામાં, તે તમને નિર્ધારિત કોડ ઓર્ગેનાઈઝેશન પેટર્નમાં પણ લૉક કરે છે, જે મોટા પાયે પ્રોજેક્ટ્સમાં કોડની ગુણવત્તા સુધારવા અથવા રિફેક્ટર કરવાનું મુશ્કેલ બનાવી શકે છે. આ સંદર્ભમાં, Composition API બહેતર લાંબા ગાળાની સ્કેલાબિલિટી (scalability) પૂરી પાડે છે.
શું Composition API તમામ ઉપયોગના કિસ્સાઓ આવરી લે છે?
હા સ્ટેટફુલ લોજિક (stateful logic) ના કિસ્સામાં. Composition API નો ઉપયોગ કરતી વખતે, હજુ પણ કેટલાક ઓપ્શન્સની જરૂર પડી શકે છે: props, emits, name, અને inheritAttrs.
TIP
Vue ૩.૩ થી તમે કમ્પોનન્ટનું નામ અથવા inheritAttrs પ્રોપર્ટી સેટ કરવા માટે <script setup> માં સીધા જ defineOptions નો ઉપયોગ કરી શકો છો.
જો તમારો ઇરાદો ખાસ કરીને Composition API (ઉપર સૂચિબદ્ધ ઓપ્શન્સ સાથે) વાપરવાનો હોય, તો તમે compile-time flag દ્વારા તમારા પ્રોડક્શન બંડલમાંથી કેટલાક kbs ઘટાડી શકો છો જે Vue માંથી ઓપ્શન્સ API સંબંધિત કોડને કાઢી નાખે છે. નોંધ કરો કે આ તમારી ડિપેન્ડન્સીસમાંના Vue ઘટકોને પણ અસર કરે છે.
શું હું એક જ કમ્પોનન્ટમાં બંને APIs નો ઉપયોગ કરી શકું?
હા, તમે ઓપ્શન્સ API ઘટકમાં setup() ઓપ્શન દ્વારા Composition API નો ઉપયોગ કરી શકો છો.
જોકે, જો તમારી પાસે હયાત ઓપ્શન્સ API કોડબેઝ હોય કે જેને Composition API સાથે લખાયેલ નવી સુવિધાઓ / બાહ્ય લાઇબ્રેરીઓ સાથે એકીકૃત કરવાની જરૂર હોય તો જ અમે આવું કરવાની ભલામણ કરીએ છીએ.
શું ઓપ્શન્સ API ડેપ્રિકેટ (deprecated) થશે?
ના, અમારી પાસે તેમ કરવાની કોઈ યોજના નથી. ઓપ્શન્સ API એ Vue નો અભિન્ન ભાગ છે અને તે ઘણા ડેવલપર્સને જે ગમે છે તેનું કારણ છે. અમે એ પણ સમજીએ છીએ કે Composition API ના ઘણા ફાયદા ફક્ત મોટા પાયે પ્રોજેક્ટ્સમાં જ દેખાય છે, અને ઓપ્શન્સ API ઘણા ઓછી થી મધ્યમ-જટિલતાના દૃશ્યો માટે મજબૂત પસંદગી રહે છે.
ક્લાસ (Class) API સાથેનો સંબંધ
અમે હવે Vue 3 સાથે ક્લાસ API વાપરવાની ભલામણ કરતા નથી, કારણ કે Composition API વધારાના લોજિક રીયુઝ અને કોડ ઓર્ગેનાઈઝેશન ફાયદાઓ સાથે ઉત્તમ TypeScript ઇન્ટિગ્રેશન પૂરું પાડે છે.
રીએક્ટ હૂક્સ (React Hooks) સાથે સરખામણી
Composition API એ રિએક્ટ હૂક્સ (React Hooks) જેવી જ લોજિક કમ્પોઝિશન (logic composition) ક્ષમતાઓ પૂરી પાડે છે, પરંતુ કેટલાક મહત્વપૂર્ણ તફાવતો સાથે.
જ્યારે પણ ઘટક અપડેટ થાય છે ત્યારે રિએક્ટ હૂક્સ વારંવાર ઉપયોગમાં લેવાય છે. આ ઘણી ચેતવણીઓ (caveats) ઉભી કરે છે જે અનુભવી રીએક્ટ ડેવલપર્સને પણ મૂંઝવી શકે છે. તે પર્ફોર્મન્સ ઓપ્ટિમાઇઝેશન સમસ્યાઓ તરફ પણ દોરી જાય છે જે ડેવલપમેન્ટ અનુભવને ગંભીર રીતે અસર કરી શકે છે. અહીં કેટલાક ઉદાહરણો છે:
હૂક્સ કોલ-ઓર્ડર (call-order) સેન્સિટિવ હોય છે અને શરતી (conditional) હોઈ શકતા નથી.
રીએક્ટ ઘટકમાં જાહેર કરાયેલા વેરિએબલ્સ હૂક ક્લોઝર (closure) દ્વારા કેપ્ચર કરી શકાય છે અને જો ડેવલપર યોગ્ય ડિપેન્ડન્સી એરે પસાર કરવામાં નિષ્ફળ જાય તો તે "જૂના (stale)" બની જાય છે. આના કારણે રીએક્ટ ડેવલપર્સ સાચી ડિપેન્ડન્સીસ પસાર થાય છે તે સુનિશ્ચિત કરવા માટે ESLint નિયમો પર આધાર રાખે છે. જો કે, નિયમ અવારનવાર એટલો સ્માર્ટ હોતો નથી અને વધુ પડતું વળતર આપે છે, જે બિનજરૂરી અમાન્યકરણ (invalidation) અને માથાનો દુખાવો તરફ દોરી જાય છે.
ખર્ચાળ ગણતરીઓ માટે
useMemoના ઉપયોગની જરૂર પડે છે, જેને ફરીથી યોગ્ય ડિપેન્ડન્સી એરે મેન્યુઅલી પાસ કરવાની જરૂર પડે છે.ચાઇલ્ડ કમ્પોનન્ટ્સને પાસ કરાયેલ ઇવેન્ટ હેન્ડલર્સ ડિફોલ્ટ રૂપે બિનજરૂરી ચાઇલ્ડ અપડેટ્સનું કારણ બને છે અને ઓપ્ટિમાઇઝેશન તરીકે સ્પષ્ટ
useCallbackની જરૂર પડે છે. આ હંમેશા જરૂરી છે, અને ફરીથી સાચી ડિપેન્ડન્સી એરેની જરૂર પડે છે. આની અવગણના કરવાથી ડિફોલ્ટ રૂપે એપ્સ વધુ પડતા રેન્ડરિંગ તરફ દોરી જાય છે અને સમજ્યા વગર પર્ફોર્મન્સ સમસ્યાઓ પેદા કરી શકે છે.સ્ટેલ ક્લોઝર (stale closure) સમસ્યા, કોન્કરન્ટ (Concurrent) સુવિધાઓ સાથે મળીને, હૂક કોડ ક્યારે ચાલે છે તે વિશે વિચારવું મુશ્કેલ બનાવે છે, અને મ્યુટેબલ સ્ટેટ કે જે રેન્ડર્સ વચ્ચે ટકી રહેવી જોઈએ (
useRefદ્વારા) તેની સાથે કામ કરવું કંટાળાજનક બનાવે છે.
નોંધ: નેમોઇઝેશન (memoization) સંબંધિત ઉપરોક્ત કેટલીક સમસ્યાઓ આગામી રિએક્ટ કમ્પાઇલર (React Compiler) દ્વારા ઉકેલી શકાય છે.
તેની સરખામણીમાં, Vue Composition API:
setup()અથવા<script setup>કોડ માત્ર એક જ વાર ઉપયોગમાં લેવાય છે. આ કોડને સામાન્ય JavaScript વપરાશ સાથે વધુ સારી રીતે સંરેખિત કરે છે કારણ કે અહીં કોઈ સ્ટેલ ક્લોઝરની ચિંતા કરવાની જરૂર નથી. Composition API ના કોલ્સ કોલ ઓર્ડર પ્રત્યે સંવેદનશીલ નથી અને શરતી હોઈ શકે છે.Vue ની રનટાઇમ રિએક્ટિવિટી સિસ્ટમ આપમેળે કોમ્પ્યુટેડ પ્રોપર્ટીઝ અને વોચર્સમાં ઉપયોગમાં લેવાતી રિએક્ટિવ ડિપેન્ડન્સીસ એકત્રિત કરે છે, તેથી જાતે ડિપેન્ડન્સીસ જાહેર કરવાની જરૂર નથી.
બિનજરૂરી ચાઇલ્ડ અપડેટ્સ ટાળવા માટે જાતે કોલબેક ફંક્શન્સ કેશ (cache) કરવાની જરૂર નથી. સામાન્ય રીતે, Vue ની ફાઇન-ગ્રેઇન્ડ રિએક્ટિવિટી સિસ્ટમ એ સુનિશ્ચિત કરે છે કે ચાઇલ્ડ કમ્પોનન્ટ્સ જ્યારે જરૂર હોય ત્યારે જ અપડેટ થાય. Vue ડેવલપર્સ માટે મેન્યુઅલ ચાઇલ્ડ-અપડેટ ઓપ્ટિમાઇઝેશન ભાગ્યે જ ચિંતાનો વિષય હોય છે.
અમે રિએક્ટ હૂક્સની સર્જનાત્મકતાનો સ્વીકાર કરીએ છીએ, અને તે Composition API માટે પ્રેરણાનો મુખ્ય સ્ત્રોત છે. જો કે, ઉપર જણાવેલ મુદ્દાઓ તેની ડિઝાઇનમાં અસ્તિત્વમાં છે અને અમે નોંધ્યું છે કે Vue નું રિએક્ટિવિટી મોડેલ તેની આસપાસ રસ્તો પૂરો પાડે છે.