معماری MRAH در ری اکت و هرچیزی که باید ازش بدونیم!
وقتی صحبت از بهینه سازی رابط کاربری در اپلیکیشن های React میشه، ذهن خیلی از ما به سمت tree shaking، lazy loading یا server-side rendering میره. ولی با افزایش نیاز به عملکرد سریعتر، تعاملات روانتر و تجربه کاربری بی نقص تو پروژه های واقعی، این تکنیک ها دیگه به تنهایی کافی نیستن!
اینجاست که یک معماری نوظهور به نام MRAH (Modular Rendering & Adaptive Hydration) وارد میشه! الگویی که به شکل عملی و قابل پیاده سازی، دو مشکل قدیمی React رو هدف گرفته:
رندر بیش از حد کامپوننت ها هیدریشن سنگین و همزمان در کلاینت
تو این مقاله در فِرانت اِندی، قدم به قدم با مفهوم MRAH آشنا میشیم، دلایل اهمیتش رو بررسی میکنیم، و میبینیم که چطور میتونیم با استفاده از این الگو توی پروژه های React (یا Next.js)، تجربه ای سریعتر برای کاربرا خلق کنیم 🙂
چرا این مقاله مهمه؟
معماری MRAH فقط یه buzzword جدید نیست؛ بلکه یه پاسخ واقع گرایانه ست به سوالی قدیمی:
«چرا اپلیکیشنمون با اینکه SSR داره و کلی بهینه سازی شده، هنوز توی تعاملات اولیه کند عمل میکنه؟»
پس اگه ما هم:
داریم روی یه پروژه React یا Next.js کار میکنیم
دنبال بهینه سازی Core Web Vitals هستیم
یا می خوایم با ترندهای جدید فرانت اند توی سال 1404 همراه بشیم
این مقاله میتونه برامون مفید باشه 🙂
مشکل دقیق هیدریشن در React چیه؟
قبل از اینکه بخوایم وارد دنیای MRAH بشیم، باید بدونیم دقیقا چه مشکلی توی معماری فعلی React وجود داره که MRAH قراره حلش کنه.
هیدریشن چیه اصلا؟
اگه با Server-Side Rendering (SSR) کار کرده باشیم، میدونیم که سرور یه نسخه HTML از صفحه تولید میکنه و اون رو به مرورگر میفرسته. این باعث میشه محتوای صفحه خیلی سریع به کاربر نشون داده بشه، حتی قبل از اینکه جاوااسکریپت به طور کامل لود بشه.
اما این فقط نصف ماجراست.
بعد از این که مرورگر HTML رو گرفت، باید React دوباره روی همون HTML “فعال” بشه تا تعامل‌پذیر بشه. یعنی بتونیم کلیک کنیم، فرم پر کنیم، تب عوض کنیم و…
به این فرایند می گیم Hydration.
مشکل از کجا شروع میشه؟
توی اپلیکیشن های React، به طور پیشفرض، کل صفحه باید یک جا هیدریت بشه. یعنی حتی اگه فقط یه دکمه توی یه بخش کوچیک نیاز به تعامل داره، React میاد و کل ساختار DOM رو اسکن و فعال می کنه.
این یعنی:
بارگذاری مقدار زیادی جاوااسکریپت
استفاده زیاد از CPU
تأخیر توی تعامل اولیه (مثل کلیک اول کاربر)
این موضوع به شدت روی Core Web Vitals مثل FID (First Input Delay) و TTI (Time to Interactive) تاثیر منفی میذاره.
چرا این موضوع توی پروژه های واقعی مهمه؟
چون کاربر معمولا با یه بخش خاص از صفحه تعامل داره. مثلا شاید اصلا اسکرول نکنه یا بعضی از ویجت ها رو نبینه. پس چرا باید همه چیز رو از همون اول هیدریت کنیم؟
واقعیت اینه که این مدل “هیدریشن کامل” هم منابع دستگاه رو هدر میده، هم تجربه کاربری رو خراب می کنه! مخصوصا روی موبایل و اینترنت های ضعیف.
معماری MRAH دقیقا چیه و از چه اجزایی تشکیل شده؟
تا اینجا دیدیم که مشکل اصلی React توی اپلیکیشن های SSR، هیدریشن کامل و غیرهوشمند صفحه است. حالا وقتشه ببینیم MRAH دقیقا چطوری با این مشکل مقابله میکنه.
MRAH مخفف دو مفهوم اصلیه که با هم کار میکنن:
۱. Modular Rendering (رندر ماژولار)
ایده اینه که صفحه مون رو به بخش های مستقل و جدا از هم تقسیم کنیم. هر بخش (ماژول) فقط وقتی رندر میشه یا هیدریت میشه که واقعاً لازمه.
مثلا:
هدر سایت یه ماژوله
لیست محصولات یه ماژوله
سایدبار یه ماژوله
و هر کامپوننت تعاملی میتونه یک ماژول مجزا باشه
با این کار، دیگه لازم نیست همه چیز از همون اول فعال بشه. هر چیزی فقط موقع نیاز لود یا هیدریت میشه.
۲. Adaptive Hydration (هیدریشن تطبیقی)
بعد از اینکه صفحه به بخش های جدا تقسیم شد، حالا وقتشه تصمیم بگیریم چه زمانی و چطوری هر بخش هیدریت بشه. اینجاست که “تطبیقی بودن” وارد ماجرا میشه.
یعنی چی؟
یعنی ما با توجه به شرایط، تصمیم می گیریم که یه ماژول رو:
بلافاصله هیدریت کنیم (مثلا چون توی viewport هست)
وقتی اسکرول خوردیم بهش، تازه فعالش کنیم
بذاریم تا مرورگر idle شد، بعد سر فرصت هیدریتش کنیم
یا اصلا اگر کاربر سمت اون بخش نرفت، هیچی براش لود نکنیم!
با این کار، مصرف CPU کمتر میشه، جاوااسکریپت کمتری لود میشه و تجربه کاربر به شدت سریعتر و روان تر میشه.
ترکیب این دوتا، میشه معماری MRAH
وقتی صفحه مون رو ماژولار کنیم، و برای هر ماژول تصمیم بگیریم که چطوری و کی فعال بشه، در واقع داریم از معماری MRAH استفاده می کنیم.
به زبان ساده:
MRAH یعنی “هر چیزی فقط وقتی زنده بشه که واقعاً بهش نیاز داریم.”
چه ابزارهایی کمکمون میکنن برای اینکار ؟
برای پیاده سازی این معماری توی React یا Next.js، ابزارهای زیادی هست که میتونیم استفاده کنیم:
dynamicدر Next.js برای lazy load کردن کامپوننت هاrequestIdleCallbackبرای اجرای کد توی زمان آزاد مرورگرIntersectionObserverبرای تشخیص اینکه یه ماژول وارد viewport شده یا نهReact.lazyوSuspenseبرای بارگذاری تنبلکتابخونه هایی مثل
react-lazy-hydrationیاreact-intersection-observerبرای راحت تر کردن این کارها
مثال: بارگذاری تنبل یک کامپوننت (Modular Rendering)
فرض کنیم یه کامپوننت داریم به اسم ProductList که فقط توی صفحه اصلی لازمه. چرا باید اون رو از اول توی کلاینت هیدریت کنیم؟ بهتره که فقط وقتی کاربر به اون بخش رسید، لودش کنیم.
توی Next.js میتونیم از dynamic import استفاده کنیم:
// pages/index.tsx یا هر صفحه دیگه
import dynamic from 'next/dynamic'
const ProductList = dynamic(() => import('../components/ProductList'), {
ssr: false,
loading: () => <p>در حال بارگذاری محصولات...</p>
})
export default function HomePage() {
return (
<div>
<h1>خوش اومدی!</h1>
<ProductList />
</div>
)
}
این کد باعث میشه ProductList فقط سمت کلاینت رندر بشه و از SSR حذف بشه.
همچنین فقط وقتی جاوااسکریپت مربوطه لود شد، اون بخش فعال میشه.
مزایای معماری MRAH
۱. بهبود جدی Core Web Vitals
با کنترل بهتر روی زمان و نحوه هیدریشن، معیارهایی مثل:
FID (First Input Delay)
TTI (Time to Interactive)
CLS (Cumulative Layout Shift)
به شکل محسوسی بهبود پیدا می کنن 🙂 مخصوصاً توی موبایل و شبکه های کندتر.
۲. کاهش مصرف منابع
وقتی فقط اون بخشی از UI هیدریت بشه که واقعاً لازمه، فشار روی CPU و حافظه مرورگر به شدت کم میشه.
این موضوع برای کاربرهایی که دستگاه ضعیف تر دارن فوق العاده مهمه.
۳. کنترل کامل روی رندر و تعامل
ما دیگه به جای این که فقط بگیم “React همه چی رو هندل کن”، میتونیم خودمون تعیین کنیم:
چی کی لود بشه
چی اصلاً تعاملی باشه یا نه
چقدر جاوااسکریپت به کلاینت بفرستیم
۴. مناسب برای پروژه های بزرگ یا مقیاس پذیر
توی پروژه هایی که تعداد صفحات یا ویجت ها زیاده، MRAH کمک میکنه مقیاس پذیری راحت تر بشه، چون همه چیز به صورت مستقل و قابل مدیریت پیش میره.
جمع بندی
معماری MRAH شاید یه مفهوم نسبتا جدید باشه، ولی خیلی زود داره تبدیل میشه به یه استاندارد واقعی برای ساخت اپلیکیشن های مقیاس پذیر و سریع در ری اکت !
این معماری یه جور دعوت به تفکر دوبارست! اینکه به جای «همه چیز، همیشه، برای همه»، فقط چیزی رو ارائه بدیم که کاربر واقعاً لازمش داره، و دقیقا همون موقعی که لازمه!
دیدگاهتان را بنویسید