Vuex Eylemine Karşı Mutasyonlar

Vuex'te hem "eylemlere" hem de "mutasyonlara" sahip olmanın mantığı nedir?

Bileşenlerin mantığını anlayamıyorum (akıllı görünüyor), ancak hem eylemlere hem de mutasyonlara sahip olmak, başka bir işlevi tetiklemek için bir işlevi yazıyor, daha sonra durumu değiştirmek gibi görünüyor.

"Eylemler" ve "mutasyonlar" arasındaki fark nedir, birlikte nasıl çalışırlar ve moreso, Vuex geliştiricilerinin neden bu şekilde yapmaya karar verdiklerini merak ediyorum?

Soru 1 : Vuejs geliştiricileri bunu neden bu şekilde yapmaya karar verdiler?

Cevap:

1. Başvurunuz genişlediğinde ve bu proje üzerinde çalışan birden fazla geliştirici olduğunda, "devlet yönetimini" (özellikle "küresel devlet") giderek daha karmaşık hale getireceksiniz.
2. Vuex yolu (reat.js'deki Redux gibi ), durumu yönetmek, durumu korumak ve "kaydet ve izlenebilir" için yeni bir mekanizma sunar (bu, durumu değiştiren her eylemin hata ayıklama aracı tarafından izlenebileceği anlamına gelir : vue-devtools )

Soru 2 : "Eylem" ve "mutasyon" arasındaki fark nedir?

Önce resmi açıklamaya bakalım:

Mutasyonlar:

Vuex mutasyonları esasen olaylardır: her mutasyonun bir adı ve bir işleyicisi vardır.

import Vuex from 'vuex'

const store = new Vuex.Store({
  state: {
    count: 1
  },
  mutations: {
    INCREMENT (state) {
      // mutate state
      state.count++
    }
  }
})

Eylemler: Eylemler sadece mutasyon gönderen işlevlerdir.

// the simplest action
function increment (store) {
  store.dispatch('INCREMENT')
}

// a action with additional arguments
// with ES2015 argument destructuring
function incrementBy ({ dispatch }, amount) {
  dispatch('INCREMENT', amount)
}

İşte yukarıdaki açıklama:

• durumu değiştirmek için tek yol mutasyon
• mutasyon iş mantığını umursamıyor, sadece "devlet"
• eylem iş mantığıdır
• eylem olabilir sevk o (mutasyon yoluyla yönetmek) değiştirerek veri umursamıyor, sadece iş mantığını uygulayan bir defada fazla 1 mutasyonu

Mutasyonlar eşzamanlı iken eylemler eşzamansız olabilir.

Başka bir deyişle, işlemleriniz senkronize ise eylemlere ihtiyacınız yoktur, aksi takdirde bunları uygulayın.

Mutasyonların ve Eylemlerin ardındaki motivasyonları anlamanın, hangisini ve nasıl kullanacağını daha iyi yargılayabileceğine inanıyorum. Ayrıca "kuralların" bulanıklaştığı durumlarda programlayıcıyı belirsizlik yükünden kurtarır. İlgili amaçları hakkında biraz düşündükten sonra, Eylemler ve Mutasyonları kullanmanın kesinlikle yanlış yolları olsa da, kanonik bir yaklaşım olduğunu düşünmediğim sonucuna vardım.

Önce neden Mutasyonlar veya Eylemler'den geçtiğimizi anlamaya çalışalım.

Neden ilk önce kazan plakasından geçmelisiniz? Neden doğrudan bileşenlerdeki durumu değiştirmiyorsunuz?

Kesinlikle söylemek gerekirse statedoğrudan bileşenlerinizden değiştirebilirsiniz. Bu statesadece bir JavaScript nesnesidir ve üzerinde yaptığınız değişiklikleri geri alacak büyülü bir şey yoktur.

// Yes, you can!
this.$store.state['products'].push(product)

Ancak, bunu yaparak devlet mutasyonlarınızı her yere dağıtırsınız. Sadece durumu barındıran tek bir modülü açma yeteneğini kaybedersiniz ve bir bakışta ne tür işlemlerin uygulanabileceğini görürsünüz. Merkezi mutasyonlara sahip olmak, bazı kazanların maliyeti de olsa bunu çözer.

// so we go from this
this.$store.state['products'].push(product)

// to this
this.$store.commit('addProduct', {product})

...
// and in store
addProduct(state, {product}){
    state.products.push(product)
}
...

Sanırım kısa bir şeyi kazan plakasıyla değiştirirseniz, kazan plakasının da küçük olmasını isteyeceksiniz. Bu nedenle mutasyonların, devlet üzerindeki yerel operasyonlar etrafında, neredeyse hiç iş mantığı olmadan çok ince sarıcılar olduğunu varsayıyorum. Başka bir deyişle, mutasyonlar çoğunlukla seterler gibi kullanılmalıdır.

Mutasyonlarınızı merkezileştirdiğinize göre, durum değişiklikleriniz hakkında daha iyi bir genel bakışa sahip olursunuz ve takımlarınız (vue-devtools) da bu konumun farkında olduğundan hata ayıklamayı kolaylaştırır. Ayrıca, birçok Vuex'in eklentisinin, değişiklikleri izlemek için doğrudan durumu izlemediğini, bunun için mutasyonlara bel bağladığını unutmayın. Devletteki "sınır dışı" değişiklikler bu nedenle onlar tarafından görülemez.

Peki mutations, actionsfark ne?

Mutasyonlar gibi eylemler de mağazanın modülünde bulunur ve statenesneyi alabilir . Bu da onların ima olabilir ayrıca doğrudan mutasyona. Her ikisine birden sahip olmanın anlamı nedir? Mutasyonların küçük ve basit tutulması gerektiğini düşünürsek, daha ayrıntılı iş mantığını barındırmak için alternatif bir yola ihtiyacımız olduğunu ima eder. Eylemler bunu yapmanın yollarıdır. Ve daha önce belirlediğimiz gibi, vue-devtools ve eklentiler Mutasyonlar yoluyla yapılan değişikliklerin farkında olduğundan, tutarlı kalmak için eylemlerimizden Mutasyonları kullanmaya devam etmeliyiz. Ayrıca, eylemlerin hepsi kapsayıcı olması ve kapsadıkları mantığın eşzamansız olabilmesi nedeniyle, İşlemlerin başlangıçtan itibaren eşzamansız hale getirilmesi mantıklıdır.

Genellikle eylemlerin eşzamansız olabileceği vurgulanırken, mutasyonlar genellikle değildir. Ayrımı, mutasyonların eşzamanlı her şey için (ve eşzamansız her şey için eylemler) kullanılması gerektiğinin bir göstergesi olarak görmeye karar verebilirsiniz; ancak, örneğin birden fazla mutasyon (eşzamanlı olarak) yapmanız gerekiyorsa veya mutasyonlarınızdan bir Getter ile çalışmanız gerekiyorsa, mutasyon işlevleri argüman olarak Getters veya Mutasyonları almadığı için bazı zorluklarla karşılaşırsınız ...

... bu ilginç bir soruya yol açıyor.

Mutasyonlar neden Mektup almıyor?

Bu soruya henüz tatmin edici bir cevap bulamadım. Çekirdek ekip tarafından en çok tartıştığım bir açıklama gördüm. Kullanımlarını özetlersem, Getters durum uzantılarının hesaplanması (ve genellikle önbelleğe alınması) anlamına gelir. Başka bir deyişle, açık bir hesaplama gerektirse de, temelde hala devlettirler ve normalde salt okunurdurlar. En azından bu şekilde kullanılmaları teşvik ediliyor.

Bu nedenle, Mutasyonların doğrudan Getters'a erişmesini engellemek, şimdi üç şeyden birinin gerekli olduğu anlamına gelir, eğer ikincisinden sunulan bazı işlevlere erişmemiz gerekirse: (1) Getter tarafından sağlanan durum hesaplamaları erişilebilir bir yerde çoğaltılır Mutasyona (kötü koku) veya (2) hesaplanan değer (veya ilgili Getter'ın kendisi) Mutasyona (funky) açık bir argüman olarak aktarılır veya (3) Getter'in mantığının kendisi doğrudan Mutasyon içinde çoğaltılır , Getter (kokusu) tarafından sağlanan önbellekleme avantajı olmadan.

