Vue 3 Composition API: Pola yang Benar untuk Project Nyata

 

Pendahuluan

Sejak rilis Vue 3, Composition API menjadi pendekatan utama dalam membangun aplikasi Vue modern.
Sayangnya, banyak developer masih salah kaprah: semua logic ditaruh di setup() tanpa struktur yang jelas.

Akibatnya:

• file cepat berantakan

• susah dibaca

• sulit di-maintain

• makin besar project, makin ribet

Di artikel ini, saya akan membahas pola Composition API yang benar untuk project nyata, berdasarkan praktik yang umum dipakai di aplikasi production, bukan sekadar contoh dokumentasi.

Cocok untuk:

• developer Vue 3

• project skala menengah–besar

• aplikasi bisnis / dashboard / SaaS

---

Apa Itu Composition API (Singkat & Jelas)

Vue.js Composition API adalah cara menulis logic Vue berdasarkan fungsi dan reusability, bukan lagi dipisah berdasarkan data, methods, dan computed seperti Options API.

Tujuan utamanya:

• logic lebih reusable

• kode lebih terstruktur

• mudah diuji dan dikembangkan

---

❌ Kesalahan Umum di Project Nyata

Sebelum masuk ke pola yang benar, ini kesalahan yang sering saya temui:

```js
setup() {
  const data = ref([])
  const loading = ref(false)
  const fetchData = async () => { ... }
  const submitForm = async () => { ... }
  const deleteItem = async () => { ... }

  return { data, loading, fetchData, submitForm, deleteItem }
}
```

Masalah:

• semua logic numpuk

• tidak reusable

• sulit dibaca

• satu file bisa 500+ baris

Untuk demo oke.
Untuk production? ❌

---

✅ Prinsip Pola Composition API yang Benar

Sebelum ke kode, pegang dulu prinsip ini:

1️⃣ Pisahkan logic dari UI
2️⃣ Gunakan composable (useSomething)
3️⃣ Satu composable = satu tanggung jawab
4️⃣ Component fokus ke tampilan

---

📁 Struktur Folder yang Direkomendasikan

Struktur ini sudah terbukti rapi di project nyata:

```js src/ ├─ components/ ├─ pages/ ├─ composables/ │ ├─ useUser.js │ ├─ useAuth.js │ └─ useFetch.js ├─ services/ │ └─ api.js └─ stores/ └─ userStore.js ```

---

🧠 Contoh Kasus Nyata: Fetch Data User

❌ Cara Salah (logic di component)

```js
<script setup>
import { ref, onMounted } from 'vue'

const users = ref([])
const loading = ref(false)

const fetchUsers = async () => {
  loading.value = true
  const res = await fetch('/api/users')
  users.value = await res.json()
  loading.value = false
}

onMounted(fetchUsers)
</script>
```

Kelihatannya oke, tapi:

• tidak reusable

• susah dites

• logic bercampur UI

---

✅ Cara Benar: Pakai Composable

1️⃣ Buat composable useUser.js

```js
// composables/useUser.js
import { ref } from 'vue'

export function useUser() {
  const users = ref([])
  const loading = ref(false)
  const error = ref(null)

  const fetchUsers = async () => {
    loading.value = true
    try {
      const res = await fetch('/api/users')
      users.value = await res.json()
    } catch (err) {
      error.value = err
    } finally {
      loading.value = false
    }
  }

  return {
    users,
    loading,
    error,
    fetchUsers
  }
}
```

---

2️⃣ Gunakan di component

```js
<script setup>
import { onMounted } from 'vue'
import { useUser } from '@/composables/useUser'

const { users, loading, fetchUsers } = useUser()

onMounted(fetchUsers)
</script>
```

Hasilnya:
✅ component bersih
✅ logic reusable
✅ mudah dipelihara

---

🔁 Reusable Logic = Kunci Project Besar

Composable bisa dipakai di banyak component:

const { users } = useUser()

Kalau besok:

• ganti API

• tambah auth

• tambah cache

➡️ ubah di satu tempat saja.

---

🧩 Pola Naming yang Disarankan

Gunakan konvensi:

```js

useAuth()
useUser()
useProduct()
usePagination()
useForm()
```

Kenapa?

• mudah dikenali

• konsisten

• readable untuk tim

---

🏪 Kapan Pakai Pinia?

Kalau data:

• dipakai banyak halaman

• bersifat global

• terkait state aplikasi

Gunakan Pinia, bukan composable biasa.

Contoh:

• user login

• role & permission

• theme

• cart

Composable 👉 logic
Pinia 👉 state global

---

⚠️ Anti Pattern yang Harus Dihindari

❌ satu composable isinya semua hal
❌ composable berisi UI logic
❌ terlalu banyak watch()
❌ tidak handle error
❌ tidak pisah API service

---

🔍 Tips Production yang Sering Terlewat

• pisahkan API call ke services/

• selalu handle error

• jangan fetch di banyak tempat

• buat composable kecil & fokus

• dokumentasikan composable penting

---

🎯 Kesimpulan

Composition API bukan soal sintaks baru, tapi soal cara berpikir yang benar.

Untuk project nyata:

• component = UI

• composable = logic

• store = state global

Dengan pola ini:
✅ kode rapi
✅ scalable
✅ mudah dikerjakan tim
✅ siap production

Kalau kamu masih menaruh semua logic di setup(), sekarang waktu yang tepat untuk refactor.

---

❓ FAQ

Q: Apakah Composition API wajib?
Tidak wajib, tapi sangat disarankan untuk project besar.

Q: Bisa dicampur dengan Options API?
Bisa, tapi sebaiknya konsisten.

Q: Composable vs Store, pilih mana?
Logic → composable
State global → store (Pinia)