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

Yönetim panellerinde durumu zorlaştıran ne?

Yö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.

Zorluk 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.

Vue 3’te genellikle durumu üç yerden birinde tutmayı seçersiniz:

• Yerel bileşen durumu: tek bir bileşenin sahip olduğu ve unmount olduğunda sıfırlanması güvenli olan durum.
• provide/inject: prop zinciri olmadan bir sayfa veya özellik alanı kapsamında paylaşılan durum.
• Pinia: navigasyonu aşması, rotalar arası yeniden kullanılabilmesi ve debug için kolay kalması gereken paylaşılan durum.

Düşü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.

Aş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).

Araç seçmeden önce durumu sınıflandırmanın basit bir yolu

Araç 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.

Pratik bir ayrım:

• UI durumu: toggle'lar, açık diyaloglar, seçili satırlar, aktif sekmeler, sıralama düzeni.
• Sunucu durumu: API yanıtları, yükleniyor bayrakları, hatalar, son yenileme zamanı.
• Form durumu: alan değerleri, doğrulama hataları, dirty bayrakları, kaydedilmemiş taslaklar.
• Ekranlar arası durum: birden çok rota tarafından okunması veya değiştirilmesi gereken her şey (geçerli çalışma alanı, paylaşılan izinler).

Sonra 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.

Sonraki 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.

Son 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.

Ö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.

Durumu 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.

Nasıl seçilir: işe yarayan bir karar süreci

İ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.

5 adımlı karar süreci

1. Kime lazım bu durum?

   • Tek bir bileşen: yerelde tutun.
   • Bir sayfa altındaki birkaç bileşen: provide/inject düşünün.
   • Birden çok rota: Pinia'yı değerlendirin.

   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.

2. Ne kadar uzun yaşamalı?

   • Bileşen unmount olduğunda yok olabiliyorsa yerel durum idealdir.
   • Rota değişikliğini aşması gerekiyorsa Pinia daha iyi uyabilir.
   • Yenilemeyi aşması gerekiyorsa, nerede yaşadığına bakmadan kalıcılık (storage) de gerekir.

   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.

3. Tarayıcı sekmeleri arasında paylaşılmalı mı yoksa sekme başına izole mi olmalı?

   Ç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.

4. Uyan en basit seçeneği seçin.

   Ö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.

5. Debug ihtiyaçlarınızı doğrulayı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.

Yerel bileşen durumu: ne zaman yeterlidir

Yerel 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.

Açı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.

Depolamaktan 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.

Sı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.

Yerel bileşen durumu genellikle yeterlidir when:

• Durum tek bir widget'i etkiliyorsa (tek form, tek tablo, tek modal).
• Başka bir ekranın okumasına veya değiştirmesine gerek yoksa.
• 1–2 bileşen içinde prop geçmeden tutulabiliyorsa.
• Sıfırlama davranışını bir cümlede açıklayabiliyorsanız.

Ana 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.

provide/inject: bir sayfa veya özellik alanı içinde durumu paylaşmak

provide/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.

Yaygı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ı).

Ne sağlanmalı (küçük tutun)

Her ş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.

Açıklık ve tuzaklar

En 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.

Okunabilir 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.

Pinia: ekranlar arası paylaşılan durum ve öngörülebilir güncellemeler

Pinia, 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.

Bir 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.

Pinia neden daha kolay bakım sağlar

Pinia 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.

Eğ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.

Pinia 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.

Çöp deposu store'dan kaçının

Global 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.

Sayfa-özel kaygılar (bir formun geçici girdisi gibi) rotalar gerçekten ihtiyaç duymuyorsa yerel kalmalıdır.

Örnek 1: her şeyi store'a çevirmeden filtreler ve tablolar

Bir 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.

Seçmek için basit bir yol, neyin hatırlanması gerektiğine karar vermektir ve nerede tutulacağına:

• Sadece hafıza (yerel veya provide/inject): sayfadan ayrıldığınızda sıfırlanır. Geçici durum için ideal.
• Sorgu parametreleri: paylaşılabilir ve yenileme sonrası kalır. Filtreler ve sayfalama için iyi.
• Pinia: navigasyonu aşar. "Listeyi bıraktığım gibi geri gelme" hissi için iyi.

Bundan sonra uygulama genellikle şu şekilde ilerler:

Eğ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.

Pratik 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.

Örnek 2: taslaklar ve kaydedilmemiş düzenlemeler (kullanıcıların güveneceği formlar)

Bir 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.

Taslaklar 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ı.

Yerel durum: açıkça tanımlanmış dirty kurallarıyla sahnelediğiniz düzenlemeler

Eğ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.

Basit 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.

provide/inject: iç içe bölümler arasında paylaşılan tek bir taslak

Yö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.

Pinia taslaklarda ne zaman yardımcı olur

Taslaklar 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.

Taslak 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.

AppMaster 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.

Örnek 3: çoklu sekme düzenleme ve durum çakışmaları olmadan

Ç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.

Çö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.

Sekmeler 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.

Durum nerede yaşarsa yaşasın, şekil benzerdir:

• Her birinin kendi customerId, draft, status ve errors alanları olan bir sekme nesnesi listesi
• Bir activeTabKey
• openTab(id), updateDraft(key, patch), saveTab(key) ve closeTab(key) gibi eylemler

Sekmeler 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.

Kaçı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.

Hatalara ve karmaşık koda yol açan yaygın hatalar

Ç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.

En sık görülen desenler:

Her ş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.

provide/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.

Aynı 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.

Yaş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.

Taslakları 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.

Bunları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.

Yerel, provide/inject veya Pinia seçmeden önce hızlı kontrol listesi

En kullanışlı soru: bu durumun sahibi kim? Bunu bir cümlede söyleyemiyorsanız, durum muhtemelen fazla şey yapıyor ve bölünmeli.

Bu kontrolleri hızlı filtre olarak kullanın:

• Sahibini adlandırabiliyor musunuz (bir bileşen, bir sayfa veya tüm uygulama)?
• Rota değişikliklerini veya yenilemeyi geçmesi gerekiyor mu? Evetse, tarayıcıdan beklemek yerine kalıcılık planlayın.
• Aynı anda iki kayıt düzenlenir mi? Evetse, durumu kayıt ID'si ile anahtarlayın.
• Durum sadece bir sayfa kabuğu altındaki bileşenler tarafından mı kullanılıyor? Evetse, provide/inject genellikle uygundur.
• Değişiklikleri inceleyip kimin neyi değiştirdiğini anlamak istiyor musunuz? Evetse, Pinia genellikle o dilim için en temiz yerdir.

Araç eşlemesi, açık terimlerle:

Eğ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.

AppMaster 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.

Sonraki adımlar: durumu karmaşıklaştırmadan geliştirmek

Yö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.

Çoğu ekip için işe yarayan bir yol:

• Sayfa-özel durumu önce yerel tutun (filtreler, sıralama, sayfalama, açık/kapalı paneller).
• Bir sayfadaki birkaç bileşen paylaşılan bağlama ihtiyaç duyduğunda provide/inject kullanın.
• Rotlar arası ihtiyaçlar için her seferinde bir Pinia store ekleyin (taslak yöneticisi, sekme yöneticisi, mevcut çalışma alanı).
• 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).

Sı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.

Bir 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.

Hı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.