سرور کامپوننت‌ها در برابر کلاینت کامپوننت‌ها

مدل ذهنی در یک جمله

سرور کامپوننت جایی رندر می‌شود که داده‌ی تو آن‌جاست؛ کلاینت کامپوننت جایی که کاربرِ توست. بقیه‌ی ماجرا از همین یک جمله بیرون می‌آید.

سرور کامپوننت چه چیزهایی می‌دهد

• دسترسی مستقیم به دیتابیس و فایل‌سیستم بدون یک API جداگانه.
• صفر جاواسکریپت زمان اجرا برای بخش‌هایی که فقط محتوا نمایش می‌دهند.
• باندل کوچک‌تر، چون کتابخانه‌هایی که سمت سرور استفاده می‌شوند هرگز به مرورگر نمی‌رسند.

چه چیزی شما را مجبور به کلاینت کامپوننت می‌کند

• State و افکت: `useState`، `useEffect`، هندلر رویداد.
• APIهای مرورگر: geometry، media query، storage.
• Context و تعامل‌هایی که کاربر باید فوراً حس کند.

قسمت سخت وسط

پراپ‌هایی که از سرور کامپوننت رد می‌شوند داده‌ی سریال‌شده‌اند؛ پس شگفتی در مرز کمین کرده است.

• تابع‌ها و instance های کلاس از این مرز عبور نمی‌کنند.
• کلاینت کامپوننت‌ها را نزدیک برگ‌های تعاملی نگه دار و سرور کامپوننت‌ها را به سمت ریشه‌های داده ببر.
• وقتی یک کامپوننت «هر دو» است، بشکنش: یک پوسته‌ی کلاینت و یک بدنه‌ی سرور.

این وبلاگ چطور سازمان‌دهی شده

صفحه‌ها و بدنه‌ی پست‌ها رندر سمت سرورند و تم‌تغییر و منوی موبایل جزیره‌های کلاینت. همین تقسیم باعث می‌شود سایت تعاملی بماند ولی جاواسکریپت کمی تحویل بدهد.

جمع‌بندی

به‌جای «این کامپوننت هوک دارد پس کلاینت» بپرس کار باید کجا اجرا شود، بعد بقیه را بسپار به فریم‌ورک.