Priority C Rules: Recommended #

Where multiple, equally good options exist, an arbitrary choice can be made to ensure consistency. In these rules, we describe each acceptable option and suggest a default choice. That means you can feel free to make a different choice in your own codebase, as long as you're consistent and have a good reason. Please do have a good reason though! By adapting to the community standard, you will:

1. Train your brain to more easily parse most of the community code you encounter
2. Be able to copy and paste most community code examples without modification
3. Often find new hires are already accustomed to your preferred coding style, at least in regards to Kdu

Component/instance options order #

Component/instance options should be ordered consistently.

This is the default order we recommend for component options. They're split into categories, so you'll know where to add new properties from plugins.

1. Global Awareness (requires knowledge beyond the component)

   • name

2. Template Compiler Options (changes the way templates are compiled)

   • compilerOptions

3. Template Dependencies (assets used in the template)

   • components
   • directives

4. Composition (merges properties into the options)

   • extends
   • mixins
   • provide/inject

5. Interface (the interface to the component)

   • inheritAttrs
   • props
   • emits

6. Composition API (the entry point for using the Composition API)

   • setup

7. Local State (local reactive properties)

   • data
   • computed

8. Events (callbacks triggered by reactive events)

   • watch
   • Lifecycle Events (in the order they are called)
     • beforeCreate
     • created
     • beforeMount
     • mounted
     • beforeUpdate
     • updated
     • activated
     • deactivated
     • beforeUnmount
     • unmounted
     • errorCaptured
     • renderTracked
     • renderTriggered

9. Non-Reactive Properties (instance properties independent of the reactivity system)

   • methods

10. Rendering (the declarative description of the component output)

    • template/render

Element attribute order #

The attributes of elements (including components) should be ordered consistently.

This is the default order we recommend for component options. They're split into categories, so you'll know where to add custom attributes and directives.

1. Definition (provides the component options)

   • is

2. List Rendering (creates multiple variations of the same element)

   • k-for

3. Conditionals (whether the element is rendered/shown)

   • k-if
   • k-else-if
   • k-else
   • k-show
   • k-cloak

4. Render Modifiers (changes the way the element renders)

   • k-pre
   • k-once

5. Global Awareness (requires knowledge beyond the component)

   • id

6. Unique Attributes (attributes that require unique values)

   • ref
   • key

7. Two-Way Binding (combining binding and events)

   • k-model

8. Other Attributes (all unspecified bound & unbound attributes)

9. Events (component event listeners)

   • k-on

10. Content (overrides the content of the element)

    • k-html
    • k-text

Empty lines in component/instance options #

You may want to add one empty line between multi-line properties, particularly if the options can no longer fit on your screen without scrolling.

When components begin to feel cramped or difficult to read, adding spaces between multi-line properties can make them easier to skim again. In some editors, such as Vim, formatting options like this can also make them easier to navigate with the keyboard.

props: {
  value: {
    type: String,
    required: true
  },

  focused: {
    type: Boolean,
    default: false
  },

  label: String,
  icon: String
},

computed: {
  formattedValue() {
    // ...
  },

  inputClasses() {
    // ...
  }
}

// No spaces are also fine, as long as the component
// is still easy to read and navigate.
props: {
  value: {
    type: String,
    required: true
  },
  focused: {
    type: Boolean,
    default: false
  },
  label: String,
  icon: String
},
computed: {
  formattedValue() {
    // ...
  },
  inputClasses() {
    // ...
  }
}

Single-file component top-level element order #

Single-File Components should always order <script>, <template>, and <style> tags consistently, with <style> last, because at least one of the other two is always necessary.

<style>/* ... */</style>
<script>/* ... */</script>
<template>...</template>

<!-- ComponentA.kdu -->
<script>/* ... */</script>
<template>...</template>
<style>/* ... */</style>

<!-- ComponentB.kdu -->
<template>...</template>
<script>/* ... */</script>
<style>/* ... */</style>

<!-- ComponentA.kdu -->
<script>/* ... */</script>
<template>...</template>
<style>/* ... */</style>

<!-- ComponentB.kdu -->
<script>/* ... */</script>
<template>...</template>
<style>/* ... */</style>

<!-- ComponentA.kdu -->
<template>...</template>
<script>/* ... */</script>
<style>/* ... */</style>

<!-- ComponentB.kdu -->
<template>...</template>
<script>/* ... */</script>
<style>/* ... */</style>