Redux ve bir durum makinesi (örneğin xstate) arasındaki gerçek fark nedir?

Orta karmaşıklıkta bir ön uç uygulamasının araştırılması üzerinde çalışıyorum. Şu anda tamamen javascript ile yazılmıştır, bu uygulamanın birkaç ana bölümünü birbirine bağlayan birçok farklı olay tabanlı mesaja sahiptir.

Daha fazla yeniden düzenleme kapsamında bu uygulama için bir tür devlet konteyneri uygulamaya ihtiyacımız olduğuna karar verdik. Daha önce redux ve ngrx store ile bazı deneyimlerim vardı (aslında aynı prensipleri takip ediyor).

Redux bizim için bir seçenektir, ancak geliştiricilerden biri durum makinesi tabanlı bir kitaplık, özellikle xstate kitaplığı kullanmayı önerdi .

Xstate ile hiç çalışmadım, bu yüzden onu ilginç buldum ve belgeleri okumaya ve farklı örneklere bakmaya başladım. Umut verici ve güçlü görünüyordu, ancak bir noktada anladım ki onunla yeniden düzenleme arasında önemli bir fark görmedim.

Xstate ve redux'u karşılaştıran bir cevap veya başka herhangi bir bilgi bulmak için saatler harcadım. " Redux'tan bir durum makinesine geçiş" gibi makaleler veya redux ve xstate'i birlikte kullanmaya odaklanan kütüphanelere bağlantılar (oldukça tuhaf) dışında net bir bilgi bulamadım .

Birisi farkı tanımlayabilir veya geliştiricilerin xstate'i ne zaman seçmesi gerektiğini söyleyebilirse - hoş geldiniz.

XState'i ben yarattım, ancak size birini diğerinin üzerinde kullanıp kullanmayacağınızı söylemeyeceğim; bu takımınıza bağlıdır. Bunun yerine, bazı temel farklılıkları vurgulamaya çalışacağım.

• Redux, esasen olayların ( Redux'da eylemler olarak adlandırılır ) durumu güncelleyen bir indirgeyiciye gönderildiği bir durum kapsayıcısıdır .
• XState da durum kap, ancak sonlu durum ayırır (örneğin "loading", "success") "sonsuz durum" veya bağlamdan (örneğin, items: [...]).
• Redux, redüktörlerinizi nasıl tanımlayacağınızı dikte etmez. Mevcut durum ve olay (eylem) verildiğinde sonraki durumu döndüren düz işlevlerdir.
• XState, "kuralları olan bir indirgeyicidir" - olaylar nedeniyle sonlu durumlar arasındaki yasal geçişleri ve ayrıca bir geçişte (veya bir duruma giriş / çıkışta) hangi eylemlerin yürütülmesi gerektiğini tanımlarsınız
• Redux, yan etkilerle başa çıkmak için yerleşik bir yola sahip değildir . Redux-thunk, redux-saga gibi birçok topluluk seçeneği var.
• XState eylemleri (yan etkileri) bildirime dayalı ve açık hale getirir - bunlar Stateher geçişte döndürülen nesnenin parçasıdır (mevcut durum + olay).
• Redux şu anda durumlar arasındaki geçişleri görselleştirmenin bir yolu yoktur, çünkü sonlu ve sonsuz durum arasında ayrım yapmaz.
• XState bir görselleştiriciye sahiptir: https://statecharts.github.io/xstate-viz, bu, bildirim niteliği nedeniyle uygulanabilir.
• Redux redüktörlerinde temsil edilen örtük mantık / davranış bildirimsel olarak serileştirilemez (örneğin, JSON'da)
• Mantığı / davranışı temsil eden XState'in makine tanımları, JSON'a serileştirilebilir ve JSON'dan okunabilir. Bu, davranışı çok taşınabilir ve harici araçlar tarafından yapılandırılabilir hale getirir.
• Redux, kesinlikle bir durum makinesi değildir.
• XState, W3C SCXML spesifikasyonuna sıkı sıkıya bağlıdır: https://www.w3.org/TR/scxml/
• Redux, imkansız durumları manuel olarak önlemek için geliştiriciye güvenir.
• XState, imkansız durumları önleyen ve statik olarak analiz edilebilen olayların işlenmesine yönelik sınırları doğal olarak tanımlamak için statecharts kullanır.
• Redux, tek bir "küresel" atom deposunun kullanılmasını teşvik eder.
• XState, birbirleriyle iletişim kuran birçok hiyerarşik durum şeması / "hizmet" örneğinin olabileceği Aktör modeli benzeri bir yaklaşımın kullanılmasını teşvik eder.

Bu hafta dokümanlara daha fazla temel farklılık ekleyeceğim.

Durum makinesi size Tek yönlü veri akışına sahip olmanızı söylemiyor (zorlamıyor). Veri akışı ile ilgisi yoktur. Daha çok durum değişikliklerini sınırlamak ve durum geçişleri ile ilgilidir . Bu nedenle, genellikle uygulamanın yalnızca bazı bölümleri, yalnızca ve yalnızca bazı durum değişikliklerini kısıtlamanız / yasaklamanız gerekiyorsa ve geçişlerle ilgileniyorsanız , Durum makineleriyle tasarlanır .

Durum makinelerinde, herhangi bir nedenle (harici API bağımlılığı vb.), Uygulamanın kısıtlamalar nedeniyle başka bir duruma geçemeyeceği bir durumda kilitlenme şansı varsa, onu çözmeniz gerektiğine dikkat edin.

Ancak , durum geçişleri yerine yalnızca son uygulama durumuyla ilgileniyorsanız ve durum kısıtlamaları önemli değilse, o zaman durum makinesini kullanmasanız ve doğrudan durumun kendisini güncellemeniz daha iyi olur ( yine de durumu bir Singleton sınıf güncellemesine kaydırabilirsiniz. Eylem sınıfları ).

Öte yandan Redux , Tek Yönlü mimari çerçevesidir . Tek yönlü mimariler, sizi tek yönlü veri akışına sahip olmaya zorlar. Redux'da şununla başlar User->View->(Action)->Store->Reducer->(Middleware)->Store->(State)->View. State Machines gibi, Redux'daki Middlewares ile yan etkileri tetikleyebilirsiniz. İsterseniz Durum geçişlerini kısıtlayabilir / yasaklayabilirsiniz. Durum Makinesi'nden farklı olarak , Redux tek yönlü veri akışını zorlar, saf ! indirgeyici işlevler, değişmez durum nesneleri, tek gözlemlenebilir uygulama durumu.