استفاده از ApexCharts در نکست جی اس: یک مطالعه موردی عملی در مورد رندرینگ سمت سرور، معماری و تعامل ها

در یکی از پروژه هایی که اخیراً روی آن کار می‌کردم،
نیاز به پیاده سازی مجموعه ای از چارتهای پیشرفته داشتم؛
چارتهایی که هم تعاملی باشند، هم با تم متریال یو آی هماهنگ شوند
و هم در معماری نکست جی اس 13 به بالا بدون مشکل اجرا شوند.

بعد از بررسی چند گزینه، ApexCharts انتخاب شد.
این مقاله، مستند تجربه‌ من از استفاده‌ این کتابخانه در یک پروژه‌ نکست جی اس است؛
از تصمیمهای معماری گرفته تا چالشهای رندرینگ سمت سرور SSR و راه حلهای نهایی.

چرا ApexCharts؟

از نظر قابلیتها، ApexCharts تقریباً همه‌ نیازهای پروژه را پوشش می‌داد:

• تعامل پذیری بالا (hover، zoom، tooltip)

• کنترل کامل روی series و axis

• پشتیبانی مناسب از تایپ اسکریپت

اما خیلی زود مشخص شد که این کتابخانه برای رندرینگ سمت سرور طراحی نشده
و استفاده‌ مستقیم از آن در نکست جی اس منجر به خطای آشنای window is not defined می‌شود.

تصمیم معماری: جداسازی Server و Client

برای جلوگیری از این مشکل، ساختار زیر انتخاب شد:

• صفحه‌ی اصلی به‌عنوان Server Component

• منطق چارت در یک Client Component مجزا

• استفاده از dynamic import برای جلوگیری از رندر در سرور

const Chart = dynamic(() => import("react-apexcharts"), {
  ssr: false
});

این تصمیم باعث شد:

• SSR اپلیکیشن سالم بماند

• کد چارت کاملاً ایزوله شود

• bundle سرور سبک‌تر شود

هماهنگی با Material UI Theme

یکی از دغدغه های اصلی، هماهنگی کامل چارتها با سیستم طراحی بود.
به‌جای تعریف رنگها به‌صورت hardcode، رنگها مستقیماً از MUI theme گرفته شدند:

const primary = theme.palette.primary.main;
const secondary = theme.palette.secondary.main;

نتیجه این شد که با تغییر تم، چارتها بدون هیچ تغییر اضافی به‌روزرسانی می‌شدند.

ParentCard: تصمیمی برای مقیاس‌پذیری

بعد از پیاده سازی چند چارت، الگوی تکراری مشخص شد:
عنوان، محتوا، و گاهی نمایش کد نمونه.

اینجا بود که کامپوننت ParentCard متولد شد؛
یک wrapper مشترک که بعدها اضافه‌کردن چارت جدید را به کاری ساده و تکراری تبدیل کرد.

این تصمیم کوچک، بیشترین تأثیر را در نگهداری پروژه داشت.

جمع‌بندی تجربه

ApexCharts در نکست جی اس کاملاً قابل استفاده است،
اما بدون درک درست از رندرینگ سرمت سرور و کامپوننتهای کلاینتی می‌تواند دردسرساز شود.

این معماری نتیجه‌ی چند بار اصلاح و بازطراحی است؛
شاید بهترین راه ممکن نباشد،
اما در عمل برای پروژه‌ای با چارت‌های متعدد و تعاملی،
پایدار و قابل نگهداری از آب درآمد.

حرف آخر

در پروژه‌ های مدرن، مسئله فقط انتخاب کتابخانه نیست؛

بلکه نحوه‌ قرار دادن آن در معماری اپلیکیشن اهمیت دارد.

اگر تجربه‌ ای مشابه در استفاده از کتابخانه های نمودار و چارت یا رندرینگ سمت سرور داشته‌اید،

خوشحال میشوم درباره‌ ش صحبت کنیم.