فرض کن یه اپلیکیشن داری که چندین Component مختلف از اطلاعات یک کاربر استفاده می‌کنن.
راه ساده اینه که اطلاعات رو از بالا به پایین با Props پاس بدی:
App
↓
Layout
↓
Page
↓
Section
↓
Card
↓
User
بعد چند ماه:
<Card
user={user}
permissions={permissions}
settings={settings}
preferences={preferences}
/>
و بعد:
"چرا Prop Drilling اینقدر زیاد شد؟" 😐
ولی راه‌حل حرفه‌ای این نیست که برای هر چیزی سریع بری سراغ Global State.
اول باید سؤال درست رو بپرسی:
این Data واقعاً چه Scopeای داره؟
مثلاً:
Local UI State
→ Component
Feature State
→ Feature Boundary
Shared Client State
→ Store
Server State
→ Cache / Query Layer
URL State
→ URL
این تفکیک خیلی مهمه.
چون اگر Server State رو مثل Client State مدیریت کنی، کم‌کم خودت مسئول چیزهایی مثل:
Cache
Refetch
Stale Data
Loading
Error
Synchronization
Invalidation
می‌شی.
در حالی که ابزارهایی مثل Query Layer دقیقاً برای مدیریت Lifecycle داده‌های سمت سرور ساخته شدن.
💡 هر State که Global نیست.
و یکی از نشانه‌های معماری خوب اینه که قبل از اضافه کردن یک State Manager جدید، دقیقاً بدونی:
این داده متعلق به کجاست؟ چه کسی مالکشه؟ و Lifecycleش دست کیه؟
@CodeVerse_dev