પર્ફોર્મન્સ (Performance) ​

વિહંગાવલોકન (Overview) ​

Vue ને મેન્યુઅલ ઓપ્ટિમાઇઝેશનની બહુ જરૂર વગર મોટાભાગના સામાન્ય ઉપયોગના કિસ્સાઓ માટે પર્ફોર્મન્ટ (performant) બનાવવા માટે ડિઝાઇન કરવામાં આવ્યું છે. જો કે, ત્યાં હંમેશા પડકારરૂપ દૃશ્યો હોય છે જ્યાં વધારાના ફાઇન-ટ્યુનિંગની જરૂર હોય છે. આ વિભાગમાં, અમે ચર્ચા કરીશું કે જ્યારે Vue એપ્લિકેશનમાં પર્ફોર્મન્સની વાત આવે ત્યારે તમારે શેના પર ધ્યાન આપવું જોઈએ.

સૌ પ્રથમ, વેબ પર્ફોર્મન્સના બે મુખ્ય પાસાઓ વિશે ચર્ચા કરીએ:

• પેજ લોડ પર્ફોર્મન્સ (Page Load Performance): પ્રારંભિક મુલાકાત પર એપ્લિકેશન કેટલી ઝડપથી સામગ્રી બતાવે છે અને ઇન્ટરેક્ટિવ બને છે. આ સામાન્ય રીતે વેબ વાઇટલ મેટ્રિક્સ જેમ કે Largest Contentful Paint (LCP) અને Interaction to Next Paint નો ઉપયોગ કરીને માપવામાં આવે છે.

• અપડેટ પર્ફોર્મન્સ (Update Performance): વપરાશકર્તાના ઇનપુટના પ્રતિસાદમાં એપ્લિકેશન કેટલી ઝડપથી અપડેટ થાય છે. ઉદાહરણ તરીકે, જ્યારે વપરાશકર્તા સર્ચ બોક્સમાં ટાઇપ કરે છે ત્યારે લિસ્ટ કેટલી ઝડપથી અપડેટ થાય છે, અથવા જ્યારે વપરાશકર્તા સિંગલ-પેજ એપ્લિકેશન (SPA) માં નેવિગેશન લિંક પર ક્લિક કરે છે ત્યારે પેજ કેટલી ઝડપથી સ્વિચ થાય છે.

જ્યારે બંનેને મહત્તમ બનાવવું આદર્શ હશે, ત્યારે વિવિધ ફ્રન્ટએન્ડ આર્કિટેક્ચર આ પાસાઓમાં ઇચ્છિત પ્રદર્શન પ્રાપ્ત કરવામાં કેટલી સરળતા છે તેની અસર કરે છે. વધારામાં, તમે જે પ્રકારની એપ્લિકેશન બનાવી રહ્યા છો તે પર્ફોર્મન્સના સંદર્ભમાં તમારે શું પ્રાથમિકતા આપવી જોઈએ તેના પર ખૂબ પ્રભાવ પાડે છે. તેથી, શ્રેષ્ઠ પ્રદર્શન સુનિશ્ચિત કરવા માટેનું પ્રથમ પગલું એ છે કે તમે જે પ્રકારની એપ્લિકેશન બનાવી રહ્યા છો તેના માટે યોગ્ય આર્કિટેક્ચર પસંદ કરો:

• તમે વિવિધ રીતે Vue નો લાભ કેવી રીતે લઈ શકો તે જોવા માટે Vue નો ઉપયોગ કરવાની રીતો (Ways of Using Vue) નો સંપર્ક કરો.

• જેસન મિલર એપ્લિકેશન હોલોટાઇપ્સ (Application Holotypes) માં વેબ એપ્લિકેશનના પ્રકારો અને તેમના સંબંધિત આદર્શ અમલીકરણ / વિતરણ વિશે ચર્ચા કરે છે.

પ્રોફાઇલિંગ વિકલ્પો (Profiling Options) ​

