MİMARİ ÖRÜNTÜLER

Flux Mimari Örüntüsü

UI Mimari örüntülerini incelediğimizde karşımıza MVC, MVP ve benzer örüntülerin çıktığını görürüz. Bu yazımda React ve Redux ile popülerleşen Flux mimari yapısını anlatmaya çalışacağım.

4 min readNov 2, 2020

Flux Mimari tüm uygulama state tek bir yerden erişecek şekilde Global bir Obje olmasını , objeden her UI bileşeninin Read (okuma) yapabilmesini ama yazarken bunun kontrollü bir şekilde tek yönlü Dispatcher üzerinden geçen komutlar ile yapılmasını sağlar.

Yukarıdaki resimde görüleceği gibi UI etkileşimi ve data akışı tek yönlü olacak şekilde geliştirilmiştir.

Dispatcher sadece Action tarafından tetiklenebilir.
Store sadece Dispatcher tarafından tetiklenebilir.
View sadece Store tarafından (Not: kendi iç state değişimleri ve Routing değişimleri hariç)

Flux Mimarisinin Bileşenleri

Flux 4 soyutlama bileşeninden oluşur.

View: Veriyi gösteren UI bileşenleri, kullanıcının bu bileşenler ile etkileşimini sağlayan parçadır. Gerçekleşen herhangi bir kullanıcı etkileşimini Aksiyonlar ile Dispatcher iletir. (React, Vue, Svelte)

Action: Aksiyonlar kullanıcının veya client yer alan programın yaptığı sistemin state değiştiren komutlardır. Bunlar Dispatcher tetikler bunu söyle düşünebiliriz. Ana amacı Store değiştirmek olan her türlü aksiyon

Ekranda ilk açılırken sunucudan veri çekme işlemide
Sunucudan Veri Çekilmesini Sağlatmak Bir Aksiyondur.
Ekrandaki bir düğmeye basıp bazı bileşenlerin gizlenmesini ve gösterilmesi için
Mevcut UI State değiştirmek için yapılan işlemler

Dispatcher: Merkezi bir hub gibi çalışır. Store kendisine register edilmiş callback çağırmaktan sorumludur. Olabildiğince basit ve az kod içerir. İş mantığını içermez sadece ilgili callback çağırır.

Store: Tüm uygulamanın state(durumunu) ve olası geçebileceği durumların neler olduğunu içerir. Tüm modellerin durumları arasında geçişlerin nasıl gerçekleşeceğinin mantığı Store içerisinde yer alır.

Flux Gerçekleştirimleri (Implementation)

React → Redux, MobX
Vue → VueX
Angular → NgRx

Redux İçin Örnek Kullanım

Neden Redux Gibi Mekanizmaya İhtiyaç Var ?

Birbirinden bağımsız bileşenlerin uygulama state ve birbirleri ile etkileşimini soyutlayıp, Pure bileşenler geliştirebilmesi, uygulama bileşen bağımlılık karmaşıklığını azaltmak ve veri değişimlerindeki hataları ortadan kaldırmak için Redux benzeri State yönetim araçlarına ihtiyaç var.

Global: Her yerden Erişilebilen State (Okuma/Read)
State Değişimi Kontrollü: Store State değişimi tek yönden gerçekleşiyor Action → Dispatcher → Store şeklinde

Global veriye erişirken bu state immutable olması istenir.

Redux is a small library that represents state as (immutable) objects. And new states by passing the current state through pure functions to create an entirely new object/application states.

Özetle Store obje kullanacak View verdiğinde objenin Deep clone olan referans bağlantısı olmayan bir versiyonunu veriyor . Bu sayede Store asıl obje değişmemiş oluyor.

Reducer Sync İşlemler için Güvenilir Peki Async İşlemler için Güvenilir Mi ?

Async işlemler için fonksiyonların güvenilir olması için 2 soru sorulmalı

Pure Function Mı ?
Side Effect Var mı ?

Saf(pure) fonksiyonlar, fonksiyonel programlamada önemli bir yer teşkil eder, Concurrency (eş-zamanlılık), test edilebilir kod, tahmin edilebilir kod, deterministik bir kod geliştirmek için pure fonksiyonlar oluşturmanız gerekir.

non-determinism = parallel processing + mutable state(değişken durum)

Bu konuda daha detaylı bilgi sahibi olmak için → Saf (Pure) Fonksiyon Nedir? yazımı okuyun.

Store Reducer Async İşler İçin Nasıl Pure Hale Getirebiliriz ? → Middleware

Reducer Async Aksiyonların side effectlerinden Middleware ile koruyabiliriz Bunun için kullanılan 2 tip middleware bulunur: Redux Thunk and Redux Saga.

Bunlardan bir tanesine değinecek olursak Redux Thunk kendisine gönderilen action içerisinde promise zinciri ile arka arkaya yapılan async işlemler varsa , burdan dönen değer payload ne zamanki bir fonksiyon yerine obje ise o taktirde reducer çağırarak burada Async çağrım işlemini yönetir. Örneğin async bir action nasıl gerçekleşiyor incelersek …

Foo verisi sunucudan istenmeden PENDING state geçirilip sonrasında veri istemesi başlatılır.
Sunucudan veri gelirse FULFILLED şekline dönüştürülür.
Sunucundan herhangi bir hata gelme durumunda ise REJECTED durumuna dönüştürülür.

Burda tüm benzer Async Call benzer Action kodları Foo, Doo, Soo vs her birinde tekrar tekrar yazmak yerine ne yapılabilir ?

redux-promise-middleware kullanılabilir örneğin… Burda verdiğiniz ana state kendisi sonlarına _PENDING, _FULFILLED, _REJECTED ekleyerek sizin tekrar tekrar aynı kodları yazmanızı engelleyecektir.

Örnek Store Oluşturma

Store Folder yapısını 2 şekilde yapabilirsiniz. 1nci yöntem büyük mimariler için daha uygun olsada 2nci yöntem birbiri ile ilgili bileşenleri tek bir .js içerisinde görmenin avantajını yaşarsınız. 2 yöntemden birisini seçebilirsiniz yani …