Aşağıda, karşılaştığım çoğu senaryoda "en az kötü" seçenek gibi görünen (2) örneği verilmiştir.

state:{
    shoppingCart: {
        products: []
    }
},

getters:{
    hasProduct(state){
        return function(product) { ... }
    }
}

actions: {
    addProduct({state, getters, commit, dispatch}, {product}){

        // all kinds of business logic goes here

        // then pull out some computed state
        const hasProduct = getters.hasProduct(product)
        // and pass it to the mutation
        commit('addProduct', {product, hasProduct})
    }
}

mutations: {
    addProduct(state, {product, hasProduct}){ 
        if (hasProduct){
            // mutate the state one way
        } else {
            // mutate the state another way 
        }
    }
}

Bana göre, yukarıdakiler sadece biraz kıvrımlı değil, aynı zamanda bir şekilde "sızdıran" gibi görünüyor, çünkü Eylemde bulunan kodun bir kısmı Mutasyonun iç mantığından açıkça sızıyor.

Bence bu bir uzlaşma göstergesi. Mutasyonların otomatik olarak Getters almasına izin vermenin bazı zorluklar getirdiğine inanıyorum. Vuex'in kendisi ya da alet (vue-devtools et al) tasarımı ya da geriye dönük uyumluluk ya da belirtilen tüm olasılıkların bir kombinasyonunu korumak olabilir.

