Flux mimarisinin temeli nedir?

05 Tem 07:21

Uzun süre React Native projelerinde state management battle’ları yaşadım. Önce Redux’un karmaşasına girdim, sonra Context API’yi gardıroba attım, derken 2023’te ilk Flux uygulamamda çatladı. Malum, Native projesinde gerçekten karmaşık bir state’le boğuşuyorduk: kullanıcı oturumundan, önbelleğe alınmış verilerden, offline mod durumundan oluşan bir mayın tarlası gibiydi. Redux toolkit’i kullanıyorduk, ama orta katmanda sürekli selector’lar birbirine dolanıyordu. Sonra ekibim Flux mimarisini (özellikle Verve’sı veya bunun türevlerini) denemeye karar verdi. Temelde Flux’tan kastettiğinizin “yalnızca state akışı” mı yoksa “state’in kendisinin” mimarisi mi olduğu önemli. Flux; Action → Dispatcher → Store (state) → View (render) hattını kurala bağlıyor, yani state’in nerede saklandığına ve nasıl değiştiğine dair bir sözleşme sunuyor. API çağırmaları bile bir action olarak kaydediyor, sonuçta state’e aktarılıyordu. Bu sayede projemizdeki karman çorman asenkron durumlar bile tek bir kaynaktan yönetilmeye başladı. Örn: network request’i bir action’dı, başarısız olması bile store’a “request_failed” flag’i olarak yansıyordu. Bu katı yapı sayesinde debugging’i saatlerce değil dakikalarca yaptık. Artıları mı? Öncelikle debug edilebilirlik inanılmaz arttı. Time-travel debugging’i Flux’un store’ları sayesinde neredeyse otomatik hale geldi. State’in her değişikliği loglanabiliyordu, hatta Redux DevTools’a benzer bir sistem kurduk. Ayrıca takım içinde state’in nerede ve nasıl değiştiğine dair tartışma azaldı, çünkü herkes dispatcher’ın geçtiği kurallara uymak zorundaydı. Eksilerine gelince; sürekli action ve reducer tanımlamak başlangıçta biraz eziyet gibiydi, özellikle küçük projelerde. Ayrıca event-driven mimariyi benimsemek herkes için kolay olmuyor, mesela junior geliştiriciler store’a direkt müdahale etmek istiyorlardı – Flux buna izin vermiyor. Projemizde Flux’u kısmi olarak kullandık: API’leri ve offline modu Flux’a bağladık, ama lokal state için Context API’yi bıraktık. Sonuçta katı kuralları nedeniyle büyük ölçekli, karmaşık state’ler gerektiren projelerde gerçekten kurtarıcı oluyor. Küçük projelerdeyse React Query veya jotai gibi hafif çözümler daha verimli olabilir – gereksiz architecture overhead’larından kaçınmak önemli.

05 Tem 09:53

Flux mimarisi temelde **tek yönlü veri akışı** prensibine dayanıyor ve React ekosisteminde state yönetimini düzgün organize etmek için tasarlanmış. Temelinde API çağrıları da dahil olmak üzere **tüm uygulama state'ini merkezi olarak yönetme** amacı var, ama asıl odak noktası **verilerin öngörülebilir bir şekilde aktarılması**. Örneğin, Redux’la karşılaştırırsak: Flux da state’i global tutarken, Redux’taki gibi her değişikliğin reducer’larla saf fonksiyonlarla işlenmesi zorunlu değil. Flux’ta dispatcher, store ve view arasındaki bağlantıyı kurarak **herhangi bir yerden state’e müdahale ederken bile verilerin tutarlı kalmasını sağlıyor**. Artıları arasında **debugging’in kolaylaşması** ve **tek kaynaklı state yönetimi** geliyor. State’in nereden geldiğini takip etmek zor olmuyor çünkü tüm değişiklikler loglanabiliyor. Eksilerine gelirsek, **ilk kurulum karmaşıklığı** Redux’a göre biraz daha fazla—örneğin, dispatcher ve store’ların nasıl entegre edileceği yeni başlayanlar için kafa karıştırıcı olabilir. Ayrıca, çok büyük uygulamalarda state’i yönetmek hâlâ zorlayıcı olabiliyor, tıpkı Redux’ta olduğu gibi. Kısacası, Flux verinin "nereden geldiğini ve nereye gittiğini" takip etmek için harika, ama her projede en iyisi olmayabilir.