Flux Nedir ? React nasıl bir göbek bağı var ?
Merhaba sevgili yazılım aşıkları,
React kütüphanesi state üzerindeki değişiklikleri view tarafında otomatik olarak render ettiğinden bahsetmiştim. En iyi yaptığı işin datayı Dom tarafına kontrollü bir şekilde aktarmak olduğundan da bahsetmiştim. Bu işlemleri kusursuz bir şekilde yapabiliyor olması biz proje geliştiriciler için yeterli değil. Çünkü uygulama geliştirirken tek ihtiyacımız bu değil. Bizim state yönetimi üzerinde de hakimiyetimizin olması gerekiyor. Bu aşamada Flux, Redux gibi yardımcılarımız var.
Flux, Js projeleri içerisinde durum yönetimi sağlamak için facebook tarafından geliştirilen bir proje. Yani React’la tek bağlantısı ikisinde facebook tarafından geliştiriliyor olması.
Tabi başka ihtiyaç duyduğumuz olmazsa olmaz dediğimiz noktalarda var. Bu konuları ileri tarihli yazılarımın başlığını oluşturacak. Şu an konuyu saptırmak istemiyorum :)
State yönetimi için Redux bu gün için iyi bir çözüm diye düşünüyorum. Ben kodlarımı Redux kullanarak geliştirmeyi planlıyorum. Fakat Redux’dan önce Flux anlatmak istiyorum. Flux konusunda bilgimizin olması Redux’u daha iyi anlamamızı sağlayacak.
Bu Flux Dedikleri Nedir ? Neden Fulux’a İhtiyaç Duyduk ?
Facebook tarafından React ile birlikte geliştirmeye başlandı. Flux projesinin amacı kontrolsüz bir şekilde uygulama içersine akan arayüz verilerinin yönetimini sağlamaktır. Çözüm önerisi ise; Tek yönlü veri akışıdır.
Flux dedikleri bu kadar :) Ama biraz daha ayrıntılandırmakta fayda var diye düşünüyorum.
Neden İhtiyaç Duyuldu?
Eskiden facebook simgesi üzerinde bildirim olduğu görünüyordu. Fakat bildirime tıklandığında bildirimin ayrıntısı gözükmüyordu. Mesaj bildirimine tıklanıyor ama mesaj yok. Uygulama üzerindeki güncellemelerle bu bildirim hatasının önüne geçiliyor. Ama bir süre sonra yine bu hata ortaya çıkıyordu. Bu sorun için kesin bir çözüm arayışına girildi. Kesin çözüm arayışının karşılığı; “Predictable state management” yani tahmin edilebilir bir state yönetimi.
Peki Problem Neydi?
Facebook ekibinin tanımladığı temel problem, arayüz verilerinin uygulama üzerinden kontrolsüz bir şekilde akıyor olmasıydı.
Kullanıcıya gösterilecek data’nın model üzerinde tutulduğu ve kullanıcıya view katmanı üzerinden sunum yapılan geleneksel yazılım mimarilerinde model ile view arasında, view ile model arasında aynı zamanda model ile model arasında veri transferi yapılabiliyor. Durum böyle olunca kullanıcı etkileşimleri başka değişiklikleri tetikleyebiliyor.Tetiklenen süreç o an çalışıp değişiklikler view tarafına yansıtılıyor. Böyle bir mimaride uygulama büyüdükçe veri akışının hatalarını yakalamak zorlaşıyor.
Peki Flux’ın Bizlere Sunduğu Çözüm Ne?
Geliştirilen yeni mimaride tek yönlü veri akışı kullanıldı. Bu mimariye göre ne zaman bir işlem yapılmak istense veri akışı baştan sona doğru olacaktı. Bu sayede karmaşıklığın önüne geçilecekti.
Sorunun ne olduğunu öğrendik. Sorun için çözümün ne olduğunu öğrendik. Artık bu sorun için geliştirilen Flux projesinin çalışma mantığını inceleyelim.
Flux mimarisini 3 bölümde incelemeyi planlıyorum Bunlar Flux Yapısı, Kurulum ve Veri akışı
Flux Yapısı
Action Creator: Flux mimarisi içerisinde bir işlem başlatmak isteğimizde action creator’a başvururuz. Action creator bizden type ve payload bilgisi bekler. Type işlemin türünü belli eder. Genelde sabitler.js gibi bir dosya içerisinde belirlenir. Bu sayede Uygulama içersinde yapılabileceklerin hepsini bu “doya” üzerinden ulaşabiliriz. Payload ise o işlemin taşıdığı data diyebiliriz. Genelde object taşır. Action creator’a gönderilen data’yı şu şekilde gösterebiliriz. {type:KULLANICI_LİSTELE, payload:{listelendimi:EVET}}
Action creator’la bir işlem başlatıldığında bu işlem Flux mimarisinin bir sonraki elemanı olan dispatcher’a otomatik olarak aktarılır.
Dispatcher: Action Creator’dan bir işlem geldiğinde bu işlemi bir sonraki adıma yani storlara yönlendirmekle görevlidir. Bu işlem için Dispatcher tüm storların listesini barındırır. Storlar arasında bir bağımlılık varsa önce şu store daha sonra bu store gibi dispatcherın waitFor() methodu ile ayarlanabilir.
Bu aşamada dikkat edilmesi gereken bir nokta var. Dispatcher kendisine gelen işlemi tüm store listesine gönderir. Storlar kendi içerisinde işlem türünü kontrol etmesi gerekir ve kendisine ait bir işlem ise ilgili state güncellemesini gerçekleştirir.
Stores: Uygulama içerisindeki tüm statelerin tutulduğu alandır. State güncelleme kuralları da burada tutulur.
State, React componentleri içerisinde tutulan ve sadece kendileri tarafında yönetilen bir obje. Yardımcı bir araç kullanılmadığında büyük uygulamalarda yönetimi zorlaşan bir yapı. Flux, Redux gibi yapılarla yönetimi kontrol altına alınıyor.
Uygulama içerisinde direk olarak state güncellemesi yapamıyoruz. Store mutlaka kendinin haberdar edilmesini istiyor. Gerekli görülürse kendisi state güncellemesi yapıyor.
Dispatcher uygulama içerisindeki tüm storlara gelen isteği yönlendirdiği için storlar kedi içerisinde kedisine gelen istekle ilgili işlem yapmam gerekiyor mu? Sorusuna cevap vermesi gerekiyor. Eğer işlem yapması gerekiyorsa ilgili state güncelleme işlemini gerçekleştiriyor.
State güncellenirse güncelleme event ı yaratılır. Bu event ın görevi Controller view’e state güncellendi bilgisi göndermektir.
View: Bu bölümde View ve Controller View kavramlarıyla karşılaşıyoruz. View ler kendisine gelen data yı kullanıcılara göstermekle görevlidir. Controller Viewler ise store ile view arasında ara bulucu gibidir. Store, state değişti bilgisi gönderdiğinde güncel state i alır ve alt view lere ulaştırır.
Flux Kurulum Aşaması
Bu bölüm uygulama başlatıldığında bir kez çalışır.
- store ile dispatcher arasındaki haberleşme için bağlantı kurulur.
- Ardından controller view ler store lardan en son state leri isterler.
3. controller view lere güncel state ler geldiğinde alt view lere state aktarılır.
4. Ayrıca controller view ler store lara her değişiklik olduğunda haberdar olmak istediğini bildirir.
Flux Veri Akışı
Kurulum aşamasını tamamladıktan sora sayfa Dom üzerine aktarılmış oluyor. Artık sayfa kullanıcı ile etkileşime geçmeye hazır. Yaşasın :)
Bir kullanıcı etkileşimi ile veri akışını başlattığımızda aşağıdaki senaryo oynanmaya başlıyor.
- View, Action creator a bir aksiyon hazırlamasını söylüyor.
2. Action creator işlemi biçimlendiriyor ve dispatcher a gönderiyor.
3. Dispatcher eylemi sırayla store lara gönderiyor. Her store tüm eylemleri dinler. Gelen eylem için işlem yapması gerekiyorsa state güncelleme işlemini gerçekleştirir.
4. State değiştirdikten sonra store bir event fırlatır ve değişiklikten controller view haberdar olmuş olur.
5. State güncelleme haberi geldiğinde controller view yeni state bilgisini ister.
6. Controller view güncel state’ı aldığında altındaki view lere güncel state i gönderir ve gerekli güncellemeleri yapmalarını ister.
Kendi anladığım kadarıyla flux mimarisini sizlere anlatmaya çalıştım. Projelerimi Redux State Management mimarisiyle geliştirmeyi düşündüğüm için bu yazının örnek projesi yok. Ama istek olursa hazırlamaya çalışırım. Bir sonraki yazım Redux Nedir? Redux nedir yazısının örnek proje dosyasını da paylaşacağım. Daha Sonra React Native tarafına geçmeyi planlıyorum. React Native yazıları bu yazı dizisindeki gibi işin felsefesinden değil uygulama ağırlıklı devam edecek. React kütüphanesinin inceliklerine bu yazı dizi içerisinde girmemeye çalıştım. React Native içerisinde bu inceliklere de yer vermeyi planlıyorum. Bu yazı dizileri daha çok React ile uygulamarımı geçiştirsem mi geliştirmemem mi? sorularını netleştirmemize yardımcı olabilmek için idi.