İnanmadığım şey, Mutasyonlarınıza kendinizin geçmesi, mutlaka yanlış bir şey yaptığınızın bir işaretidir. Bunu çerçevenin eksikliklerinden biri olarak "yamalı" olarak görüyorum.

TLDR cevabının, Mutasyonların senkron / işlemsel olması gerektiği yönündedir. Bu nedenle, bir Ajax çağrısı çalıştırmanız veya başka bir eşzamansız kod yapmanız gerekiyorsa, yeni durumu ayarlamak için bunu bir Eylem'de yapmanız ve ardından bir mutasyon gerçekleştirmeniz gerekir.

Eylemler ve Mutasyonlar arasındaki temel farklar:

1. Eylemlerin içinde eşzamansız kod çalıştırabilirsiniz, ancak mutasyonlarda çalışamazsınız. Bu nedenle, eşzamansız kod için eylemleri kullanın, aksi takdirde mutasyonlar kullanın.
2. Eylemlerin içinde alıcılara, duruma, mutasyonlara (taahhütte bulunma), eylemlere (sevk etme) erişebilir ve duruma erişebilirsiniz. Yani sadece devlete erişmek istiyorsanız mutasyonları kullanın, aksi takdirde eylemleri kullanın.

Göre docs

Eylemler mutasyonlara benzer , farklılıklar şöyledir :

• Yerine mutasyona durumunu, eylemler taahhüt mutasyonları.
• Eylemler keyfi eşzamansız işlemler içerebilir .

Aşağıdaki kod parçasını düşünün.

const store = new Vuex.Store({
  state: {
    count: 0
  },
  mutations: {
    increment (state) {
      state.count++               //Mutating the state. Must be synchronous
    }
  },
  actions: {
    increment (context) {
      context.commit('increment') //Committing the mutations. Can be asynchronous.
    }
  }
})

Eylem işleyicileri ( artış) ), mağaza örneğinde aynı yöntem / özellik kümesini ortaya çıkaran bir bağlam nesnesi alır, böylece bir mutasyon işlemek için context.commit öğesini çağırabilir veya context.state ve context.getters aracılığıyla duruma ve alıcılara erişebilirsiniz.

Feragatname - Sadece vuejs kullanmaya başladım, bu yüzden bu sadece tasarım amacını tahmin ediyorum.

