પ્રાથમિકતા B નિયમો: ભારપૂર્વક ભલામણ કરેલ (Priority B Rules: Strongly Recommended) ​

આ નિયમો મોટાભાગના પ્રોજેક્ટ્સમાં વાંચવાની ક્ષમતા (readability) અને/અથવા ડેવલપરના અનુભવને સુધારવા માટે મળ્યા છે. જો તમે તેનું ઉલ્લંઘન કરશો તો પણ તમારો કોડ ચાલશે, પરંતુ ઉલ્લંઘન દુર્લભ અને યોગ્ય રીતે વાજબી હોવું જોઈએ.

કમ્પોનન્ટ ફાઇલ્સ (Component files) ​

જ્યારે પણ ફાઇલ્સને જોડવા (concatenate) માટે બિલ્ડ સિસ્ટમ ઉપલબ્ધ હોય, ત્યારે દરેક ઘટક તેની પોતાની ફાઇલમાં હોવો જોઈએ.

આ તમને ઘટકને ઝડપથી શોધવામાં મદદ કરે છે જ્યારે તમારે તેને સંપાદિત કરવાની અથવા તેનો ઉપયોગ કેવી રીતે કરવો તેની સમીક્ષા કરવાની જરૂર હોય.

app.component('TodoList', {
  // ...
})

app.component('TodoItem', {
  // ...
})

components/
|- TodoList.js
|- TodoItem.js

components/
|- TodoList.vue
|- TodoItem.vue

સિંગલ-ફાઇલ કમ્પોનન્ટ ફાઇલનેમ કેસિંગ ​

સિંગલ-ફાઇલ કમ્પોનન્ટ્સ (Single-File Components) ના ફાઇલનેમ હંમેશા PascalCase અથવા હંમેશા kebab-case હોવા જોઈએ.

PascalCase કોડ એડિટર્સમાં ઓટોકમ્પ્લીટ સાથે શ્રેષ્ઠ રીતે કામ કરે છે, કારણ કે જ્યાં પણ શક્ય હોય ત્યાં JS(X) અને ટેમ્પ્લેટ્સમાં ઘટકોને સંદર્ભિત કરવાની રીત સાથે તે સુસંગત છે. જો કે, મિક્સ્ડ કેસ ફાઇલનેમ ક્યારેક કેસ-ઇનસેન્સિટિવ ફાઇલ સિસ્ટમ્સ પર સમસ્યાઓ સર્જી શકે છે, જેથી kebab-case પણ સંપૂર્ણપણે સ્વીકાર્ય છે.

components/
|- mycomponent.vue

components/
|- myComponent.vue

components/
|- MyComponent.vue

components/
|- my-component.vue

બેઝ કમ્પોનન્ટ નામો (Base component names) ​

બેઝ ઘટકો (a.k.a. presentational, dumb, અથવા pure ઘટકો) જે એપ-વિશિષ્ટ સ્ટાઇલિંગ અને કન્વેન્શન્સ લાગુ કરે છે તે તમામ ચોક્કસ ઉપસર્ગ (prefix) થી શરૂ થવા જોઈએ, જેમ કે Base, App, અથવા V.

components/
|- MyButton.vue
|- VueTable.vue
|- Icon.vue

components/
|- BaseButton.vue
|- BaseTable.vue
|- BaseIcon.vue

components/
|- AppButton.vue
|- AppTable.vue
|- AppIcon.vue

components/
|- VButton.vue
|- VTable.vue
|- VIcon.vue

ગાઢ રીતે જોડાયેલા કમ્પોનન્ટ નામો (Tightly coupled component names) ​

પેરેન્ટ સાથે ગાઢ રીતે જોડાયેલા ચાઇલ્ડ ઘટકોમાં પેરેન્ટ ઘટકનું નામ ઉપસર્ગ (prefix) તરીકે સામેલ હોવું જોઈએ.

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

components/
|- TodoList/
   |- Item/
      |- index.vue
      |- Button.vue
   |- index.vue

components/
|- TodoList/
   |- Item/
      |- Button.vue
   |- Item.vue
|- TodoList.vue

components/
|- TodoList.vue
|- TodoItem.vue
|- TodoButton.vue

