CodeVerse | دنیای برنامه نویسان
🔥 یک تصمیم معماری که می‌تونه هزاران خط کد Frontend رو کمتر کنه
فرض کن یه اپلیکیشن داری که چندین 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
4 · 215 ·