Zaman makinesinde hata ayıklama, durumun anlık görüntülerini kullanır ve eylemlerin ve mutasyonların zaman çizelgesini gösterir. Teoride actions, mutasyonu eşzamanlı olarak tanımlamak için devlet belirleyicileri ve alıcıların bir kaydıyla birlikte olabilirdik . Ama sonra:

• Ayarlayıcılara ve alıcılara neden olan saf olmayan girdilerimiz (async sonuçları) olurdu. Bunu mantıklı bir şekilde takip etmek zor olabilir ve farklı asenkron ayarlayıcılar ve alıcılar şaşırtıcı bir şekilde etkileşime girebilir. Bu yine de olabilirmutations işlemlerde ancak daha sonra işlemlerde bir yarış koşulu olması yerine işlemin iyileştirilmesi gerektiğini söyleyebiliriz. Bir eylem içindeki anonim mutasyonlar, bu tür hataları daha kolay bir şekilde yeniden ortaya çıkarabilir çünkü asenkron programlama kırılgan ve zordur.
• Durum değişikliklerinin adı olmayacağından işlem günlüğünün okunması zor olurdu. Çok daha fazla kod benzeri ve daha az İngilizce olurdu, mutasyonların mantıksal gruplarını kaçırdı.
• Mutasyon fonksiyon çağrısından önce ve sonra, eşzamanlı olarak tanımlanmış fark noktalarının olduğu yerlerin aksine, bir veri nesnesi üzerindeki herhangi bir mutasyonu kaydeden enstrümanda daha zor ve daha az performans gösterebilir. Ne kadar büyük bir problem olduğundan emin değilim.

Aşağıdaki işlem günlüğünü adlandırılmış mutasyonlarla karşılaştırın.

Action: FetchNewsStories
Mutation: SetFetchingNewsStories
Action: FetchNewsStories [continuation]
Mutation: DoneFetchingNewsStories([...])

Adlandırılmış bir mutasyonu olmayan bir işlem günlüğüyle:

Action: FetchNewsStories
Mutation: state.isFetching = true;
Action: FetchNewsStories [continuation]
Mutation: state.isFetching = false;
Mutation: state.listOfStories = [...]

Umarım bu örnekten eylemler içinde zaman uyumsuzluk ve anonim mutasyonda potansiyel ilave karmaşıklığı tahmin edebilirsiniz.

https://vuex.vuejs.org/en/mutations.html

Şimdi biz app hata ayıklama ve devtool mutasyon günlükleri bakarak düşünün. Kaydedilen her mutasyon için, devtoolun durumun "önce" ve "sonra" anlık görüntülerini yakalaması gerekir. Bununla birlikte, yukarıdaki örnek mutasyon içindeki eşzamansız geri arama bunu imkansız hale getirir: mutasyon tamamlandığında geri çağrı henüz çağrılmaz ve devtoolun geri çağrının gerçekte ne zaman çağrılacağını bilmesinin bir yolu yoktur - geri çağrıda gerçekleştirilen herhangi bir durum mutasyonu aslında izlenemez!

Mutasyonlar:

Can update the state. (Having the Authorization to change the state).

Hareketler:

Actions are used to tell "which mutation should be triggered"

Redux Yolunda

Mutations are Reducers
Actions are Actions

Neden İkisi?

Uygulama büyüdüğünde, kodlama ve satırlar artacaktır, Mutasyonların durumunu değiştirmek için tek yetki olduğu için mutasyonlarda değil, Eylemler'deki mantığı işlemeniz gerekir, mümkün olduğunca temiz olmalıdır.

Bu da beni şaşırttı, bu yüzden basit bir demo yaptım.

component.vue

<template>
    <div id="app">
        <h6>Logging with Action vs Mutation</h6>
        <p>{{count}}</p>
        <p>
            <button @click="mutateCountWithAsyncDelay()">Mutate Count directly with delay</button>
        </p>
        <p>
            <button @click="updateCountViaAsyncAction()">Update Count via action, but with delay</button>
        </p>
        <p>Note that when the mutation handles the asynchronous action, the "log" in console is broken.</p>
        <p>When mutations are separated to only update data while the action handles the asynchronous business
            logic, the log works the log works</p>
    </div>
