Vue 3 Composition API vs Options API — büyük bileşen kütüphaneleri için seçim

Neden bu seçim büyük yönetici (admin) bileşen kütüphanelerinde önemli?

Bir admin uygulamasındaki büyük bir bileşen kütüphanesi birkaç düğmesi olan bir pazarlama sitesi değildir. Ekranlar arasında tekrar eden onlarca (ya da yüzlerce) yapı taşıdır: sıralama ve toplu işlemler içeren veri tabloları, filtre panelleri, doğrulama kurallarıyla formlar, çekmeceler ve modallar, onay akışları ve tarih seçiciler ya da izin korumaları gibi küçük yardımcılar.

Bu kalıplar her yerde göründüğü için ekipler genellikle teslim tarihlerini yakalamak için kodu kopyalar ve ufak değişiklikler yapar. Bir tabloda özel bir filtre çubuğu olur, başka bir yerde biraz farklı bir versiyon, ve kısa sürede beş “neredeyse aynı” versiyonunuz olur. İşte o zaman Composition API vs Options API sorusu kişisel tercih olmaktan çıkar ve tüm kütüphanenin sağlığını etkilemeye başlar.

İlk kırılan genellikle tutarlılıktır. UI yine çalışır, ama davranış kayar: bir yerde Escape tuşuyla modal kapanırken başka yerde kapanmaz; aynı form alanı bir sayfada blur'da doğrularken diğerinde submit'te doğrular. Ardından hız düşer çünkü her değişiklik neredeyse kopyalar arasında arama gerektirir. Son olarak güven azalır: insanlar refactor'lardan kaçınır çünkü neyin etkileneceğini tahmin edemezler.

Paylaşılan bir kütüphanede en çok önem taşıyan üç pratik karar:

• Kod yeniden kullanımı: paylaşılan mantığı karışık bağımlılıklar olmadan nasıl paketlersiniz.
• Test: UI ağırlıklı kırılgan testler olmadan davranışı doğrulamak ne kadar kolay.
• İşe alıştırma (onboarding): yeni bir katkıcı bir bileşeni ne kadar hızlı okuyup güvenle değiştirebilir.

Basit bir örnek: admin'inizde 20 liste sayfası var ve ürün ekibi yeni bir “Kaydedilmiş filtreler” özelliği istiyor. Eğer tablo, filtreler ve URL eşitleme mantığı dağınık ve tutarsızsa, ya yavaş gönderirsiniz ya da hatalı gönderirsiniz. Seçtiğiniz API tarzı, bu mantığın tek bir yeniden kullanılabilir yerde mi kaldığını, her ekrana ne kadar net bağlandığını ve yeni birinin onu ne kadar kolay genişletebileceğini şekillendirir.

Vue 3 admin uygulamaları (AppMaster gibi platformlarda Vue 3 kullanan ekipler dahil) inşa ediyorsanız, bu seçimi erken yapmak sonraki aylarda bakım için aylar kazandırabilir.

Options ve Composition günlük koddaki farkı nasıl gösterir?

Farkı hissetmenin en hızlı yolu büyük bir admin bileşenini açıp şu soruyu sormaktır: “Bu özellik için davranışı nereden değiştiririm?” Bir bileşen kütüphanesinde bu soru her gün karşınıza çıkar.

Options API ile kod tipe göre gruplanır: durum için data, eylemler için methods, türetilmiş değerler için computed ve yan etkiler için watch. Bu yapı bileşen küçükken taraması kolaydır. Büyük bir tablo veya form bileşeninde tek bir özelliğe ait mantık (örneğin toplu işlemler veya alan doğrulaması) genellikle birkaç blok arasına dağılır. Düzeni koruyabilirsiniz, ama “dosyada zıplama” iş akışını önlemek için disiplin ve tutarlı isimlendirme gerekir.

