Vue 3 yönetim panellerinde durum yönetimi: Pinia mı yoksa yerel durum mu

Yönetim panellerinde durumu zorlaştıran ne?\n\nYönetim panelleri, aynı ekrana birçok hareketli parçayı sığdırdıkları için “durum ağır” hissi verir. Bir tablo sadece veri değildir. Aynı zamanda sıralama, filtreler, sayfalama, seçili satırlar ve kullanıcıların güvendiği “ne oldu şimdi?” bağlamını da içerir. Uzun formlar, role dayalı izinler ve UI’nin neye izin vereceğini değiştiren eylemler eklenince küçük durum kararları önem kazanmaya başlar.\n\nZorluk değerleri depolamak değil. Aynı gerçeğe birkaç bileşenin ihtiyaç duyduğu durumda davranışı öngörülebilir tutmaktır. Bir filtre etiketi “Aktif” diyorsa, tablo, URL ve dışa aktarma eylemi aynı fikirde olmalı. Bir kullanıcı bir kaydı düzenleyip ayrılırsa uygulama sessizce çalışını kaybetmemeli. İki sekme açarlarsa, bir sekme diğerini ezmemeli.\n\nVue 3’te genellikle durumu üç yerden birinde tutmayı seçersiniz:\n\n- Yerel bileşen durumu: tek bir bileşenin sahip olduğu ve unmount olduğunda sıfırlanması güvenli olan durum.\n- provide/inject: prop zinciri olmadan bir sayfa veya özellik alanı kapsamında paylaşılan durum.\n- Pinia: navigasyonu aşması, rotalar arası yeniden kullanılabilmesi ve debug için kolay kalması gereken paylaşılan durum.\n\nDüşünmek için faydalı bir yol: her durum parçası için nerede olmalı diye karar verin, böylece doğru kalır, kullanıcıyı şaşırtmaz ve spagetti hale gelmez.\n\nAşağıdaki örnekler üç yaygın yönetim problemiyle sınırlı: filtreler ve tablolar (ne kalmalı ne sıfırlanmalı), taslaklar ve kaydedilmemiş düzenlemeler (kullanıcıların güvenebileceği formlar) ve çoklu sekme düzenleme (durum çakışmalarından kaçınma).\n\n## Araç seçmeden önce durumu sınıflandırmanın basit bir yolu\n\nAraç tartışmaları, önce sahip olduğunuz durum türünü adlandırmayı bıraktığınızda kolaylaşır. Farklı durum tipleri farklı davranır ve onları karıştırmak garip hatalar yaratır.\n\nPratik bir ayrım:\n\n- UI durumu: toggle'lar, açık diyaloglar, seçili satırlar, aktif sekmeler, sıralama düzeni.\n- Sunucu durumu: API yanıtları, yükleniyor bayrakları, hatalar, son yenileme zamanı.\n- Form durumu: alan değerleri, doğrulama hataları, dirty bayrakları, kaydedilmemiş taslaklar.\n- Ekranlar arası durum: birden çok rota tarafından okunması veya değiştirilmesi gereken her şey (geçerli çalışma alanı, paylaşılan izinler).\n\nSonra kapsamı tanımlayın. Durumun bugün nerede kullanıldığını sorun, bir gün nerede kullanılabileceğini değil. Sadece bir tablo bileşeni içinde önemliyse yerel durum genellikle yeterlidir. Aynı sayfada iki kardeş bileşen buna ihtiyaç duyuyorsa gerçek sorun sayfa düzeyinde paylaşım demektir. Birden çok rota gerekiyorsa, paylaşılan uygulama durumu alanındasınız demektir.\n\nSonraki adım yaşam süresi. Bazı durumlar bir çekmece kapandığında sıfırlanmalı. Diğerleri navigasyonu aşmalı (kaydederken bir kayda girip geri döndüğünüzde filtreler gibi). Bazıları yenileme sonrası da kalmalı (kullanıcıların daha sonra döndüklerinde bulacakları uzun taslaklar). Üçünü aynı muameleye tabi tutmak filtrelerin gizemli şekilde sıfırlanması veya taslakların kaybolması ile sonuçlanır.\n\nSon olarak eşzamanlılığı kontrol edin. Yönetim panelleri kenar durumlarına çabuk düşer: kullanıcı aynı kaydı iki sekmede açar, arka planda bir yenileme bir satırı güncellerken form kirliyken, ya da iki editör kaydetmek için yarışır.\n\nÖrnek: filtreler, bir tablo ve bir düzenleme çekmecesi olan bir “Kullanıcılar” ekranı. Filtreler UI durumu ve sayfa ömrü ile ilişkilidir. Satırlar sunucu durumudur. Çekmece alanları form durumudur. Aynı kullanıcı iki sekmede düzenleniyorsa açık bir eşzamanlılık kararı gerekir: engelle, birleştir veya uyar.\n\nDurumu tür, kapsam, yaşam süresi ve eşzamanlılık ile etiketleyebildiğinizde, araç seçimi (yerel durum, provide/inject veya Pinia) genellikle çok daha net olur.\n\n## Nasıl seçilir: işe yarayan bir karar süreci\n\nİyi durum seçimleri bir alışkanlıkla başlar: bir aracı seçmeden önce durumu basitçe tanımlayın. Yönetim panelleri tablolar, filtreler, büyük formlar ve kayıtlar arasında gezinti karıştırdığı için “küçük” görünen durum bile hata manyağı olabilir.\n\n### 5 adımlı karar süreci\n\n1. Kime lazım bu durum?\n - Tek bir bileşen: yerelde tutun.\n - Bir sayfa altındaki birkaç bileşen: provide/inject düşünün.\n - Birden çok rota: Pinia'yı değerlendirin.\n\n Filtreler iyi bir örnektir. Eğer sadece tabloyu etkiliyorsa yerel durum uygundur. Eğer filtreler bir üst bilgi bileşeninde duruyor ama aşağıdaki tabloyu kontrol ediyorsa, sayfa kapsamlı bir paylaşım (çoğunlukla provide/inject) işleri temiz tutar.\n\n2. Ne kadar uzun yaşamalı?\n - Bileşen unmount olduğunda yok olabiliyorsa yerel durum idealdir.\n - Rota değişikliğini aşması gerekiyorsa Pinia daha iyi uyabilir.\n - Yenilemeyi aşması gerekiyorsa, nerede yaşadığına bakmadan kalıcılık (storage) de gerekir.\n\n Bu, taslaklar için en önemlisidir. Kaydedilmemiş düzenlemeler güven duyusu gerektirir: insanlar uzaklaşıp geri döndüklerinde bir taslağın orada olmasını bekler.\n\n3. Tarayıcı sekmeleri arasında paylaşılmalı mı yoksa sekme başına izole mi olmalı?\n\n Çoklu sekme düzenleme hataların saklandığı yerdir. Her sekmenin kendi taslağı olmalıysa tek global bir singleton'tan kaçının. Kayıt ID'si ile anahtarlanan durum tercih edin veya durumu sayfa kapsamlı tutun ki bir sekme diğerini ezemesin.\n\n4. Uyan en basit seçeneği seçin.\n\n Önce yerel başla. Sadece gerçek acı hissettiğinizde yukarı taşıyın: prop zinciri, tekrar eden mantık veya zor üretilen sıfırlanmalar.\n\n5. Debug ihtiyaçlarınızı doğrulayın.\n\n Değişikliklerin açık, denetlenebilir bir görünümüne ihtiyacınız varsa Pinia’nın merkezi eylemleri ve durum incelemesi saatler kazandırabilir. Durum kısa ömürlü ve açıksa yerel durum okumayı daha kolay kılar.\n\n## Yerel bileşen durumu: ne zaman yeterlidir\n\nYerel durum, veri sadece bir bileşeni etkilediğinde varsayılandır. Bu seçeneği atlamak ve aylardır bakımını yapacağınız bir store kurmak kolaydır.\n\nAçık bir uygunluk, kendi filtrelerine sahip tek bir tablodur. Eğer filtreler sadece o tabloyu etkiliyorsa (örneğin Kullanıcılar listesi) bunları tablo bileşeni içindeki ref değerleri olarak tutun. “Modal açık mı?”, “hangi satır düzenleniyor?” ve “hangi öğeler şu an seçili?” gibi küçük UI durumları için de aynı şey geçerli.\n\nDepolamaktan kaçınabileceğiniz şeyleri saklamamaya çalışın. “Aktif filtreler (3)” rozeti mevcut filtre değerlerinden hesaplanmalıdır. Sıralama etiketleri, biçimlendirilmiş özetler ve “kaydedilebilir” bayrakları da computed olarak tutulursa otomatik olarak senkron kalırlar.\n\nSıfırlama kuralları seçtiğiniz araçtan daha önemlidir. Hangi durumun rota değiştiğinde temizleneceğini (genellikle her şey) ve hangi durumun aynı sayfa içindeki görünüm değişiminde kalacağını (örneğin filtreleri tutup geçici seçimleri temizlemek) karar verin.\n\nYerel bileşen durumu genellikle yeterlidir when:\n\n- Durum tek bir widget'i etkiliyorsa (tek form, tek tablo, tek modal).\n- Başka bir ekranın okumasına veya değiştirmesine gerek yoksa.\n- 1–2 bileşen içinde prop geçmeden tutulabiliyorsa.\n- Sıfırlama davranışını bir cümlede açıklayabiliyorsanız.\n\nAna sınır derinliktir. Aynı durumu birkaç iç içe bileşene geçirmek zorunda kaldığınızda, yerel durum prop zincirine dönüşür ve bu genelde provide/inject veya bir store'a geçme işaretidir.\n\n## provide/inject: bir sayfa veya özellik alanı içinde durumu paylaşmak\n\nprovide/inject yerel durum ile tam bir store arasında durur. Bir üst bileşen altındakilere değerler “sağlar” ve iç bileşenler bunları prop zinciri olmadan “enjekte” eder. Yönetim panellerinde, durum bir ekranın veya özellik alanınınsa (tüm uygulamanın değil) harika bir uyumdur.\n\nYaygın bir desen, durumu sahiplenen bir sayfa kabuğu ve küçük bileşenlerin bunu tüketmesidir: bir filtre çubuğu, tablo, toplu eylem aracı, detay çekmecesi ve “kaydedilmemiş değişiklikler” bildirimi. Kabuğun paylaştığı reaktif yüzey küçük olabilir; örneğin bir filters nesnesi, bir draftStatus nesnesi (dirty, saving, error) ve birkaç salt-okunur bayrak (isReadOnly gibi izinlere dayalı).\n\n### Ne sağlanmalı (küçük tutun)\n\nHer şeyi sağlarsanız, temelde daha az yapılandırılmış bir store yeniden yaratırsınız. Birkaç çocuğun gerçekten ihtiyaç duyduğu şeyleri sağlayın. Filtreler klasik bir örnektir: tablo, etiketler, dışa aktarma eylemi ve sayfalama senkron kalmalıysa, bir doğruluk kaynağını paylaşmak prop ve olaylarla uğraşmaktan daha iyidir.\n\n### Açıklık ve tuzaklar\n\nEn büyük risk gizli bağımlılıklardır: bir çocuk “sadece çalışır” çünkü yukarıda bir şey sağlanmıştır ve sonra güncellemelerin nereden geldiğini bulmak zorlaşır.\n\nOkunabilir ve test edilebilir tutmak için injectionlara açık isimler verin (genellikle sabitler veya Symbol'lar ile). Ayrıca sadece değiştirilebilir nesneler sağlamak yerine eylemleri sağlamak tercih edilir. setFilter, markDirty, resetDraft gibi küçük bir API sahipliği ve izin verilen değişiklikleri açıklar.\n\n## Pinia: ekranlar arası paylaşılan durum ve öngörülebilir güncellemeler\n\nPinia, aynı durumun rotalar arasında tutarlı kalması gerektiğinde parlıyor. Yönetim panelinde, bu genellikle mevcut kullanıcı, hangi işlemlere izinli olduğu, seçili organizasyon/çalışma alanı ve uygulama düzeyi ayarları demektir. Her ekran bunu yeniden uyguladığında acı başlar.\n\nBir store size paylaşılan durumu okumak ve güncellemek için tek bir yer verir. Birçok katman arasında prop geçirmek yerine, ihtiyacınız olduğunda store'u import edersiniz. Listeden detay sayfasına geçtiğinizde UI yine aynı seçili org, izinler ve ayarlara tepki verebilir.\n\n### Pinia neden daha kolay bakım sağlar\n\nPinia basit bir yapı zorlar: ham değerler için state, türetilmiş değerler için getters ve güncellemeler için actions. Yönetim UI'larında bu yapı “kolay düzeltmelerin” dağınık mutasyonlara dönüşmesini engeller.\n\nEğer “canEditUsers” mevcut role ve bir özellik bayrağına bağlıysa kuralı bir getter'a koyun. Bir organizasyon değişimi önbellek seçimlerini temizlemeyi ve navigasyonu yeniden yüklemeyi gerektiriyorsa, bu diziyi bir action içinde toplayın. Böylece gizemli watcher'lar ve “neden değişti bu?” anları azalır.\n\nPinia ayrıca Vue DevTools ile iyi çalışır. Bir hata olduğunda store durumunu incelemek ve hangi action'ın çalıştığını görmek, rastgele bileşenlerde yaratılan ad-hoc reaktif nesneleri takip etmekten çok daha kolaydır.\n\n### Çöp deposu store'dan kaçının\n\nGlobal bir store başta düzenli hissettirir, sonra bir eşya çekmecesine dönüşür. Pinia için iyi adaylar gerçekten paylaşılan kaygılar olmalıdır: kullanıcı kimliği ve izinleri, seçili çalışma alanı, özellik bayrakları ve birçok ekranda kullanılan referans veriler.\n\nSayfa-özel kaygılar (bir formun geçici girdisi gibi) rotalar gerçekten ihtiyaç duymuyorsa yerel kalmalıdır.\n\n## Örnek 1: her şeyi store'a çevirmeden filtreler ve tablolar\n\nBir Orders sayfası hayal edin: bir tablo, filtreler (durum, tarih aralığı, müşteri), sayfalama ve seçili siparişi önizleyen bir yan panel. Bu hızla karmaşıklaşır çünkü her filtre ve tablo ayarını global store'a koymak cazip gelir.\n\nSeçmek için basit bir yol, neyin hatırlanması gerektiğine karar vermektir ve nerede tutulacağına:\n\n- Sadece hafıza (yerel veya provide/inject): sayfadan ayrıldığınızda sıfırlanır. Geçici durum için ideal.\n- Sorgu parametreleri: paylaşılabilir ve yenileme sonrası kalır. Filtreler ve sayfalama için iyi.\n- Pinia: navigasyonu aşar. "Listeyi bıraktığım gibi geri gelme" hissi için iyi.\n\nBundan sonra uygulama genellikle şu şekilde ilerler:\n\nEğer ayarların navigasyonu aşması beklenmiyorsa, filters, sort, page ve pageSize değerlerini Orders sayfa bileşeninin içinde tutun ve bu sayfa fetch'i tetiksin. Eğer toolbar, tablo ve önizleme paneli aynı modeli gerekiyorsa ve prop zinciri gürültülü hale geliyorsa, liste modelini sayfa kabuğuna taşıyıp provide/inject ile paylaşın. Listeyi rotalar arası yapışkan hissettirmek istiyorsanız (bir siparişi açıp başka yere gidip geri döndüğünüzde aynı filtre ve seçimin kalması), Pinia daha iyi bir seçimdir.\n\nPratik bir kural: önce yerel başla, birkaç çocuk aynı modele ihtiyaç duyduğunda provide/inject'e geçin ve rotalar arası kalıcılık gerçekten gerektiğinde Pinia'ya uzanın.\n\n## Örnek 2: taslaklar ve kaydedilmemiş düzenlemeler (kullanıcıların güveneceği formlar)\n\nBir destek görevlisinin bir müşteri kaydını düzenlediğini düşünün: iletişim bilgileri, faturalama ve dahili notlar. Müdahale edilirler, ekran değiştirirler ve sonra geri dönerler. Eğer form çalışmalarını unutuyorsa veya yarım bırakılmış veriyi kazara kaydediyorsa, güven gider.\n\nTaslaklar için üç şeyi ayırın: son kaydedilmiş kayıt, kullanıcının sahnelediği düzenlemeler ve doğrulama hataları gibi yalnızca UI durumları.\n\n### Yerel durum: açıkça tanımlanmış dirty kurallarıyla sahnelediğiniz düzenlemeler\n\nEğer düzenleme ekranı kendi içinde kapalıysa, yerel bileşen durumu çoğunlukla en güvenlisi olur. Kaydı yükleyin, bir draft kopyası oluşturun, isDirty (veya alan düzeyinde dirty haritası) takip edin ve hataları form kontrollerinin yanında saklayın.\n\nBasit akış: kaydı yükle, draft'a kopyala, draft'ı düzenle ve kullanıcı Kaydet'e tıklayana kadar sadece kaydetme isteği gönderme. İptal draft'ı iptal eder ve yeniden yükler.\n\n### provide/inject: iç içe bölümler arasında paylaşılan tek bir taslak\n\nYönetim formları genellikle sekmelere veya panellere bölünür (Profil, Adresler, İzinler). provide/inject ile tek bir draft modeli tutabilir ve updateField(), resetDraft() ve validateSection() gibi küçük bir API sunabilirsiniz. Her bölüm aynı draft'ı okuyup yazar, prop zinciri olmadan.\n\n### Pinia taslaklarda ne zaman yardımcı olur\n\nTaslaklar navigasyonu aşmalı veya düzenleme ekranının dışından görünür olmalıysa Pinia işe yarar. Yaygın bir desen draftsById[customerId] şeklindedir, böylece her kayıt kendi taslağına sahip olur. Bu ayrıca kullanıcıların birden çok düzenleme ekranı açabildiği durumlarda da yardımcı olur.\n\nTaslak hataları genellikle birkaç tahmin edilebilir hatadan gelir: kayıt yüklenmeden önce taslak oluşturmak, kirli bir taslağın yeniden getirme ile üzerine yazılması, iptal sırasında hataları temizlemeyi unutmak veya taslakların birbirinin üstüne yazılmasına yol açan tek bir paylaşılan anahtar kullanmak. Ne zaman oluşturulacağını, üzerine yazılacağını, atılacağını, saklanacağını ve kaydetme sonrası nasıl değiştirileceğini net kurallarla belirlerseniz çoğu sorun kaybolur.\n\nAppMaster ile yönetim ekranları oluşturuyorsanız, “taslak vs kaydedilmiş kayıt” ayrımı hala geçerlidir: taslağı istemci tarafında tutun ve backend'i yalnızca başarılı bir Kaydet sonrası doğrulanmış kaynak olarak kabul edin.\n\n## Örnek 3: çoklu sekme düzenleme ve durum çakışmaları olmadan\n\nÇoklu sekme düzenleme, yönetim panellerinin sık kırıldığı yerdir. Kullanıcı Müşteri A’yı açar, sonra Müşteri B’yi açar, geri gelir ve her sekmenin kendi kaydedilmemiş değişikliklerini hatırlamasını bekler.\n\nÇözüm her sekmeyi tek bir durum paketine dönüştürmek değil, her sekmeyi kendi durum paketi olarak modellemektir. Her sekmenin en azından benzersiz bir anahtara (genellikle kayıt ID'sine), draft verisine, duruma (clean, dirty, saving) ve alan hatalarına ihtiyacı vardır.\n\nSekmeler aynı ekran içindeyse yerel yaklaşım iyi çalışır. Sekme listesini ve draft'ları sayfa bileşeni sahiplenir. Her editör paneli sadece kendi paketini okur ve yazar. Bir sekme kapandığında o paketi silin ve iş biter. Bu izolasyonu sağlar ve düşünmesi kolaydır.\n\nDurum nerede yaşarsa yaşasın, şekil benzerdir:\n\n- Her birinin kendi customerId, draft, status ve errors alanları olan bir sekme nesnesi listesi\n- Bir activeTabKey\n- openTab(id), updateDraft(key, patch), saveTab(key) ve closeTab(key) gibi eylemler\n\nSekmeler navigasyonu aşmalıysa (Orders'a gidip geri dönmek gibi) veya birden çok ekran sekme açıp odaklamak zorundaysa Pinia daha iyi bir seçimdir. Bu durumda küçük bir “sekme yöneticisi” store uygulama genelinde davranışı tutarlı kılar.\n\nKaçınılması gereken ana çarpışma tek bir global değişken (currentDraft gibi) kullanmaktır. Bu ikinci sekme açılana kadar işe yarar, sonra düzenlemeler birbirini ezer, doğrulama hataları yanlış yerde görünür ve Kaydet yanlış kaydı günceller. Her açık sekmenin kendi paketi olduğunda çakışmalar tasarım gereği büyük ölçüde kaybolur.\n\n## Hatalara ve karmaşık koda yol açan yaygın hatalar\n\nÇoğu yönetim paneli hatası “Vue hatası” değildir. Bunlar durum hatalarıdır: veriler yanlış yerde yaşıyor, ekranın iki parçası anlaşamıyor veya eski durum sessizce kalıyor.\n\nEn sık görülen desenler:\n\nHer şeyi varsayılan olarak Pinia'ya koymak sahipliği belirsizleştirir. Global bir store başta düzenli görünür, ama sonra her sayfa aynı nesneleri okur ve yazar ve temizlik tahmine dayanır.\n\nprovide/inject'i net bir sözleşme olmadan kullanmak gizli bağımlılıklar yaratır. Bir çocuk filters inject ediyorsa ama kim sağlıyor ve hangi eylemler değiştirebilir konusunda ortak anlayış yoksa başka bir çocuk aynı nesneyi değiştirmeye başlayınca sürpriz güncellemeler olur.\n\nAynı store içinde sunucu durumu ve UI durumunu karıştırmak kazara üzerine yazmalara yol açar. Getirilen kayıtlar “drawer açık mı?”, “geçerli sekme” veya “kirli alanlar” gibi UI'den farklı davranır. Birlikte yaşadıklarında refetch UI'yi ezebilir veya UI değişiklikleri cachelenmiş veriyi bozabilir.\n\nYaşam döngüsü temizliği atlamak durumun sızmasına izin verir. Bir görüşten kalan filtreler başka bir görünümü etkileyebilir ve taslaklar sayfadan ayrıldıktan sonra kalabilir. Birisi başka bir kaydı açtığında eski seçimleri görür ve uygulamanın bozuk olduğunu varsayar.\n\nTaslakları kötü anahtarlamak sessiz bir güven kırıcıdır. Eğer taslakları draft:editUser gibi tek bir anahtar altında saklıyorsanız, Kullanıcı A'yı düzenlemek Kullanıcı B'yi düzenlediğinizde aynı taslağı üzerine yazar.\n\nBunların çoğunu önlemenin basit kuralı: durumu mümkün olduğunca kullanıldığı yere yakın tutun ve yalnızca iki bağımsız parça gerçekten paylaşması gerektiğinde onu yukarı taşıyın. Paylaştığınızda sahipliği (kimin değiştirebileceği) ve kimliği (nasıl anahtarlanacağı) tanımlayın.\n\n## Yerel, provide/inject veya Pinia seçmeden önce hızlı kontrol listesi\n\nEn kullanışlı soru: bu durumun sahibi kim? Bunu bir cümlede söyleyemiyorsanız, durum muhtemelen fazla şey yapıyor ve bölünmeli.\n\nBu kontrolleri hızlı filtre olarak kullanın:\n\n- Sahibini adlandırabiliyor musunuz (bir bileşen, bir sayfa veya tüm uygulama)?\n- Rota değişikliklerini veya yenilemeyi geçmesi gerekiyor mu? Evetse, tarayıcıdan beklemek yerine kalıcılık planlayın.\n- Aynı anda iki kayıt düzenlenir mi? Evetse, durumu kayıt ID'si ile anahtarlayın.\n- Durum sadece bir sayfa kabuğu altındaki bileşenler tarafından mı kullanılıyor? Evetse, provide/inject genellikle uygundur.\n- Değişiklikleri inceleyip kimin neyi değiştirdiğini anlamak istiyor musunuz? Evetse, Pinia genellikle o dilim için en temiz yerdir.\n\nAraç eşlemesi, açık terimlerle:\n\nEğer durum bir bileşen içinde yaşıyorsa ve ölüyorsa (örneğin bir açılır menü açık/kapalı bayrağı), yerel tutun. Eğer aynı ekrandaki birkaç bileşen paylaşılan bağlama ihtiyaç duyuyorsa (filtre çubuğu + tablo + özet), provide/inject küresel hale getirmeden paylaşım sağlar. Eğer durum ekranlar arası paylaşılmalı, navigasyonu aşmalı veya öngörülebilir, debug edilebilir güncellemeler gerekliyse Pinia'ya ve taslaklar için kayıt ID'siyle anahtarlamaya yönelin.\n\nAppMaster gibi araçlarla bir Vue 3 yönetim UI'si inşa ediyorsanız, bu kontrol listesi her şeyi çok erken store'a koymanızı engellemeye yardımcı olur.\n\n## Sonraki adımlar: durumu karmaşıklaştırmadan geliştirmek\n\nYönetim panellerinde durum yönetimini geliştirmek için en güvenli yol küçük, sıkıcı adımlarla büyütmektir. Bir sayfa içinde kalan her şey için önce yerel tutun. Gerçek yeniden kullanım (kopyalanmış mantık, üçüncü bir bileşenin aynı duruma ihtiyacı) gördüğünüzde bir seviye yukarı taşıyın. Sadece o zaman paylaşılan bir store düşünün.\n\nÇoğu ekip için işe yarayan bir yol:\n\n- Sayfa-özel durumu önce yerel tutun (filtreler, sıralama, sayfalama, açık/kapalı paneller).\n- Bir sayfadaki birkaç bileşen paylaşılan bağlama ihtiyaç duyduğunda provide/inject kullanın.\n- Rotlar arası ihtiyaçlar için her seferinde bir Pinia store ekleyin (taslak yöneticisi, sekme yöneticisi, mevcut çalışma alanı).\n- Sıfırlama kuralları yazın ve bunlara sadık kalın (navigasyonda, çıkışta, Filtreleri Temizle, Değişiklikleri At gibi ne sıfırlanır).\n\nSıfırlama kuralları küçük gibi görünür ama çoğu “neden değişti?” anını engeller. Örneğin birisi başka bir kaydı açıp geri döndüğünde bir taslağa ne olacağına karar verin: geri yükle, uyar veya sıfırla. Sonra bu davranışı tutarlı hale getirin.\n\nBir store kullanmaya başlarsanız, onu özellik-şekilli tutun. Bir taslaklar store'u oluşturma, geri yükleme ve temizleme işlemlerini yapmalı ama tablo filtrelerini veya UI düzen bayraklarını da sahiplenmemelidir.\n\nHızlı bir prototip yapmak istiyorsanız, AppMaster hızlıca bir Vue3 web uygulaması ile backend ve iş mantığı üretebilir ve üretilen kodda özel durum işlemlerini gerektiği yerde rafine edebilirsiniz. Gerçek bir sonraki adım, bir ekranı uçtan uca (örneğin düzenleme formu ve taslak kurtarma) inşa etmek ve gerçekten neyin Pinia gerektirdiğini görmek olabilir.