પ્રદર્શન સુધારવા માટે, આપણે તેને કેવી રીતે માપવું તે પહેલા જાણવાની જરૂર છે. અસંખ્ય શ્રેષ્ઠ સાધનો છે જે આ બાબતમાં મદદ કરી શકે છે:

પ્રોડક્શન ડિપ્લોયમેન્ટના લોડ પર્ફોર્મન્સને પ્રોફાઇલ કરવા માટે:

• PageSpeed Insights
• WebPageTest

સ્થાનિક ડેવલપમેન્ટ દરમિયાન પર્ફોર્મન્સ પ્રોફાઇલ કરવા માટે:

• Chrome DevTools Performance Panel
  • app.config.performance Chrome DevTools ની પર્ફોર્મન્સ ટાઇમલાઇનમાં Vue-વિશિષ્ટ પર્ફોર્મન્સ માર્કર્સને સક્ષમ કરે છે.
• Vue DevTools Extension પણ પર્ફોર્મન્સ પ્રોફાઇલિંગ સુવિધા પૂરી પાડે છે.

પેજ લોડ ઓપ્ટિમાઇઝેશન (Page Load Optimizations) ​

પેજ લોડ પર્ફોર્મન્સને શ્રેષ્ઠ બનાવવા માટે ઘણા ફ્રેમવર્ક-અજ્ઞેયવાદી પાસાઓ છે - વ્યાપક રાઉન્ડઅપ માટે આ web.dev માર્ગદર્શિકા તપાસો. અહીં આપણે મુખ્યત્વે Vue માટે વિશિષ્ટ તકનીકો પર ધ્યાન કેન્દ્રિત કરીશું.

સાચું આર્કિટેક્ચર પસંદ કરવું (Choosing the Right Architecture) ​

જો તમારો ઉપયોગ પેજ લોડ પર્ફોર્મન્સ પ્રત્યે સંવેદનશીલ છે, તો તેને શુદ્ધ ક્લાયન્ટ-સાઇડ SPA તરીકે મોકલવાનું ટાળો. તમે ઈચ્છશો કે તમારું સર્વર સીધું જ HTML મોકલે જેમાં વપરાશકર્તાઓ જે સામગ્રી જોવા માંગે છે તે હોય. શુદ્ધ ક્લાયન્ટ-સાઇડ રેન્ડરિંગ ધીમા ટાઇમ-ટુ-કન્ટેન્ટથી પીડાય છે. આને Server-Side Rendering (SSR) અથવા Static Site Generation (SSG) સાથે ઘટાડી શકાય છે. Vue સાથે SSR કરવા વિશે જાણવા માટે SSR ગાઇડ તપાસો. જો તમારી એપમાં સમૃદ્ધ ઇન્ટરેક્ટિવિટી આવશ્યકતાઓ નથી, તો તમે HTML રેન્ડર કરવા માટે પરંપરાગત બેકએન્ડ સર્વરનો ઉપયોગ કરી શકો છો અને ક્લાયન્ટ પર Vue સાથે તેને એન્હાન્સ કરી શકો છો.

જો તમારી મુખ્ય એપ્લિકેશન SPA હોવી જ જોઈએ, પરંતુ તેમાં માર્કેટિંગ પેજીસ (લેન્ડિંગ, અબાઉટ, બ્લોગ) છે, તો તેમને અલગથી મોકલો! તમારા માર્કેટિંગ પેજીસ આદર્શ રીતે SSG નો ઉપયોગ કરીને ન્યૂનતમ JS સાથે સ્ટેટિક HTML તરીકે ડિપ્લોય કરવા જોઈએ.

બંડલ સાઈઝ અને ટ્રી-શેકિંગ (Bundle Size and Tree-shaking) ​

પેજ લોડ પર્ફોર્મન્સ સુધારવા માટેની સૌથી અસરકારક રીતોમાંની એક નાના JavaScript બંડલ્સ મોકલવા છે. Vue નો ઉપયોગ કરતી વખતે બંડલ સાઈઝ ઘટાડવાની અહીં કેટલીક રીતો છે:

• જો શક્ય હોય તો બિલ્ડ સ્ટેપનો ઉપયોગ કરો.

  • જો આધુનિક બિલ્ડ ટૂલ દ્વારા બંડલ કરવામાં આવે તો Vue ના ઘણા APIs "tree-shakable" છે. ઉદાહરણ તરીકે, જો તમે બિલ્ટ-ઇન <Transition> ઘટકનો ઉપયોગ કરતા નથી, તો તે અંતિમ પ્રોડક્શન બંડલમાં શામેલ કરવામાં આવશે નહીં. ટ્રી-શેકિંગ તમારા સોર્સ કોડમાં અન્ય બિનઉપયોગી મોડ્યુલોને પણ દૂર કરી શકે છે.

  • બિલ્ડ સ્ટેપનો ઉપયોગ કરતી વખતે, નમૂનાઓ (templates) પ્રી-કમ્પાઇલ કરવામાં આવે છે જેથી આપણે બ્રાઉઝર પર Vue કમ્પાઇલર મોકલવાની જરૂર નથી. આ ૧૪kb min+gzipped JavaScript બચાવે છે અને રનટાઇમ કમ્પાઇલેશન ખર્ચ ટાળે છે.

• નવી ડિપેન્ડન્સીસ રજૂ કરતી વખતે સાઈઝ (size) પ્રત્યે સાવધ રહો! વાસ્તવિક દુનિયાની એપ્લિકેશન્સમાં, ફૂલેલા બંડલ્સ મોટે ભાગે ભારે નિર્ભરતાઓને સમજ્યા વગર રજૂ કરવાના પરિણામે હોય છે.

  • જો બિલ્ડ સ્ટેપનો ઉપયોગ કરી રહ્યાં હોવ, તો એવી ડિપેન્ડન્સીસ પસંદ કરો કે જે ES મોડ્યુલ ફોર્મેટ્સ ઓફર કરે અને ટ્રી-શેકિંગ ફ્રેન્ડલી હોય. ઉદાહરણ તરીકે, lodash પર lodash-es ને પ્રાધાન્ય આપો.

  • ડિપેન્ડન્સી સાઈઝ તપાસો અને મૂલ્યાંકન કરો કે તે જે કાર્યક્ષમતા પ્રદાન કરે છે તે મૂલ્યવાન છે કે નહીં. નોંધ લો કે જો ડિપેન્ડન્સી ટ્રી-શેકિંગ ફ્રેન્ડલી હોય, તો વાસ્તવિક સાઈઝ વધારો તમે તેનાથી ખરેખર ઇમ્પોર્ટ કરેલ APIs પર નિર્ભર રહેશે. bundlejs.com જેવા ટૂલ્સનો ઉપયોગ ઝડપી તપાસ માટે કરી શકાય છે, પરંતુ તમારા વાસ્તવિક બિલ્ડ સેટઅપ સાથે માપન હંમેશા સૌથી વધુ સચોટ રહેશે.

• જો તમે મુખ્યત્વે પ્રોગ્રેસિવ એન્હાન્સમેન્ટ માટે Vue નો ઉપયોગ કરી રહ્યાં છો અને બિલ્ડ સ્ટેપ ટાળવાનું પસંદ કરો છો, તો તેના બદલે petite-vue (માત્ર ૬kb) વાપરવાનું વિચારો.

કોડ સ્પ્લિટિંગ (Code Splitting) ​

કોડ સ્પ્લિટિંગ એ છે જ્યાં બિલ્ડ ટૂલ એપ્લિકેશન બંડલને બહુવિધ નાના ચંક્સ (chunks) માં વિભાજિત કરે છે, જે પછી માંગ પર અથવા પેરેલલી લોડ કરી શકાય છે. યોગ્ય કોડ સ્પ્લિટિંગ સાથે, પેજ લોડ વખતે જરૂરી સુવિધાઓ તાત્કાલિક ડાઉનલોડ કરી શકાય છે, વધારાના ચંક્સની જરૂર હોય ત્યારે જ લેઝી લોડ કરવામાં આવે છે, આમ પ્રદર્શનમાં સુધારો થાય છે.