Composition API ile kod genellikle özellik bazında gruplanır. İlgili durum, türetilmiş değerler, yan etkiler ve yardımcılar yan yana tanımlanır ve tekrar eden mantığı composable'lara çekebilirsiniz. Admin tarzı bir kütüphanede bu, insanların düşündüğü şekille sıkça örtüşür: “filtrelemeye dair her şey burada”, “satır seçimine dair her şey burada”. Ayrıca usePagination gibi composable'ların birden çok tabloda yeniden kullanılmasını sağlayarak çoğalmayı azaltabilir.

Günlük kullanımda büyük farklardan biri bağımlılıkların nasıl göründüğüdür.

• Options API daha örtük hissedebilir: bir method this.user, this.filters ve this.loading'e dayanıyor olabilir ve bunu yalnızca methodun içini okuyarak anlarsınız.
• Composition API daha açık olma eğilimindedir: bir fonksiyon filters ve loading üzerine kapanıyorsa, bu değişkenleri yakınlarda görürsünüz ve gerektiğinde yardımcı fonksiyonlara geçirirsiniz.

Takası şu: Composition API her şeyi setup() içine dökerseniz gürültülü olabilir.

Pratik bir başparmak kuralı:

• Bileşenler çoğunlukla sunumsalsa ve hafif mantık içeriyorsa Options API seçin.
• Bileşenlerin birden çok özelliği varsa ve kütüphane çapında kurallar paylaşılıyorsa Composition API seçin.
• Composition API seçerseniz, kodu özellik bazında gruplayan basit bir düzen üzerinde anlaşın ("önce tüm ref'ler" değil).
• Options API seçerseniz, isimlendirmeyi zorunlu kılın ve ilgili mantığı kısa yorumlarla ve tutarlı method isimleriyle bir arada tutun.

Her ikisi de çalışabilir. Anahtar nokta, bir sonraki değişikliğin sezgisel hissettireceği organizasyon stilini seçmektir; zekice değil, açık olmalı.

Kod yeniden kullanımı: ne temiz ölçeklenir, ne dağılır

Admin tarzı uygulamalarda yeniden kullanım lüks değil; onlarca ekranda aynı davranışları tekrar edersiniz ve küçük tutarsızlıklar hatalara ve destek bileti yığılmasına dönüşür.

Çoğu yeniden kullanım ihtiyacı birkaç tekrar eden kategoride toplanır: backend ile uyumlu sıralama/filtreleme/sayfalandırma, form doğrulama ve hata eşlemesi, izin kontrolleri ve UI kısıtlama, sorgu senkronizasyonu (URL paramları, kaydedilmiş görünümler, varsayılan filtreler) ve tablo seçim kuralları ile toplu işlemler.

Options API yeniden kullanımı: güçlü ama karmaşıklığı saklaması kolay

Options API ile yeniden kullanım genelde mixin'lerle, extends ile veya plugin'lerle başlar.

Mixin'ler hızlıdır ama ölçeklendikçe kötüleşir çünkü bir methodun veya computed değerinin nereden geldiğini gizlerler. İki mixin aynı method adında çakışma yapabilir ve artık bileşen dosyasında görünmeyen davranışlarla uğraşırsınız.