</template>

<script>

        export default {
                name: 'app',

                methods: {

                        //WRONG
                        mutateCountWithAsyncDelay(){
                                this.$store.commit('mutateCountWithAsyncDelay');
                        },

                        //RIGHT
                        updateCountViaAsyncAction(){
                                this.$store.dispatch('updateCountAsync')
                        }
                },

                computed: {
                        count: function(){
                                return this.$store.state.count;
                        },
                }

        }
</script>

store.js

import 'es6-promise/auto'
import Vuex from 'vuex'
import Vue from 'vue';

Vue.use(Vuex);

const myStore = new Vuex.Store({
    state: {
        count: 0,
    },
    mutations: {

        //The WRONG way
        mutateCountWithAsyncDelay (state) {
            var log1;
            var log2;

            //Capture Before Value
            log1 = state.count;

            //Simulate delay from a fetch or something
            setTimeout(() => {
                state.count++
            }, 1000);

            //Capture After Value
            log2 = state.count;

            //Async in mutation screws up the log
            console.log(`Starting Count: ${log1}`); //NRHG
            console.log(`Ending Count: ${log2}`); //NRHG
        },

        //The RIGHT way
        mutateCount (state) {
            var log1;
            var log2;

            //Capture Before Value
            log1 = state.count;

            //Mutation does nothing but update data
            state.count++;

            //Capture After Value
            log2 = state.count;

            //Changes logged correctly
            console.log(`Starting Count: ${log1}`); //NRHG
            console.log(`Ending Count: ${log2}`); //NRHG
        }
    },

    actions: {

        //This action performs its async work then commits the RIGHT mutation
        updateCountAsync(context){
            setTimeout(() => {
                context.commit('mutateCount');
            }, 1000);
        }
    },
});

export default myStore;

Bunu araştırdıktan sonra, geldiğim sonuç mutasyonların sadece endişeleri daha iyi ayırmak ve güncellenen verilerden önce ve sonra günlüğe kaydetmeyi iyileştirmek için verileri değiştirmeye odaklanan bir sözleşmedir. Eylemler, daha yüksek düzey mantığı işleyen ve daha sonra mutasyonları uygun şekilde çağıran bir soyutlama katmanıdır.

1. belgelerden :

Eylemler mutasyonlara benzer, farklılıklar şöyledir:

• Devleti mutasyona uğratmak yerine eylemler mutasyonlar yapar.
• Eylemler keyfi eşzamansız işlemler içerebilir.

Eylemler eşzamansız işlemler içerebilir, ancak mutasyon olamaz.

2. mutasyonu çağırıyoruz, doğrudan durumu değiştirebiliriz. ve aynı zamanda devletleri şu şekilde değiştirme eyleminde bulunabiliriz:

actions: {
  increment (store) {
    // do whatever ... then change the state
    store.dispatch('MUTATION_NAME')
  }
}

Eylemler başka şeyleri işlemek için tasarlanmıştır, orada birçok şey yapabiliriz (eşzamansız işlemleri kullanabiliriz) ve sonra mutasyon göndererek durumu değiştirebiliriz.

Çünkü mutasyonlar olmadan devlet yok! İşe alındığında - durumu öngörülebilir bir şekilde değiştiren bir mantık parçası yürütülür. Mutasyonlar durumu ayarlamanın veya değiştirmenin tek yoludur (bu nedenle doğrudan değişiklik yoktur!) Ve ayrıca - senkron olmalıdırlar. Bu çözüm çok önemli bir işlevsellik sağlar: mutasyonlar devtoollere giriş yapıyor. Ve bu size harika bir okunabilirlik ve öngörülebilirlik sağlar!