components/
|- SearchSidebar.vue
|- NavigationForSearchSidebar.vue

components/
|- TodoList.vue
|- TodoListItem.vue
|- TodoListItemButton.vue

components/
|- SearchSidebar.vue
|- SearchSidebarNavigation.vue

કમ્પોનન્ટ નામોમાં શબ્દોનો ક્રમ (Order of words in component names) ​

ઘટક નામો સૌથી ઉચ્ચ-સ્તરના (ઘણીવાર સૌથી સામાન્ય) શબ્દોથી શરૂ થવા જોઈએ અને વર્ણનાત્મક ફેરફાર કરતા શબ્દો સાથે સમાપ્ત થવા જોઈએ.

components/
|- ClearSearchButton.vue
|- ExcludeFromSearchInput.vue
|- LaunchOnStartupCheckbox.vue
|- RunSearchButton.vue
|- SearchInput.vue
|- TermsCheckbox.vue

components/
|- SearchButtonClear.vue
|- SearchButtonRun.vue
|- SearchInputExcludeGlob.vue
|- SearchInputQuery.vue
|- SettingsCheckboxLaunchOnStartup.vue
|- SettingsCheckboxTerms.vue

components/
|- ClearSearchButton.vue
|- ExcludeFromSearchInput.vue
|- LaunchOnStartupCheckbox.vue
|- RunSearchButton.vue
|- SearchInput.vue
|- TermsCheckbox.vue

components/
|- SearchButtonClear.vue
|- SearchButtonRun.vue
|- SearchInputQuery.vue
|- SearchInputExcludeGlob.vue
|- SettingsCheckboxTerms.vue
|- SettingsCheckboxLaunchOnStartup.vue

સેલ્ફ-ક્લોઝિંગ કમ્પોનન્ટ્સ (Self-closing components) ​

કોઈ કન્ટેન્ટ ન હોય તેવા ઘટકો સિંગલ-ફાઇલ કમ્પોનન્ટ્સ (Single-File Components), સ્ટ્રિંગ ટેમ્પ્લેટ્સ, અને JSX માં સેલ્ફ-ક્લોઝિંગ હોવા જોઈએ - પરંતુ ઇન-DOM ટેમ્પ્લેટ્સમાં ક્યારેય નહીં.

સેલ્ફ-ક્લોઝ થતા ઘટકો જણાવે છે કે તેમની પાસે માત્ર કોઈ કન્ટેન્ટ નથી, પણ ઈરાદાપૂર્વક કોઈ કન્ટેન્ટ નથી. તે પુસ્તકમાં ખાલી પેજ અને "આ પેજ ઈરાદાપૂર્વક ખાલી છુટેલ છે" લેબલવાળા પેજ વચ્ચેનો તફાવત છે. બિનજરૂરી ક્લોઝિંગ ટેગ વિના તમારો કોડ પણ સ્વચ્છ છે.

દુર્ભાગ્યે, HTML કસ્ટમ એલિમેન્ટ્સને સેલ્ફ-ક્લોઝિંગ કરવાની મંજૂરી આપતું નથી - ફક્ત સત્તાવાર "void" એલિમેન્ટ્સ. તેથી જ આ વ્યૂહરચના ત્યારે જ શક્ય છે જ્યારે Vue ના ટેમ્પ્લેટ કમ્પાઇલર ડોમ (DOM) પહેલા ટેમ્પ્લેટ સુધી પહોંચી શકે, પછી DOM સ્પેક-અનુરૂપ HTML પીરસે.

<!-- સિંગલ-ફાઇલ કમ્પોનન્ટ્સ, સ્ટ્રિંગ ટેમ્પ્લેટ્સ, અને JSX માં -->
<MyComponent></MyComponent>

<!-- ઇન-DOM ટેમ્પ્લેટ્સમાં -->
<my-component/>

<!-- સિંગલ-ફાઇલ કમ્પોનન્ટ્સ, સ્ટ્રિંગ ટેમ્પ્લેટ્સ, અને JSX માં -->
<MyComponent/>

<!-- ઇન-DOM ટેમ્પ્લેટ્સમાં -->
<my-component></my-component>

