# Vue 3 Composition API: neden ve ne zaman

> Vue 3 ile gelen Composition API'nin Options API'ye göre ne getirdiğini, ne zaman tercih edilmesi gerektiğini somut örneklerle tartışıyorum.

- Yayın: 2020-07-05
- Kategori: Arayüz
- Etiketler: Vue.js
- Okuma süresi: 3 dk okuma
- Kaynak: https://www.muhammetsafak.com.tr/blog/vue-3-composition-api-neden-ve-ne-zaman/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
Vue 3 beta sürecini uzaktan takip ediyordum. Composition API duyurusunu gördüğümde ilk tepkim skeptikti: [React Hooks](/blog/react-hooks-ile-bilesen-yazmanin-degisen-yuzu)'un Vue versiyonu mu? Bu değişikliği neden ihtiyaç duydular?

Soruyu gerçek kodla yanıtlamak daha sağlıklı oldu. Birkaç hafta önce bir proje için Vue 3 beta kullandım. Hem yeni API'yi hem de eski Options API'yi aynı projede çalıştırdım. Farkı gördükten sonra "neden" sorusunun cevabı daha net geldi.

## Options API'nin neden sınırlandığı

Options API, Vue 2'nin tanıdık yüzü: `data`, `computed`, `methods`, `watch` — her şeyin bir kategorisi var. Bu yapı küçük bileşenler için sezgisel. Bileşen büyüdüğünde bir sorun ortaya çıkıyor: tek bir özelliğe ait mantık dört farklı bloğa dağılıyor.

Bir kullanıcı arama özelliği düşünün. Arama sorgusu `data`'da, filtreleme mantığı `computed`'da, debounce için timer `data`'da, sıfırlama `methods`'da. Bu dört parça aynı özelliğe ait; ama kodda dört farklı yerde.

```javascript
// Options API — arama mantığı dört yere dağılmış
export default {
  data() {
    return {
      query: '',
      timer: null,
      results: [],
    };
  },
  computed: {
    filteredResults() {
      return this.results.filter(r => r.active);
    }
  },
  methods: {
    onInput(value) {
      clearTimeout(this.timer);
      this.timer = setTimeout(() => this.search(value), 300);
    },
    async search(query) {
      const { data } = await axios.get('/api/search', { params: { q: query } });
      this.results = data;
    },
    reset() {
      this.query = '';
      this.results = [];
    }
  }
};
```

## Composition API ile aynı mantık

Composition API ile aynı mantığı tek bir `setup` fonksiyonunda — ya da ayrılabilen bir composable içinde — tutabiliyorsunuz:

```javascript
// useSearch.js — ayrı bir composable olarak
import { ref, computed } from 'vue';
import axios from 'axios';

export function useSearch() {
  const query = ref('');
  const results = ref([]);
  let timer = null;

  const filteredResults = computed(() =>
    results.value.filter(r => r.active)
  );

  function onInput(value) {
    clearTimeout(timer);
    timer = setTimeout(() => search(value), 300);
  }

  async function search(q) {
    const { data } = await axios.get('/api/search', { params: { q } });
    results.value = data;
  }

  function reset() {
    query.value = '';
    results.value = [];
  }

  return { query, filteredResults, onInput, reset };
}
```

Bileşende kullanımı:

```javascript
import { useSearch } from '@/composables/useSearch';

export default {
  setup() {
    const { query, filteredResults, onInput, reset } = useSearch();
    return { query, filteredResults, onInput, reset };
  }
};
```

Arama mantığı artık tek bir dosyada, taşınabilir ve test edilebilir. Başka bir bileşende aynı davranış gerektiğinde `useSearch` içe alınıyor.

## Mixin ile kıyaslama

[Vue 2'de](/blog/vue-ile-bilesen-tabanli-arayuz-mimarisine-gecis) composable'ın yerini mixin tutuyordu. Ama mixin'lerin bilinen sorunları var: iki mixin aynı isimli bir özellik tanımlarsa hangisinin kazanacağı belirsiz. `this.results`'a bakıyorsunuz, bu nereden geldi? Bileşen mi tanımladı, hangi mixin mi ekleydi? Composable'da bu belirsizlik yok; `useSearch` ne döndürüyorsa adını siz belirliyorsunuz ve nereden geldiği açık.

Bu fark küçük bileşenlerde önemsiz görünüyor. Dört, beş farklı mixin karışan büyük bir bileşende bu belirsizlik gerçek bir bakım yükü oluşturuyor.

## Ne zaman Composition API, ne zaman Options API?

Bu soruyu doğrudan yanıtlayayım:

**Küçük, bağımsız bileşenler için** Options API hâlâ okunabilir. Birkaç veri alanı, birkaç metot — kategorilendirme yük değil, netlik. Özellikle Vue 2'den gelen kod tabanlarında gereksiz yere Composition API'ye geçmek kodu daha karmaşık yapıyor.

**Yeniden kullanılabilir mantık için** Composition API net kazanç. Vue 2'de mixin'lerle yapılan şey composable'larla çok daha temiz oluyor; isim çakışması yok, nereden geldiği belirsiz özellik yok.

**Büyük bileşenler için** Composition API mantığı özelliğe göre gruplamayı sağlıyor. Bu büyük bir fark.

TypeScript uyumluluğu da önemli bir neden. Composition API TypeScript ile çok daha iyi çalışıyor; type inference Options API'de sınırlı.

## Vue 2'den geçiş

Vue 3 beta sürümünde Options API kaldırılmıyor; iki API birlikte kullanılabiliyor. Mevcut Vue 2 projelerini aniden geçirmek zorunda değilsiniz. Yeni bileşenler için Composition API, eskiler için Options API geçici olarak mantıklı bir strateji.

---

Composition API'yi "React'ın etkisiyle eklenen bir özellik" olarak küçümsemek haksız. Gerçek bir problemi — mantığın bileşen boyunca dağılması — somut biçimde çözüyor. Vue 2 alışkanlığı olan birinin bu API'yi benimsemesi birkaç gün alıyor; uzun vadede o süre kısa bileşenlerden çıktıkça karşılığını buluyor.