extends mixin'lerden daha temiz gelebilir ama yine kalıtım bulmacaları yaratır; bir bileşenin gerçekten ne yaptığını anlamak için birden çok dosya okumanız gerekir. Plugin'ler uygulama seviyesi endişeler (global directive'ler, paylaşılan servisler) için iyidir, ama ekranlara göre değişen iş kuralları için iyi bir yer değildir.

Karışıklık genelde yeniden kullanım örtük hale geldiğinde gelir. Yeni katkıcılar “bu veri nereden geliyor?” sorusunu kod tabanında aramadan cevaplayamazlar.

Composition API yeniden kullanımı: composable'larla şeffaflık

Composition API ile yeniden kullanım genelde composable'lar etrafında kurulur: ref'ler, computed değerler ve handler'lar döndüren küçük fonksiyonlar. Büyük kazanım, yeniden kullanımın bileşenin üst kısmına görünür şekilde gelmesidir ve gizli bileşen bağlamına güvenmek yerine parametre geçebilirsiniz.

Örneğin usePagination composable'ı varsayılanları alabilir ve tutarlı bir şekil ile değişiklikleri yayabilir; usePermissions ise mevcut rolü ve bir özellik adını parametre olarak alabilir. Bu noktada seçim söz diziminden çok, kütüphanenizin açık bağlantılara mı yoksa örtük kalıtıma mı öncelik verdiği meselesi olur.

Yeniden kullanımı öngörülebilir tutmak için her tekrar kullanılabilir birimi küçük bir API gibi ele alın: net bir ad, giriş ve çıkış tanımı ve tek bir sorumluluk. Bir composable sayfalandırma, önbellekleme, izinler ve bildirimleri aynı anda yönetmeye başlarsa, onu bölün. Bir parçayı daha sonra bozmadan değiştirmek çok daha kolaydır.

Yeniden kullanılabilir form ve tablo bileşenleri acısız nasıl inşa edilir

Admin tarzı uygulamalarda formlar ve tablolar, bir bileşen kütüphanesinin ya değerini gösterir ya da bir labirente döner. Her iki API de çalışabilir. Fark, kirli durum, hata eşleme ve gönderim akışı gibi paylaşılan davranışları paketleme şeklinizdedir.

Paylaşılan form mantığı için Options API genelde sizi mixin'lere veya paylaşılan yardımcı modüllere yönlendirir. Mixin'ler ilk başta kullanışlı görünür, ama sonra temel sorulara cevap bulmak zorlaşır: “Bu alan hatası nereden geliyor?” ya da “Neden gönderim devre dışı?” gibi.

Composition API bu tür tekrar kullanımı daha görünür yapar çünkü mantığı useDirtyState, useFormErrors, useSubmitFlow gibi composable'lara taşıyabilir ve bir form bileşeninin tam olarak hangi parçaları çektiğini görebilirsiniz. Büyük bir kütüphanede bu açıklık genellikle birkaç satır tasarrufundan daha önemlidir.

Bileşen API'lerinizi kararlı tutmanın pratik bir yolu, genel yüzeyi bir sözleşme gibi ele almaktır: props, emits ve slot'lar nadiren değişmeli, iç mantık değişse bile. Bu sözleşme her iki stil için de benzer görünür; ancak Composition API refactor'ları daha güvenli hale getirme eğilimindedir çünkü bir composable'ı bir seferde değiştirebilirsiniz ve template API'ye dokunmak zorunda kalmazsınız.

Kütüphane büyüdükçe genelde akılda kalan desenler:

• Tek işi iyi yapan base bileşenler oluşturun (BaseInput, BaseSelect, BaseTable), sonra bunları özellik bileşenlerinde birleştirin.
• Yerleşim esnekliği için çok sayıda prop eklemek yerine slot'ları tercih edin (actions alanı, boş durumlar, hücre render'ları).
• Olayları erken normalize edin (örneğin update:modelValue, submit, rowClick) ki uygulamalar iç detaylara bağlanmasın.
• Doğrulama ve formatlamayı input'lara yakın tutun, ama iş kurallarını dışarıda (composable'larda veya parent container'larda) tutun.

Aşırı soyutlama yaygın tuzaktır. Her alan tipini, her doğrulama kuralını ve her yerleşim seçeneğini yöneten “süper form” genelde kullanımdan daha zor hale gelir. İyi bir kural: bir base bileşenin tüm ekiplerin ihtiyaçlarını karşılamak için bir avuçtan fazla prop'a ihtiyacı varsa, muhtemelen iki bileşendir.