ટેમ્પ્લેટ્સમાં કમ્પોનન્ટ નામ કેસિંગ ​

મોટાભાગના પ્રોજેક્ટ્સમાં, ઘટક નામો સિંગલ-ફાઇલ કમ્પોનન્ટ્સ (Single-File Components) અને સ્ટ્રિંગ ટેમ્પ્લેટ્સમાં હંમેશા PascalCase હોવા જોઈએ - પરંતુ ઇન-DOM ટેમ્પ્લેટ્સમાં kebab-case.

PascalCase ના kebab-case કરતા કેટલાક ફાયદા છે:

• એડિટર્સ ટેમ્પ્લેટ્સમાં ઘટક નામો ઓટોકમ્પ્લીટ કરી શકે છે, કારણ કે PascalCase JavaScript માં પણ ઉપયોગમાં લેવાય છે.
• <MyComponent> એક-શબ્દના HTML એલિમેન્ટ કરતા <my-component> કરતા દૃષ્ટિગત રીતે વધુ અલગ છે, કારણ કે બે અક્ષર તફાવત (બે કેપિટલ) છે, માત્ર એક (હાઇફન) ના બદલે.
• જો તમે તમારા ટેમ્પ્લેટ્સમાં કોઈ non-Vue કસ્ટમ એલિમેન્ટ્સ ઉપયોગ કરો છો, જેમ કે વેબ કમ્પોનન્ટ, PascalCase ખાતરી કરે છે કે તમારા Vue ઘટકો સ્પષ્ટ રીતે દેખાય છે.

દુર્ભાગ્યે, HTML ની કેસ ઇનસેન્સિટિવિટી (case insensitivity) ને કારણે, ઇન-DOM ટેમ્પ્લેટ્સે હજુ પણ kebab-case નો ઉપયોગ કરવો પડે.

એ પણ નોંધો કે જો તમે પહેલેથી kebab-case માં ભારે રોકાણ કર્યું છે, તો HTML કન્વેન્શન્સ સાથે સુસંગતતા અને તમારા બધા પ્રોજેક્ટ્સમાં સમાન કેસિંગનો ઉપયોગ કરવો ઉપર સૂચિબદ્ધ ફાયદાઓ કરતા વધુ મહત્વપૂર્ણ હોઈ શકે. તે કિસ્સાઓમાં, સર્વત્ર kebab-case નો ઉપયોગ કરવો પણ સ્વીકાર્ય છે.

<!-- સિંગલ-ફાઇલ કમ્પોનન્ટ્સ અને સ્ટ્રિંગ ટેમ્પ્લેટ્સમાં -->
<mycomponent/>

<!-- સિંગલ-ફાઇલ કમ્પોનન્ટ્સ અને સ્ટ્રિંગ ટેમ્પ્લેટ્સમાં -->
<myComponent/>

<!-- ઇન-DOM ટેમ્પ્લેટ્સમાં -->
<MyComponent></MyComponent>

<!-- સિંગલ-ફાઇલ કમ્પોનન્ટ્સ અને સ્ટ્રિંગ ટેમ્પ્લેટ્સમાં -->
<MyComponent/>

<!-- ઇન-DOM ટેમ્પ્લેટ્સમાં -->
<my-component></my-component>

<!-- સર્વત્ર (Everywhere) -->
<my-component></my-component>

JS/JSX માં કમ્પોનન્ટ નામ કેસિંગ ​

JS/JSX માં ઘટક નામો હંમેશા PascalCase હોવા જોઈએ, જો કે app.component દ્વારા ફક્ત ગ્લોબલ કમ્પોનન્ટ રજિસ્ટ્રેશનનો ઉપયોગ કરતી સરળ એપ્લિકેશન્સ માટે સ્ટ્રિંગ્સ અંદર kebab-case હોઈ શકે.

app.component('myComponent', {
  // ...
})

import myComponent from './MyComponent.vue'

export default {
  name: 'myComponent'
  // ...
}

export default {
  name: 'my-component'
  // ...
}

app.component('MyComponent', {
  // ...
})

app.component('my-component', {
  // ...
})

import MyComponent from './MyComponent.vue'

export default {
  name: 'MyComponent'
  // ...
}

