State Karmaşasına Girmeden UI Kurmak

State Karmaşasına Girmeden UI Kurmak

Bir arayüz geliştirirken işler genelde sakin başlar.

Bir buton vardır, bir liste vardır, bir form… Her şey kontrol altındadır.

 

Sonra küçük eklemeler gelir:

 

• “Buraya bir loading ekleyelim”

• “Bu kapalıyken şu görünmesin”

• “Şuna basınca burası da güncellensin”

 

 

Ve bir noktada şunu fark edersin:

Ne, neye bağlı artık tam belli değil.

 

İşte state karmaşası tam olarak böyle başlar.

 

Sorun state kullanmak değil, her şeyi state yapmak

Modern UI geliştirme bize güçlü araçlar verdi.

Ama bu güç bazen yanlış bir refleksi doğurdu:

 

“Bir şey değişiyorsa state olsun.”

 

Oysa her değişken state olmak zorunda değildir.

State:

• Uygulamanın gerçekten hatırlaması gereken şeyler içindir

• Geçici görsel detaylar için değil

 

Her şeyi state’e bağladığında, arayüz sadece dinamik değil, kırılgan olur.

 

 

UI’da karmaşa çoğu zaman isimlendirmede başlar

isOpen, isVisible, showModal, modalActive…

 

Aynı şeyi anlatan ama farklı anlamlar taşıyan state’ler oluşur.

Bir süre sonra şunu sormaya başlarsın:

 

“Hangisi gerçeği temsil ediyor?”

 

State sayısı arttıkça:

• Akışı zihninde tutmak zorlaşır

• Değişiklik yapma cesareti azalır

• “Burası bozulmasın” korkusu oluşur

 

 

Bu da geliştirmeyi yavaşlatır.

 

 

Görsel durum ≠ uygulama durumu

En sık yapılan hatalardan biri budur.

 

Bir bileşenin:

• Açık / kapalı olması

• Hover’da görünmesi

• Animasyonlu olması

 

bunların hepsi uygulamanın state’i değildir.

Bunlar çoğu zaman UI state bile değildir; sadece görsel tepkidir.

 

CSS, basit koşullar ve bileşen yapısı burada çoğu zaman yeterlidir.

 

State’i her yere yaymak yerine, yerel tutmak karmaşayı ciddi şekilde azaltır.

 

 

State yukarı çıktıkça kontrol zorlaşır

“Bunu üst componente alalım” cümlesi tanıdıktır.

Ama her state yukarı taşındığında, etkilediği alan büyür.

Bir state:

• Kaç bileşeni etkiliyor?

• Gerçekten paylaşılması gerekiyor mu?

• Yoksa sadece kolay gelsin diye mi yukarı alındı?

Bu sorular sorulmadığında, state ağ gibi yayılır.

 

Ve UI mantığı okunmaz hâle gelir.

 

 

Basit bir kural çok iş görür

Şu refleksi kazanmak çoğu zaman yeterlidir:

 

“Bu bilgi gerçekten hatırlanmalı mı?”

 

Eğer cevap:

• “Sadece bu ekranda lazım” ise → yerel tut

• “Görsel bir detay” ise → state yapma

• “İş kuralı” ise → merkezi düşün

Bu ayrımı yapan UI’lar:

• Daha sade

• Daha test edilebilir

• Daha rahat değiştirilebilir olur

 

 

Aslında mesele kontrol hissi

State karmaşası teknik bir problem gibi görünür ama psikolojiktir.

Kontrol edemediğin bir yapı, seni yorar.

State’i azalttıkça:

• Kod okunur hâle gelir

• UI davranışı tahmin edilebilir olur

• “Buraya dokunursam ne olur?” korkusu azalır

 

Bu da geliştirmeyi keyifli hâle getirir.

 

 

Son söz

State karmaşasına girmeden UI kurmak,

daha az state yazmak değil,

doğru yere state koymak demektir.

 

Her şeyi kontrol etmeye çalışmak yerine,

neyin gerçekten kontrol edilmesi gerektiğini seçtiğinde,

arayüz kendiliğinden sadeleşir.

 

İyi UI’lar genelde çok state kullandıkları için değil,

çok az şeye gerçekten ihtiyaç duydukları için rahattır.