Bazen çoğaltma doğru karardır. Eğer yalnızca bir ekran çok özel bir tablo başlığına ihtiyaç duyuyorsa, küçük bir parçayı kopyalamak ve onu yerel tutmak daha iyidir. Zeki soyutlamalar uzun bakım kuyrukları getirir, özellikle yeni katkıcılar katıldığında “normal” bileşenlerle framework içindeki bir framework arasındaki farkı anlamaya çalışırken.

Composition veya Options arasında karar verirken büyük form ve tablo kütüphanesi için veri akışının okunabilirliğini ön planda tutun. Yeniden kullanım harika, ama kullanıcı eyleminden emit edilen olaya giden yolu sakladığında işe yaramaz.

Test etme etkisi: neyin doğrulanması kolaylaşır

Bir bileşen kütüphanesinde testler genelde üç kategoriye ayrılır: saf mantık (formatlama, doğrulama, filtreleme), render (verilen bir durum için ne görünüyor) ve etkileşimler (tıklamalar, input, klavye, emit'ler). Seçtiğiniz API stili ilk kategoriyi DOM olmadan ne sıklıkla test edebileceğinizi değiştirir.

Options API testleri genelde “bileşeni mount et, instance durumunu değiştir, DOM'u assert et” şeklinde olur. Bu işe yarar, ama mantık methods, computed, watch ve lifecycle hook'larla karıştığı için daha büyük testlere teşvik edebilir. Bir şey başarısız olduğunda da bunun watcher zamanlaması mı, lifecycle yan etkisi mi yoksa mantık mı olduğunu ayırt etmek zaman alır.

Options API genelde şu durumlar için uygundur:

• Lifecycle sırasına dayalı kullanıcı akışları (mount'ta fetch, route değişiminde reset)
• Watcher-driven davranışlar (otomatik kaydetme, sorgu senkronizasyonu)
• Component method'larından event emit etme (save(), reset(), applyFilter())

Composition API dengeyi kaydırır. Mantığı composable'lara taşırsanız, bu mantığı saf fonksiyonlar gibi birim testleriyle doğrulayabilirsiniz; küçük girdiler ve net çıktılarla. Bu, mount ve tık testlerine duyulan ihtiyacı azaltır ve hataları daha lokal yapar. Ayrıca bağımlılıkları kontrol etmek kolaylaşır: global bir şeyi mocklamak yerine fetch fonksiyonunu, tarih formatlayıcıyı veya izin kontrolörünü composable'a parametre olarak geçebilirsiniz.

Somut örnek: sıralama, sayfalandırma ve seçili satırlar içeren yeniden kullanılabilir bir AdminTable. Composition API ile seçim mantığı useRowSelection() içinde yaşayabilir ve tabloyu render etmeden (toggle, clear, select all, sayfalar arasında koruma) test edilebilir. Sonra bileşen testleri butonların, checkbox'ların ve emit'lerin template'e düzgün bağlandığını doğrulamakla sınırlı kalır.

Testleri küçük ve okunabilir tutmak için (stil fark etmeksizin) mantık ile UI arasında net bir dikiş oluşturun:

• İş kurallarını saf fonksiyonlara veya composable'lara koyun, watcher'ların içine sıkıştırmayın.
• Yan etkileri (fetch, storage, timer) enjekte edilen bağımlılıkların arkasına saklayın.
• Her bileşen için birkaç odaklı entegrasyon testi tercih edin, tek bir devasa “her şey” testi değil.
• Kütüphane genelinde durum ve event isimlendirmesini tutarlı kullanın (test kurulumunu azaltır).
• Gizli bağlılıklardan kaçının (örneğin method A'nın watcher B'nin çalışmasına dayanması).

Test kararlılığını artıracak bir stil kararı istiyorsanız, lifecycle-driven davranışları azaltıp daha izole mantık birimlerine yönelin.

Yeni katkıcıları işe alıştırma: insanların ne kadar hızlı üretken oluyor?

Büyük bir admin bileşen kütüphanesinde onboarding Vue öğretmekten çok, insanlara nesneleri bulmayı, aynı konvansiyonları takip etmeyi ve güvenle değişiklik yapmayı öğretmektir. Yavaşlamaların çoğu üç boşluktan gelir: navigasyon (mantık nerede?), konvansiyonlar (burada nasıl yapıyoruz?) ve güven (bunu beş ekranı bozmadan nasıl değiştiririm?).

Options API ile yeni başlayanlar genelde ilk gün daha hızlı ilerler çünkü yapı tanıdık: props, data, computed, methods, watchers. Takası, gerçek davranışın genelde dağınık olmasıdır. “Sunucu tarafı filtreleme” gibi bir özellik watcher, computed ve iki method arasında, artı bir mixin içinde bölünebilir. İnsanlar her bloğu okuyabilir ama hikayeyi birleştirmek zaman alır.

Composition API ile onboarding avantajı, ilgili mantığın bir arada durabilmesidir: durum, yan etkiler ve yardımcılar aynı yerde. Maliyeti ise composable okuryazarlığıdır. Yeni katkıcıların useTableState() gibi kalıpları ve reaktif değerlerin birden çok composable arasında nasıl aktığını anlaması gerekir. Sınırlar net değilse, dosyalar arasında haritasız dolaşıyormuş gibi hissedilebilir.

Hangi stil olursa olsun birkaç konvansiyon çoğu soruyu ortadan kaldırır:

• Tahmin edilebilir bir yapı kullanın: components/, composables/, types/, tests/.
• Bir isimlendirme deseni seçin ve ona sadık kalın (örneğin: useX, XTable, XForm).
• Kısa docblock'lar ekleyin: bileşenin ne yaptığı, ana props ve ana event'ler.
• Bir “escape hatch” kuralı tanımlayın (ne zaman yeni bir composable veya helper eklenebilir?).
• Tercih edilen deseni gösteren küçük bir “golden” bileşen tutun.

Örnek: ekibiniz Vue 3 admin paneli üretiyor ve sonra özelleştiriyorsa (örneğin AppMaster ile üretilen bir web uygulaması), onboarding tablo davranışını (sıralama, filtreler, sayfalandırma) ayarlamak için tek bir açık yer olduğunda çok daha iyi olur. Bu netlik seçtiğiniz API'den daha önemlidir.

Adım adım: bir stil seçmek ve güvenli tanıtmak

Büyük bir admin UI kütüphanesi için sorunu çözmenin en güvenli yolu tek bir iyi tanımlanmış özelliği pilot olarak ele almak, komple bir yeniden yazım yapmamak.

Davranışı yüksek yeniden kullanım potansiyeli olan tek bir modül seçin (örneğin tablo filtreleme veya form doğrulaması). Koda dokunmadan önce şu soruları yazıya dökün: girdiler (props, query paramları, kullanıcı eylemleri), çıktılar (event'ler, emit'ler, URL değişiklikleri) ve uç durumlar (boş durum, reset, sunucu hataları).

Sonra sınırları belirleyin. Render, DOM olayları ve erişilebilirlik detaylarının bileşen içinde kalması gerekir; parsing filtreler, debounce, API parametreleri oluşturma ve varsayılan durum gibi iş mantıkları paylaşılan koda taşınabilir. Burada ekipler genellikle hata yapar: UI kararlarını paylaşılan koda taşırsanız, tekrar kullanılabilirliği zorlaştırırsınız.

Pratik bir yayılma planı:

• Deseni açıkça gösteren ve birden çok ekranda kullanılan bir bileşen seçin.
• Bir paylaşılan birim (composable veya saf helper) çıkarın; API'si küçük ve açık olsun.
• Önce o birim için gerçek admin senaryolarına dayalı odaklı bir test yazın.
• Seçilen bileşeni yeni birimle baştan sona refactor edin.
• Aynı deseni bir bileşende daha uygulayarak ölçeklendiğini doğrulayın.

Paylaşılan API'yi sıkıcı ve açık tutun. Örneğin useTableFilters() composable'ı başlangıç filtrelerini alıp filters, apply(), reset() ve toRequestParams() gibi fonksiyonlar sunabilir. Global durumdan “sihirli” şekilde okuyan kodlardan kaçının, unless uygulamanızda bunun halihazırda sağlam bir kuralı varsa.

Pilot sonrası kısa bir dahili yönerge yayınlayın ve katkıcıların kopyalayabileceği bir örnek verin. Bir somut kural uzun belgelerden daha etkilidir: “Tüm tablo filtreleme mantığı bir composable içinde; bileşenler yalnızca UI kontrollerini bağlar ve apply() çağırır.”

Deseni genişletmeden önce şu basit “done” tanımını kullanın:

• Yeni kod iki farklı bileşende aynı şekilde okunuyor.
• Testler paylaşılan mantığı UI'ı mount etmeden kapsıyor.
• Yeni bir katkıcı filtre kuralını ilgili olmayan dosyalara dokunmadan değiştirebiliyor.

AppMaster gibi no-code araçlarla admin portalları da üretiyorsanız, aynı pilot zihniyetini orada da kullanabilirsiniz: bir iş akışını seçin, davranışları tanımlayın, sonra deseni ürüne ölçeklendirin.

Büyük kütüphanelerde sık yapılan hatalar ve tuzaklar

Büyük bir bileşen kütüphanesindeki en büyük problemler nadiren sözdizimiyle ilgilidir. Küçük yerel kararların yığılmasıyla ortaya çıkar ve yeniden kullanım, test ve bakım zorlaşır.

Yaygın bir tuzak, desenleri rastgele karıştırmaktır. Kütüphanenin yarısı Options API, diğer yarısı Composition API ise ve bunun için bir kural yoksa, her yeni bileşen bir stil tartışması olur. Ayrıca aynı problemlere farklı şekillerde çözümler çoğalır (formlar, tablolar, izinler) ama farklı formlarda yazılmış olur. Her iki stile de izin veriyorsanız, açık bir politika yazın: yeni bileşenler tek bir stile göre yazılır, legacy yalnızca gerektiğinde dokunulur ve paylaşılan mantık tek bir yerde tutulur.

Bir diğer tuzak “god composable” dir. Bu genellikle yardımcı useAdminPage() veya useTable() ile başlar ve yavaş yavaş routing, fetch, önbellekleme, seçim, dialog'lar, toast'lar ve izinler gibi her şeyi içine çeker. Test edilmesi zorlaşır çünkü tek bir çağrı birçok yan etki tetikler. Yeniden kullanımı zorlaşır çünkü her ekran yalnızca %30 kullanırken karmaşıklığın %100'ünü taşır.

Watcher'lar başka bir sıkıntı kaynağıdır. Bir şeyin senkron dışında kaldığını hissettiğinizde watcher eklemek kolaydır, ama zamanlama hataları daha sonra ortaya çıkar (özellikle async veri ve debounce edilmiş input'larla). “Bazen seçimimi temizliyor” gibi raporlar genelde yeniden üretmesi zor hatalara dönüşür.

Kütüphanenin işinin çıkma yolunda olduğunu gösteren kırmızı bayraklar:

• Bir bileşen yalnızca props ve event'lerin belirli bir sırasıyla çalışıyor.
• Bir composable global durumu açıkça okuyup yazıyor ama bunu belli etmiyor.
• Birden fazla watcher aynı durumu güncelliyor.
• Refactor'lar tüketici ekranları küçük şekillerde kırmaya devam ediyor.
• Katkıcılar “o dosyaya” dokunmaktan kaçınıyor çünkü riskli.

Son tuzak API'leri refactor sırasında kırmaktır. Admin uygulamalarında tablolar, filtreler ve form alanları hızla yayılır. Bir prop'un adını değiştirmek, bir emit'i değiştirmek veya slot davranışını kırpmak düzinelerce ekranı sessizce bozabilir.

Daha güvenli yaklaşım bileşen API'lerini sözleşme gibi ele almaktır: silmek yerine deprecate edin, uyumluluk shim'leri bir süre tutun ve tüketicilerin kullandığı şekilde bileşeni mount eden basit kullanım testleri ekleyin. AppMaster ile üretilen Vue 3 arayüzleri gibi durumlarda, tutarlı bileşen kontratları ekranların yeniden kullanılmasını ve değişikliklerin öngörülebilir olmasını kolaylaştırır.

Bir desene karar vermeden önce hızlı kontroller

Composition API, Options API veya karışık bir yaklaşımı seçmeden önce kütüphanenizden gerçek bileşenlerle birkaç hızlı kontrol yapın. Amaç basit: mantığı hızlı bulunabilir, güvenli yeniden kullanılabilir ve admin'lerin güvendiği parçalar test edilebilir olsun.

1) Mantığı hızlıca bulabiliyor mu?