પૂર્ણ-શબ્દ કમ્પોનન્ટ નામો (Full-word component names) ​

ઘટક નામો ટૂંકાક્ષરો (abbreviations) ના બદલે પૂર્ણ શબ્દોને પ્રાધાન્ય આપવું જોઈએ.

એડિટર્સમાં ઓટોકમ્પ્લીટ લાંબા નામો લખવાનો ખર્ચ ઘણો ઓછો બનાવે છે, જ્યારે તેઓ જે સ્પષ્ટતા પ્રદાન કરે છે તે અમૂલ્ય છે. ખાસ કરીને, અસામાન્ય ટૂંકાક્ષરો (uncommon abbreviations) હંમેશા ટાળવા જોઈએ.

components/
|- SdSettings.vue
|- UProfOpts.vue

components/
|- StudentDashboardSettings.vue
|- UserProfileOptions.vue

પ્રોપ નામ કેસિંગ (Prop name casing) ​

પ્રોપ નામો ડિક્લેરેશન દરમિયાન હંમેશા camelCase હોવા જોઈએ. ઇન-DOM ટેમ્પ્લેટ્સમાં ઉપયોગ કરતી વખતે, પ્રોપ્સ kebab-cased હોવા જોઈએ. સિંગલ-ફાઇલ કમ્પોનન્ટ ટેમ્પ્લેટ્સ અને JSX kebab-case અથવા camelCase પ્રોપ્સ બંનેનો ઉપયોગ કરી શકે. કેસિંગ સુસંગત હોવું જોઈએ - જો તમે camelCased પ્રોપ્સ ઉપયોગ કરવાનું પસંદ કરો, તો ખાતરી કરો કે તમે તમારી એપ્લિકેશનમાં kebab-cased પ્રોપ્સ ઉપયોગ ન કરો

props: {
  'greeting-text': String
}

const props = defineProps({
  'greeting-text': String
})

// ઇન-DOM ટેમ્પ્લેટ્સ માટે
<welcome-message greetingText="hi"></welcome-message>

props: {
  greetingText: String
}

const props = defineProps({
  greetingText: String
})

// SFC માટે - કૃપા કરીને ખાતરી કરો કે તમારા આખા પ્રોજેક્ટમાં કેસિંગ સુસંગત છે
// તમે ગમે તે કન્વેન્શન ઉપયોગ કરી શકો પરંતુ અમે બે અલગ કેસિંગ સ્ટાઇલ્સ મિક્સ કરવાની ભલામણ કરતા નથી
<WelcomeMessage greeting-text="hi"/>
// અથવા
<WelcomeMessage greetingText="hi"/>

// ઇન-DOM ટેમ્પ્લેટ્સ માટે
<welcome-message greeting-text="hi"></welcome-message>

મલ્ટી-એટ્રિબ્યુટ એલિમેન્ટ્સ (Multi-attribute elements) ​

બહુવિધ એટ્રિબ્યુટ્સ ધરાવતા એલિમેન્ટ્સ બહુવિધ લાઇન્સ પર ફેલાવા જોઈએ, દરેક લાઇન પર એક એટ્રિબ્યુટ.

JavaScript માં, બહુવિધ પ્રોપર્ટીઝ ધરાવતા ઓબ્જેક્ટ્સને બહુવિધ લાઇન્સમાં વિભાજિત કરવું એ વ્યાપક રીતે સારો કન્વેન્શન માનવામાં આવે છે, કારણ કે તે વાંચવામાં ઘણું સરળ છે. અમારા ટેમ્પ્લેટ્સ અને JSX એ જ ધ્યાનને પાત્ર છે.

<img src="https://vuejs.org/images/logo.png" alt="Vue Logo">

<MyComponent foo="a" bar="b" baz="c"/>

<img
  src="https://vuejs.org/images/logo.png"
  alt="Vue Logo"
>

<MyComponent
  foo="a"
  bar="b"
  baz="c"
/>

ટેમ્પ્લેટ્સમાં સરળ એક્સપ્રેશન્સ (Simple expressions in templates) ​