Bir şey daha - eylemler. Söylendiği gibi - eylemler mutasyonlar yapar. Bu yüzden mağazayı değiştirmezler ve bunların senkronize olmasına gerek yoktur. Ancak, fazladan bir asenkron mantığı yönetebilirler!

Sadece actionsaramak için fazladan bir katmana sahip olmak gereksiz gibi görünebilir mutations, örneğin:

const actions = {
  logout: ({ commit }) => {
    commit("setToken", null);
  }
};

const mutations = {
  setToken: (state, token) => {
    state.token = token;
  }
};

Peki çağrıları actionsçağırıyorsanız logout, neden mutasyonun kendisini çağırmıyorsunuz ?

Bir eylemin tüm fikri, bir eylemin içinden birden fazla mutasyon çağırmak veya bir Ajax isteği veya hayal edebileceğiniz her türlü asenkron mantık yapmaktır.

Sonunda birden fazla ağ isteği yapan ve sonunda birçok farklı mutasyon çağıran eylemlerimiz olabilir.

Bizim dan çok karmaşıklık olarak şeyler denemek Yani Vuex.Store()bizim gibi mümkün actionsve bu yapraklar bizim mutations, stateve getterssüpürge ve basit ve Vue gibi kütüphaneler yapar ve popüler tepki modülerliği tür uygun düşer.

Vuex'i yaklaşık 3 yıldır profesyonel olarak kullanıyorum ve işte eylemler ve mutasyonlar arasındaki temel farklılıklar, bunları birlikte nasıl kullanmanızdan nasıl faydalanabileceğiniz ve eğer hayatınızı nasıl daha zor hale getirebileceğiniz hakkında düşündüğüm şey iyi kullanma.

Vuex'in temel amacı, uygulamanızın davranışını kontrol etmek için yeni bir model sunmaktır: Reaktivite. Fikir, uygulamanızın durumunun düzenlenmesini özel bir nesneye (bir mağazaya) boşaltmaktır. Bileşenlerinizi kendi mağazalarında kullanılacak mağaza verilerine doğrudan bağlamak için yöntemler sağlar. Bu, bileşenlerinizin işlerine odaklanmasını sağlar: kullanıcılarınıza sunmak için bir şablon, stil ve temel bileşen davranışı tanımlama. Bu arada, mağaza ağır veri yükünü idare eder.

Yine de bu modelin tek avantajı bu değil. Depoların, uygulamanızın tamamı için tek bir veri kaynağı olması, bu verilerin birçok bileşende yeniden kullanılabilirliği için büyük bir potansiyel sunar. Bu, bileşenler arası iletişim sorununu ele almaya çalışan ilk model değildir, ancak parladığı yerde, bileşenlerinizi temel olarak bu paylaşılan verilerin durumunu değiştirmesini yasaklayarak uygulamanıza çok güvenli bir davranış uygulamaya zorlamasıdır. ve bunun yerine değişiklik istemek için "genel uç noktaları" kullanmaya zorlayın.

Temel fikir şudur:

• Mağazanın, doğrudan bileşenler tarafından doğrudan erişilmemesi gereken dahili bir durumu vardır (mapState etkin bir şekilde yasaklanmıştır)
• Mağaza, dahili duruma eşzamanlı modifikasyon olan mutasyonlara sahiptir. Bir mutasyonun tek işi durumu değiştirmektir. Sadece bir eylemden çağrılmalıdırlar. Devlete olan şeyleri tanımlamak için adlandırılmalıdırlar (ORDER_CANCELED, ORDER_CREATED). Onları kısa ve tatlı tutun. Vue Devtools tarayıcı uzantısını kullanarak bunlara adım atabilirsiniz (hata ayıklamak için de harika!)
• Mağazanın ayrıca zaman uyumsuz olması veya bir söz vermesi gereken eylemleri vardır. Bunlar, uygulamanın durumunu değiştirmek isteyecekleri zaman bileşenlerinizin arayacağı eylemlerdir. İş odaklı eylemlerle adlandırılmalıdırlar (fiiller, yani cancelOrder, createOrder). Bu, isteklerinizi doğruladığınız ve gönderdiğiniz yerdir. Durumu değiştirmek gerekirse, her eylem farklı adımlarda farklı taahhütler çağırabilir.
• Son olarak, mağaza, eyaletinizi bileşenlerinize maruz bırakmak için kullandığınız alıcılara sahiptir. Uygulamanız genişledikçe bunların birçok bileşende yoğun bir şekilde kullanılmasını bekleyin. Vuex, işe yaramaz hesaplama döngülerinden kaçınmak için alıcıları ağır bir şekilde önbelleğe alır (alıcıya parametre eklemediğiniz sürece - parametreleri kullanmamaya çalışın), bu yüzden bunları yoğun bir şekilde kullanmaktan çekinmeyin. Uygulamanın şu anda hangi durumda olduğunu mümkün olduğunca yakın tanımlayan adlar verdiğinizden emin olun.