બંડલર્સ જેમ કે રોલઅપ (Rollup - જેના પર Vite આધારિત છે) અથવા webpack ESM ડાયનેમિક ઇમ્પોર્ટ સિન્ટેક્સ શોધીને આપમેળે સ્પ્લિટ ચંક્સ બનાવી શકે છે:

// lazy.js અને તેની ડિપેન્ડન્સીસને એક અલગ ચંકમાં વહેંચવામાં આવશે
// અને જ્યારે `loadLazy()` ને કોલ કરવામાં આવે ત્યારે જ લોડ થશે.
function loadLazy() {
  return import('./lazy.js')
}

પ્રારંભિક પેજ લોડ પછી તરત જ જરૂરી ન હોય તેવી સુવિધાઓ પર લેઝી લોડિંગનો શ્રેષ્ઠ ઉપયોગ થાય છે. Vue એપ્લિકેશન્સમાં, આનો ઉપયોગ ઘટક ટ્રી (component trees) માટે સ્પ્લિટ ચંક્સ બનાવવા માટે Vue ના Async Component ફીચર સાથે સંયોજનમાં કરી શકાય છે:

import { defineAsyncComponent } from 'vue'

// Foo.vue અને તેની ડિપેન્ડન્સીસ માટે એક અલગ ચંક બનાવવામાં આવે છે.
// જ્યારે પેજ પર એસિંક ઘટક રેન્ડર કરવામાં આવે ત્યારે જ તે માગ પર લેવામાં આવે છે.
const Foo = defineAsyncComponent(() => import('./Foo.vue'))

Vue Router નો ઉપયોગ કરતી એપ્લિકેશન્સ માટે, રૂટ ઘટકો માટે લેઝી લોડિંગનો ઉપયોગ કરવાની ભારપૂર્વક ભલામણ કરવામાં આવે છે. Vue Router પાસે defineAsyncComponent થી અલગ લેઝી લોડિંગ માટે સ્પષ્ટ સપોર્ટ છે. વધુ વિગતો માટે લેઝી લોડિંગ રૂટ્સ (Lazy Loading Routes) જુઓ.

અપડેટ ઓપ્ટિમાઇઝેશન (Update Optimizations) ​

પ્રોપ્સ સ્ટેબિલિટી (Props Stability) ​

Vue માં, ચાઇલ્ડ કમ્પોનન્ટ ત્યારે જ અપડેટ થાય છે જ્યારે તેના પ્રાપ્ત થયેલા ઓછામાં ઓછા એક પ્રોપમાં ફેરફાર થયો હોય. નીચેનું ઉદાહરણ ધ્યાનમાં લો:

<ListItem
  v-for="item in list"
  :id="item.id"
  :active-id="activeId" />

<ListItem> ઘટકની અંદર, તે હાલમાં સક્રિય આઇટમ છે કે નહીં તે નક્કી કરવા માટે તેના id અને activeId પ્રોપ્સનો ઉપયોગ કરે છે. જ્યારે આ કામ કરે છે, ત્યારે સમસ્યા એ છે કે જ્યારે પણ activeId બદલાય છે, ત્યારે લિસ્ટમાંનો દરેક <ListItem> અપડેટ થવો જોઈએ!

આદર્શ રીતે, ફક્ત તે જ આઇટમ્સ જેની સક્રિય સ્થિતિ (active status) બદલાઈ ગઈ છે તે અપડેટ થવી જોઈએ. અમે પેરેન્ટ (parent) માં એક્ટિવ સ્ટેટસ કોમ્પ્યુટેશનને ખસેડીને અને <ListItem> સીધા જ active પ્રોપ સ્વીકારે તે રીતે તે હાંસલ કરી શકીએ છીએ:

<ListItem
  v-for="item in list"
  :id="item.id"
  :active="item.id === activeId" />

હવે, મોટાભાગના ઘટકો માટે active પ્રોપ સમાન રહેશે જ્યારે activeId બદલાય છે, તેથી તેમને હવે અપડેટ કરવાની જરૂર નથી. સામાન્ય રીતે, વિચાર એ છે કે ચાઇલ્ડ કમ્પોનન્ટ્સને પસાર કરવામાં આવતા પ્રોપ્સને શક્ય તેટલું સ્થિર (stable) રાખવું.

v-once ​

v-once એ બિલ્ટ-ઇન ડાયરેક્ટિવ છે જેનો ઉપયોગ રનટાઇમ ડેટા પર આધાર રાખતી સામગ્રીને રેન્ડર કરવા માટે થઈ શકે છે પરંતુ તેને ક્યારેય અપડેટ કરવાની જરૂર નથી. જે આખું સબ-ટ્રી તેના પર વપરાયેલ છે તે તમામ ભાવિ અપડેટ્સ માટે છોડી દેવામાં આવશે. વધુ વિગતો માટે તેના API રિફરન્સ નો સંપર્ક કરો.

v-memo ​

v-memo એ બિલ્ટ-ઇન ડાયરેક્ટિવ છે જેનો ઉપયોગ મોટા સબ-ટ્રીઝ અથવા v-for લિસ્ટ્સના અપડેટને શરતી રીતે છોડવા માટે થઈ શકે છે. વધુ વિગતો માટે તેના API રિફરન્સ નો સંપર્ક કરો.

કોમ્પ્યુટેડ સ્ટેબિલિટી (Computed Stability) ​

Vue ૩.૪ અને તેનાથી ઉપરના વર્ઝનમાં, કોમ્પ્યુટેડ પ્રોપર્ટી ત્યારે જ ઇફેક્ટ્સ ટ્રિગર કરશે જ્યારે તેની ગણતરી કરેલ કિંમત અગાઉના એક કરતા બદલાઈ હોય. ઉદાહરણ તરીકે, નીચેની isEven ગણતરી માત્ર ઇફેક્ટ્સ ટ્રિગર કરે છે જો પરત કરેલ વેલ્યુ true માંથી false અથવા ઊલટું બદલાઈ હોય:

const count = ref(0)
const isEven = computed(() => count.value % 2 === 0)

watchEffect(() => console.log(isEven.value)) // true

// નવી લોગ્સ ટ્રિગર થશે નહીં કારણ કે ગણતરી કરેલ મૂલ્ય `true` રહેશે
count.value = 2
count.value = 4

આ બિનજરૂરી ઇફેક્ટ ટ્રિગર્સ ઘટાડે છે, પરંતુ જો ગણતરીમાં દરેક વખતે નવો ઓબ્જેક્ટ બનાવવામાં આવે તો તે કમનસીબે કામ કરતું નથી:

const computedObj = computed(() => {
  return {
    isEven: count.value % 2 === 0
  }
})

કારણ કે દરેક વખતે નવો ઓબ્જેક્ટ બનાવવામાં આવે છે, નવું મૂલ્ય તકનીકી રીતે હંમેશા જૂના મૂલ્યથી અલગ હોય છે. ભલે isEven પ્રોપર્ટી સમાન રહે, Vue જ્યાં સુધી તે જૂના મૂલ્ય અને નવા મૂલ્યની ઊંડાણપૂર્વક સરખામણી (deep comparison) ન કરે ત્યાં સુધી જાણી શકશે નહીં. આવી સરખામણી ખર્ચાળ હોઈ શકે છે અને સંભવતઃ તે મૂલ્યવાન નથી.

તેના બદલે, અમે જૂના મૂલ્ય સાથે નવા મૂલ્યની જાતે સરખામણી કરીને આને શ્રેષ્ઠ બનાવી શકીએ છીએ, અને જો આપણને ખબર હોય કે કંઈ બદલાયું નથી તો શરતી રીતે જૂનું મૂલ્ય પરત કરી શકીએ છીએ:

const computedObj = computed((oldValue) => {
  const newValue = {
    isEven: count.value % 2 === 0
  }
  if (oldValue && oldValue.isEven === newValue.isEven) {
    return oldValue
  }
  return newValue
})

Playground માં તે અજમાવી જુઓ

નોંધ લો કે તમારે જૂના મૂલ્યની સરખામણી કરવા અને પરત કરવા પહેલાં હંમેશા સંપૂર્ણ ગણતરી કરવી જોઈએ, જેથી દરેક રન પર સમાન ડિપેન્ડન્સીસ એકત્રિત કરી શકાય.

સામાન્ય ઓપ્ટિમાઇઝેશન (General Optimizations) ​

નીચેની ટિપ્સ પેજ લોડ અને અપડેટ પર્ફોર્મન્સ બંનેને અસર કરે છે.

વિઝ્યુઅલાઈઝ લાર્જ લિસ્ટ્સ (Virtualize Large Lists) ​

તમામ ફ્રન્ટએન્ડ એપ્લિકેશન્સમાં સૌથી સામાન્ય પર્ફોર્મન્સ સમસ્યાઓમાંથી એક વિશાળ યાદી પ્રસ્તુત (rendering large lists) કરવી છે. ફ્રેમવર્ક ભલે ગમે તેટલું પર્ફોર્મન્ટ હોય, હજારો વસ્તુઓ સાથેની યાદી રેન્ડર કરવી તે ધીમી હશે કારણ કે બ્રાઉઝરે હેન્ડલ કરવાની જરૂર હોય તેવા DOM નોડ્સની વિશાળ સંખ્યા છે.

જો કે, આપણે આ તમામ નોડ્સને અગાઉથી રેન્ડર કરવા જરૂરી નથી. મોટાભાગના કિસ્સાઓમાં, વપરાશકર્તાની સ્ક્રીન સાઈઝ આપણી આટલી મોટી યાદીનો માત્ર એક નાનો સબસેટ જ પ્રદર્શિત કરી શકે છે. આપણે લિસ્ટ વિઝ્યુઅલાઈઝેશન (list virtualization) સાથે પ્રદર્શનમાં ઘણો સુધારો કરી શકીએ છીએ, જે મોટી યાદીમાં હાલમાં વ્યુપોર્ટ (viewport) માં અથવા તેની નજીકની વસ્તુઓ જ રેન્ડર કરવાની તકનીક છે.

લિસ્ટ વિઝ્યુલાઇઝેશન અમલમાં મૂકવું સરળ નથી, સદભાગ્યે ત્યાં અસ્તિત્વમાં રહેલી સમુદાય લાઇબ્રેરીઓ છે જેનો તમે સીધો ઉપયોગ કરી શકો છો:

• vue-virtual-scroller
• vue-virtual-scroll-grid
• vueuc/VVirtualList

વિશાળ ઇમ્યુટેબલ (Immutable) સ્ટ્રક્ચર્સ માટે રિએક્ટિવિટી ઓવરહેડ ઘટાડવો ​

Vue ની રિએક્ટિવિટી સિસ્ટમ ડિફોલ્ટ રૂપે ઊંડી (deep) છે. જ્યારે આ સ્ટેટ મેનેજમેન્ટને સાહજિક બનાવે છે, તે ત્યારે અમુક સ્તરનું ઓવરહેડ બનાવે છે જ્યારે ડેટાની સાઈઝ મોટી હોય છે, કારણ કે દરેક પ્રોપર્ટી એક્સેસ પ્રોક્સી ટ્રેપ્સને ટ્રિગર કરે છે જે ડિપેન્ડન્સી ટ્રેકિંગ કરે છે. આ સામાન્ય રીતે ત્યારે નોંધનીય બને છે જ્યારે ઊંડા નેસ્ટેડ ઓબ્જેક્ટ્સની વિશાળ એરે સાથે કામ કરવામાં આવે છે, જ્યાં સિંગલ રેન્ડરને ૧,૦૦,૦૦૦+ પ્રોપર્ટીઝ એક્સેસ કરવાની જરૂર હોય છે, તેથી તે માત્ર ખૂબ જ વિશિષ્ટ ઉપયોગના કિસ્સાઓને અસર કરે છે.