ઘટક ટેમ્પ્લેટ્સમાં માત્ર સરળ એક્સપ્રેશન્સ હોવા જોઈએ, વધુ જટિલ એક્સપ્રેશન્સે computed પ્રોપર્ટીઝ અથવા methods માં રિફેક્ટર થવા જોઈએ.

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

{{
  fullName.split(' ').map((word) => {
    return word[0].toUpperCase() + word.slice(1)
  }).join(' ')
}}

<!-- ટેમ્પ્લેટમાં -->
{{ normalizedFullName }}

// જટિલ એક્સપ્રેશનને computed પ્રોપર્ટીમાં ખસેડવામાં આવ્યું છે
computed: {
  normalizedFullName() {
    return this.fullName.split(' ')
      .map(word => word[0].toUpperCase() + word.slice(1))
      .join(' ')
  }
}

// જટિલ એક્સપ્રેશનને computed પ્રોપર્ટીમાં ખસેડવામાં આવ્યું છે
const normalizedFullName = computed(() =>
  fullName.value
    .split(' ')
    .map((word) => word[0].toUpperCase() + word.slice(1))
    .join(' ')
)

સરળ computed પ્રોપર્ટીઝ (Simple computed properties) ​

જટિલ computed પ્રોપર્ટીઝને શક્ય તેટલી ઘણી સરળ પ્રોપર્ટીઝમાં વિભાજિત કરવી જોઈએ.

computed: {
  price() {
    const basePrice = this.manufactureCost / (1 - this.profitMargin)
    return (
      basePrice -
      basePrice * (this.discountPercent || 0)
    )
  }
}

const price = computed(() => {
  const basePrice = manufactureCost.value / (1 - profitMargin.value)
  return basePrice - basePrice * (discountPercent.value || 0)
})

computed: {
  basePrice() {
    return this.manufactureCost / (1 - this.profitMargin)
  },

  discount() {
    return this.basePrice * (this.discountPercent || 0)
  },

  finalPrice() {
    return this.basePrice - this.discount
  }
}

const basePrice = computed(
  () => manufactureCost.value / (1 - profitMargin.value)
)

const discount = computed(
  () => basePrice.value * (discountPercent.value || 0)
)

const finalPrice = computed(() => basePrice.value - discount.value)

ક્વોટેડ એટ્રિબ્યુટ વેલ્યુ (Quoted attribute values) ​

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

જ્યારે કોઈ સ્પેસ ન હોય તેવા એટ્રિબ્યુટ વેલ્યુ માટે HTML માં ક્વોટ્સ જરૂરી નથી, આ પ્રથા ઘણીવાર સ્પેસ ટાળવા તરફ દોરી જાય છે, જે એટ્રિબ્યુટ વેલ્યુને ઓછા વાંચી શકાય તેવા બનાવે છે.

<input type=text>

<AppSidebar :style={width:sidebarWidth+'px'}>

<input type="text">

<AppSidebar :style="{ width: sidebarWidth + 'px' }">

ડિરેક્ટિવ શોર્ટહેન્ડ્સ (Directive shorthands) ​

ડિરેક્ટિવ શોર્ટહેન્ડ્સ (v-bind: માટે :, v-on: માટે @ અને v-slot માટે #) નો ઉપયોગ હંમેશા અથવા ક્યારેય ન થવો જોઈએ.

<input
  v-bind:value="newTodoText"
  :placeholder="newTodoInstructions"
>

<input
  v-on:input="onInput"
  @focus="onFocus"
>

<template v-slot:header>
  <h1>Here might be a page title</h1>
</template>

<template #footer>
  <p>Here's some contact info</p>
</template>

<input
  :value="newTodoText"
  :placeholder="newTodoInstructions"
>

<input
  v-bind:value="newTodoText"
  v-bind:placeholder="newTodoInstructions"
>

<input
  @input="onInput"
  @focus="onFocus"
>

<input
  v-on:input="onInput"
  v-on:focus="onFocus"
>

<template v-slot:header>
  <h1>Here might be a page title</h1>
</template>

<template v-slot:footer>
  <p>Here's some contact info</p>
</template>

<template #header>
  <h1>Here might be a page title</h1>
</template>

<template #footer>
  <p>Here's some contact info</p>
</template>