State Hoisting: Compose'ta Gereksiz Tasarım Tuzağı

State hoisting Compose'un temel ilkelerinden biri. Durumu üst bileşene taşı, aşağıya prop olarak indir, güzel teori. Ama uygulamada bu yaklaşım sık sık fazla tasarıma dönüşüyor.

Geçen ay bir proje gördüm: basit bir form sayfasında 15 satır kod yazan state hoisting. Her input field'ın durumu ana Activity'ye çıkarılmıştı. Neden? "Reusability için." Oysa bu bileşen başka hiçbir yerde kullanılmıyor, ve belki de hiç kullanılmayacak.

State hoisting'in gerçek amacı paylaşmak. İki veya daha fazla bileşen aynı duruma ihtiyaç duyduğunda, o zaman kaldır. Ama tek bir bileşen içinde kalan durum, özellikle UI durumu, form geçici değerleri, toggle state'i, kendi içinde tutmalı. Bunu yapmak Composable'ı basit, test edilebilir ve anlaşılır tutar.

Compose'ta `remember` ve `mutableStateOf` hafif ve hızlı. Gereksiz yere state'i yukarı çıkarmak sadece kod akışını karmaşıklaştırmaz, aynı zamanda recomposition'ı da gereksiz yere tetikler. Üst bileşen her state değişikliğinde yeniden compose olur, hatta hiç ilgili olmayan widget'lar da etkilenir.

Praktik kural basit: durumu, onu kullanan en düşük bileşende tut. Sadece başka bir bileşenin aynı state'i okuması veya değiştirmesi gerekiyorsa, o zaman hoist et. Preemptive reusability uğruna tasarım yapmak, Compose'un en yaygın hatasıdır.

Malum, "clean architecture" ve "separation of concerns" sloganları cazip geliyor. Ama Compose bağlamında temizlik, gereksiz abstraction değil, açıklık ve basitliktir. State hoisting bir araç, dogma değil.