Filtreler + tablo + izinler + toplu işlemler içeren tipik bir admin bileşenini açın. Yeni gelen biriymiş gibi davranın.

İyi işareti, katkıcının “filtre mantığı nerede?” veya “butonun ne zaman devre dışı olduğunu kim belirliyor?” sorularına 2 dakika içinde cevap verebilmesidir. Options API'de bu genelde computed, methods ve watcher'ların net bölünmesiyle olur. Composition API'de ise setup()'ın küçük isimlendirilmiş bloklara (veya composable'lara) bölünmesi ve tek bir devasa fonksiyondan kaçınılması beklenir.

2) Paylaşılan yardımcılar fonksiyon gibi mi davranıyor, sihir gibi mi?

Hangi deseni seçerseniz seçin, paylaşılan kodun net giriş ve çıkışları olmalı, yan etkileri minimum olmalı. Bir helper global duruma el atıyorsa, geçirilen nesneleri değiştiriyorsa ya da ağ çağrısı tetikliyorsa, yeniden kullanım risklidir.

Hızlı kontrol:

• Bir composable ya da helper imzasını okuyunca ne döndürdüğünü tahmin edebiliyor musunuz?
• İki bileşende ekstra gizli kurulum olmadan kullanabiliyor musunuz?
• Testlerde durumunu temiz bir şekilde sıfırlayabiliyor musunuz?