Vue shallowRef() અને shallowReactive() નો ઉપયોગ કરીને ઊંડી રિએક્ટિવિટી પસંદગીયુક્ત રીતે રક્ષણ આપે છે. શેલો (Shallow) APIs જે સ્ટેટ બનાવે છે તે માત્ર રુટ સ્તરે જ રિએક્ટિવ હોય છે, અને તમામ નેસ્ટેડ ઓબ્જેક્ટ્સને અસ્પૃશ્ય એક્સપોઝ કરે છે. આ નેસ્ટેડ પ્રોપર્ટી એક્સેસને ઝડપી રાખે છે, ટ્રેડ-ઓફ એ છે કે આપણે હવે તમામ નેસ્ટેડ ઓબ્જેક્ટ્સને ઇમ્યુટેબલ તરીકે ગણવા જોઈએ, અને અપડેટ્સ માત્ર રુટ સ્ટેટને બદલીને ટ્રિગર કરી શકાય છે:

const shallowArray = shallowRef([
  /* ઊંડા ઓબ્જેક્ટ્સની મોટી યાદી */
])

// આ ફર્ક લાવશે નહીં...
shallowArray.value.push(newObject)
// આ લાવશે:
shallowArray.value = [...shallowArray.value, newObject]

// આ ફર્ક લાવશે નહીં...
shallowArray.value[0].foo = 1
// આ લાવશે:
shallowArray.value = [
  {
    ...shallowArray.value[0],
    foo: 1
  },
  ...shallowArray.value.slice(1)
]

બિનજરૂરી કમ્પોનન્ટ એબ્સ્ટ્રેક્શન્સ (Abstractions) ટાળો ​

ક્યારેક આપણે બહેતર એબ્સ્ટ્રેક્શન અથવા કોડ ઓર્ગેનાઈઝેશન માટે renderless components અથવા હાયર-ઓર્ડર ઘટકો (એટલે ​​કે એવા ઘટકો કે જે વધારાના પ્રોપ્સ સાથે અન્ય ઘટકોને રેન્ડર કરે છે) બનાવી શકીએ છીએ. જ્યારે આમાં કંઈ ખોટું નથી, ત્યારે એ ધ્યાનમાં રાખો કે ઘટક ઇન્સ્ટન્સ સાદા DOM નોડ્સ કરતાં ઘણા વધુ ખર્ચાળ છે, અને એબ્સ્ટ્રેક્શન પેટર્નને કારણે તેમાંથી ઘણા બધા બનાવવા પર્ફોર્મન્સ ખર્ચમાં વધારો કરશે.

નોંધ કરો કે માત્ર થોડા ઇન્સ્ટન્સ ઘટાડવાથી નોંધનીય અસર થશે નહીં, તેથી જો એપમાં ઘટક માત્ર થોડી જ વાર રેન્ડર કરવામાં આવે તો ચિંતા કરશો નહીં. આ ઓપ્ટિમાઇઝેશનને ધ્યાનમાં લેવાનું શ્રેષ્ઠ દૃશ્ય ફરીથી વિશાળ યાદીઓમાં છે. ૧૦૦ આઇટમ્સની યાદીની કલ્પના કરો જ્યાં દરેક આઇટમ કમ્પોનન્ટમાં ઘણા ચાઇલ્ડ કમ્પોનન્ટ્સ હોય છે. અહીં એક બિનજરૂરી ઘટક એબ્સ્ટ્રેક્શન દૂર કરવાથી સેંકડો ઘટક ઇન્સ્ટન્સનો ઘટાડો થઈ શકે છે.