Bununla birlikte sihir, uygulamamızı bu şekilde tasarlamaya başladığımızda başlar. Örneğin:

• Kullanıcıya bu siparişleri silme imkanı sunan bir sipariş listesi sunan bir bileşene sahibiz
• Bileşenler, kimliğine sahip bir nesne dizisi olan bir mağaza alıcısını (deletableOrders) eşledi
• Bileşenin her bir sipariş satırında bir düğmesi vardır ve tıklaması, sipariş nesnesini kendisine ileten bir mağaza eylemiyle (deleteOrder) eşlenir (hatırlayacağımız, mağazanın listesinden gelir)
• Store deleteOrder eylemi aşağıdakileri yapar:
  • silme işlemini doğrular
  • geçici olarak silme sırasını saklar
  • siparişle birlikte ORDER_DELETED mutasyonunu yapar
  • siparişi gerçekten silmek için API çağrısını gönderir (evet, durumu değiştirdikten SONRA!)
  • çağrının bitmesini bekler (durum zaten güncellenir) ve başarısızlık durumunda ORDER_DELETE_FAILED mutasyonunu daha önce tuttuğumuz sırayla çağırırız.
• ORDER_DELETED mutasyonu, verilen siparişi silinebilir siparişler listesinden kaldıracak (alıcıyı güncelleyecek)
• ORDER_DELETE_FAILED mutasyonu basitçe geri koyar ve hatayı bildirmek için durumu değiştirir (başka bir bileşen, hata bildirimi, ne zaman kendini göstereceğini bilmek için bu durumu izler)

Sonunda, "reaktif" kabul edilen bir kullanıcı deneyimimiz var. Kullanıcı açısından, öğe hemen silindi. Çoğu zaman, uç noktalarımızın sadece çalışmasını bekliyoruz, bu yüzden bu mükemmel. Başarısız olduğunda, başvurumuzun nasıl tepki vereceği konusunda hala bazı kontrollerimiz var , çünkü ön uç başvurumuzun durumunun endişesini gerçek verilerle başarıyla ayırdık.

Her zaman bir mağazaya ihtiyacınız yok, dikkat edin. Şöyle bir mağaza yazdığınızı fark ederseniz:

export default {
  state: {
    orders: []
  },
  mutations: {
    ADD_ORDER (state, order) {
       state.orders.push(order)
    },
    DELETE_ORDER (state, orderToDelete) {
       state.orders = state.orders.filter(order => order.id !== orderToDelete.id)
    }
  },
  actions: {
    addOrder ({commit}, order) {
      commit('ADD_ORDER', order)
    },
    deleteOrder ({commit}, order) {
      commit('DELETE_ORDER', order)
    }
  },
  getters: {
    orders: state => state.orders
  }
}

Bana göre, mağazayı sadece bir veri deposu olarak kullanıyorsunuz ve belki de uygulamanızın tepki verdiği değişkenlerin kontrolünü ele geçirmesine izin vermeyerek belki de reaktivite yönünü kaçırıyorsunuz. Temel olarak, bileşenlerinizde yazılan bazı kod satırlarını mağazalarınıza boşaltabilir ve muhtemelen yükleyebilirsiniz.