3) Testler admin davranışlarına odaklanıyor mu?

Admin tarzı uygulamalar tutarlı biçimde şu hatalarla başarısız olur: filtreler yanlış uygulanır, izinler aksiyonu sızdırır, formlar tutarsız doğrulanır ve tablo durumu düzenlemelerden sonra bozulur.

İç uygulama detaylarını (watcher vs ref) test etmek yerine davranışa dayalı testler yazın: “rol X verildiğinde Y aksiyon gizlenir”, “kaydetme hata gösterir ve kullanıcı girdisini korur”, “filtre değişince sorgu güncellenir ve boş durum mesajı değişir”. Bu testler refactor sırasında bile stabil kalır.

4) Async durum için standartınız var mı?

Büyük kütüphaneler küçük async akışlarla dolar: seçenekleri yükle, alanları doğrula, tablo satırlarını çek, başarısız olunca yeniden dene. Her bileşen kendi loading/error yapısını icat ederse onboarding ve hata ayıklama yavaşlar.

Async durum için tek bir şekil seçin (loading, error, retries, cancellation). Composition API genelde useAsyncX() gibi reusable bir composable önerirken, Options API data() içinde ortak durum + shared method'larla standardize edebilir. Önemli olan tüm kütüphane boyunca tutarlı olmasıdır.

