Photo by Dzmitry Dudov on Unsplash

REACT STATE MANAGEMENT

Hangi Client State Management Yöntemi’ni Kullanmalıyım ? (Jotai)

Bu yazıda Client State Management için hangi yöntemleri kullanabilirim üzerine araştırma yaptım. (useState, useContext, redux, zustand, jotai, …) avantajı, dezavantajı için küçük bir deneme ortamı oluşturup bunun üzerinde denemeler yaptım.

Frontend Development With JS
3 min readJan 15, 2023

--

Bu yazı serimizin 4ncü yazısı. Özet olması açısından ilk yazıda ortak paylaşımlı kullanılacak count1 ve count2 state Lifting State Up yöntemi ile sayfa seviyesine taşıyıp bunu useState ve Props Drilling yöntem ile alt bileşenlere ulaştırmıştık ama arada konu ile ilgili olmayan bileşenlere de dokunmak zorunda kaldık. Bu onlarında ekstradan props taşımasına ve ekstradan bileşenlerin re-render edilmesine sebep olmuştu.

2nci yazımız ise bu prop taşıma yönteminden kurtulmak için React.createContext üzerinden Context oluşturma ve bu context üzerinden sadece ilgili bileşenlere ulaştırmayı denedik. Context oluşturduğumuz kısımda Multiple Context Wraplama(Sarmallama) karmaşıklığı ve ilgili bileşenlerin sadece kendi contextleri ile ilgilendiği durumda bile başka contextlerden gelen güncellemerin rendering etkilemesi ekstra Memoization gereksinimi Context’in de tam istediğimiz sonucu vermediğini belirtmiştik.

3ncü yazımızda Zustand kütüphanesi ile aynı ortamı kurduk hem kod yazım şeklinde props taşıma zorunluluğu olmaması , hemde rendering sırasında sadece ilgili bileşeni güncellemesi yönünden en beğendiğim kütüphane olduğunu söylemiştim.

Bu yazıda ise Atomic bir yapıda state yönetmemizi sağlayan Jotai kullanarak aynı Playground oluşturalım (Linki)

Jotai Playground

Öncelikle state tutacak 2 atomic yapıyı oluşturalım. Aslında Jotai’de genel bir store yapma mantığı yok. Direk ihtiyacın olan kısımlarda atomlar üzerinden çalışma var yani top → bottom bir yapı yerine bottom → top aşağıdan yukarı yayılan bir yapı. Her neyse biz uygulama mantığımızı bozmadan zustand benzer bir şekilde atom oluşturuyoruz.

import { atom } from 'jotai';

export const count1Atom = atom(0);
export const count2Atom = atom(0);

Burada bu atomlar Orn count1Atom aslında bizim o değere olan getter ve settter olan pointer adresi

export const IncBtn2 = props => {
const [count2, setCount2] = useAtom(count2Atom);
return (
<button onClick={() => setCount2(count2 + 1)}>Inc2</button>
);
};

Aynı şekilde ValueDisp incelediğimizde

export const ValueDisp2 = () => {
const [count2] = useAtom(count2Atom);
return (
<span style={{ backgroundColor: 'red' }}>{count2}</span>
);
};

Kod olarak Zuztand kullanımı ile nerdeyse birbirine çok yakın oldu. Tek fark Zustand değerin state değişim işlemini increment iş mantığını Zustand slice tanımladığımız yere aldığımız için bu iş logic işletilme State Machine göre işletilme kısmı Bileşenden dışarı çıkmıştı.

Halbuki Jotai bu kısım ile uğraşmıyor bunun için biz bileşen içerisinde değerin önceki halini bilip onu bir arttırma işlemini bileşen içinde yapıyoruz.

RENDERING

Rendering kısmında IncBtn1 ve C1 etkilendi. Yukarı da yazdığım gibi Jotai’nin yapısında bu çok normal çünkü iş yapma mantığını Inc Düğmesi gerçekleştiriyor ve onunda Count1 val değerini bilmesi gerekiyor.

https://onurdayibasi.dev/state-jotai

Sonuç: Bence kod temizliği ve Rendering mantığı Zustand gibi oldukça temiz. Eğer ki bir Reducing, ortak Store yapısı kurmak istemiyorsanız Jotai iyi bir Mimari tercih olabilir.

Not: Bir sonraki yazımızda Redux ile ilgili yaptığımız playground ortamını açıklamaya çalışacağım.

Okumaya Devam Et 😃

Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.

--

--