5) Bileşen public API'leri anlaşılır ve stabil mi?

Bileşenleri ürün gibi düşünün. Props'ları, emit'leri ve slot'ları sözleşmedir. O sözleşme sık değişiyorsa her admin ekran kırılgan hale gelir.

Niçin kullanıldığını (mekaniği değil) açıklayan yorumlar arayın: props ne demek, hangi event'ler garanti edilir ve ne dahili sayılır. AppMaster ile inşa edilen dahili araçlarda da bu zihniyet fayda sağlar: stabil yapı taşları gelecekteki ekranları daha hızlı teslim etmeyi sağlar.

Örnek senaryo ve ekibiniz için sonraki adımlar

Yeniden inşa ettiğiniz bir “Kullanıcılar” sayfasını hayal edin: bir filtre çubuğu (durum, rol, oluşturulma tarihi), seçilebilir satırlar içeren bir tablo, toplu işlemler (devre dışı bırak, sil, dışa aktar) ve rol bazlı erişim (sadece adminler toplu silme yapabilir, yöneticiler rolleri düzenleyebilir).

Composition API veya Options API ile UI aynı görünebilir, ama kod genellikle farklı organize olur.

Options API'de genelde filtreler ve seçim için data, türetilmiş durum için computed, fetch ve toplu işlemler için methods içeren büyük bir bileşende toplanma olur. Yeniden kullanım genelde mixin'ler veya paylaşılan helper modüller olarak görünür. Bu tanıdık ama ilgili mantık dağılmaya meyillidir (fetch methods içinde, sorgu senkronizasyonu watcher'larda, izinler computed içinde).

Composition API'de sayfayı tipik olarak sorgu ve filtreler için bir composable, tablo seçim ve toplu işlemler için bir composable ve izinler için bir composable olarak ayırırsınız. Sayfa bileşeni bu parçaları bir araya getirir ve her bir konuda mantık bir yerde kalır. Maliyet, katkıcıların net isimlendirme ve klasör konvansiyonlarını öğrenmesi gerektiğidir ki setup() içindeki sihir hissi olmasın.

Yeniden kullanım genelde admin kütüphanelerinde şu alanlarda doğal olarak ortaya çıkar: URL ile eşlenen filtreler, sunucu tarafı tablo kalıpları (sayfalandırma, sıralama, select-all, toplu işlem korumaları), izin kontrolleri ve her sayfada tutarlı kalan boş/yükleniyor durumları.

Çoğu ekip için işe yarayan bir sonraki adımlar planı:

1. Yeni kod için bir varsayılan stil seçin ve istisnalara yazılı gerekçe şartı koyun.
2. Konvansiyonları tanımlayın: composable'ların nerede duracağı, nasıl adlandırılacağı, neler içerebileceği ve ne döndürmesi gerektiği.
3. Küçük bir referans sayfası (örneğin bu Kullanıcılar sayfası) oluşturun ve tercih edilen desen için altın standart yapın.
4. Önce yeniden kullanılabilir parçalara test yazın (filtreler, izinler, toplu işlemler), görsel düzen yerine.
5. Bazı admin ekranlarında derin özelleştirme hızından çok hız önemliyse, o ekranları AppMaster gibi no-code araçlarla üretmeyi düşünün; el yazısı kütüphanenizi gerçekten benzersiz olan kısımlara odaklayın.

Zaten AppMaster ile inşa ediyorsanız, üretilen ve elle yazılan parçalar arasında aynı zihniyeti korumak faydalıdır: stabil bileşen kontratları ve küçük, açık paketlenmiş mantık birimleri. Değerlendiren ekipler için AppMaster (appmaster.io) arka uç, web ve mobil dahil tam uygulamalar üretecek şekilde tasarlanmıştır ve Vue 3 web UI'ınızı ihtiyaç duyduğunuz yerde standardize etmenize izin verir.

Haftanın bir işi: Kullanıcılar sayfasını şablon olarak alın ve kod incelemelerinde uygulayın. Bir açık örnek uzun bir stil rehberinden çok daha fayda sağlar.