خانه‌تکانی به سبکِ ReactJS!

تقریباً مدتی است که ReactJS دستی به صفحه‌ی مستندات خود کشیده و از لحاظِ ظاهری دیگر خبری از alert‌های زمخت و صفحاتی استاتیک نیست، در نسخه جدید بیشتر با صفحه‌ای مشابه مستندات MUI مواجه می‌شویم که تماماً با NextJS نوشته شده است.

این کتابخانه به روشِ معروفِ Killed by Google برخی از ویژگیهای قبلی را خارج از دسترس کرده، که از معروفترین آن‌ها می‌توان به تکنیکِ ایجادِ وب آپلیکش توسط CRA یا create-react-app اشاره کرد، شاید یکی از اهداف پشتِ این تغییر کم کردنِ فاصله خود با فریمورک‌هایی است که از ReactJS به‌عنوانِ engine استفاده می‌کنند، که در نتیجه به‌جای یدک کشیدن لقبِ UI Library دیگر ما شاهدِ به‌کارگیریِ همه‌چیز از جمله route در یک چهارچوبِ جامع هستیم.

دلایلِ حذف CRA

• مدِ نظرگرفتنِ trade-off بین بهینه‌سازی و حجمِ نهاییِ فایل

در نگاه اول دلیلِ حذفِ قابلیتِ CRA را می‌توان وجودِ چالش‌هایی از جمله نحوه‌یِ راه‌اندازی و حفظ یکپارچه‌گی پروژه دانست، نیازمند کنترلِ پیوسته‌ی حجمِ فایل که از طریق روش‌هایی مثل lazy load که فرایند chaining یا تکه‌تکه‌کردنِ فایل‌های resource (به منظورِ کاهشِ زمانِ بارگزاری اولیه صفحه) میسر می‌شود، از دیگر چالش‌های اصلی آن است، این مشکل زمانی‌که در بخشی خاص از پروژه نیاز به استفاده از کتابخانه‌های third-party حجیم باشد، بیشتر به چشم خواهد خورد.

• مشکل در پیاده‌کردنِ routing

در وهله دوم دلیلِ حذف می‌تواند، ملموس بودنِ جایِ خالیِ routing در یک وب اپلیکیشن باشد که همواره نیاز به یکپارچه‌سازی دارد، به طوری‌که شاملِ استثنائاتی از جمله تعریف wildcard به ازای هر route به صورتِ دستی است.

• پیچیدگیِ ادغام client با server

خلاء یا نبودِ بخشی یکپارچه جهت ارتباط با سمت server یا راه‌اندازی بخش server به صورتِ جداگانه، یکیِ از چالش‌هایی است که علی‌رغمِ وجودِ react-query، فرایندِ درخواست و نحوه‌ی استفاده از داده نیازمندِ ساعت‌های متوالی جهت بهینه‌سازی و آماده‌کردن دارد، از این رو ارائه‌یافتن یک‌پروژه به صورت SSR یا Server-side rendering چالشی‌ست که با وجودِ روش‌های مختلف هنوز CRA نتوانستهِ رویکردی منعطف را برای این امر ممکن سازد.

سلامی به NextJs و خداحافظی با CRA

یکی از عمده دلایلِ اصلیِ این خانه‌تکانی، واگذاریِ عمده‌ کارها به یک فریم‌ورک (این مقاله تنها به NextJS اشاره می‌کند) است. اما سوالِ پیش رو این‌است‌که:

آیا کلِ مشکلات یا چالش‌های فوق با یکپارچه‌گی درونِ یک فریم‌ورک نظیر به NextJS حل خواهد شد؟!

فریم‌ورکِ NextJS هم عاری از اشکال نیست، مشکلِ نبودِ راه‌انداز مناسب برای سرورهایِ ویندوزی در آن به خوبی مشهود است، به صورتی‌که نسخه build شده هنوز برای آن‌که به صورت serverless اجرا شود در بعضی موارد همچون کنترلِ جریان داده از طریق props از client به server یا بلعکس نیازمندِ یکسری پیاده‌سازی‌هایِ اولیه است که هنوز نیاز به IIS برایِ کنترلِ جریانِ routing و بعضاِ security شدیداً به چشم می‌خورد، اگرچهِ بر اساسِ ادعای توسعه دهنده‌گان آن، در نسلِ جدید از NextJS ممکن است روالِ routing بهتر شود، ولی شایانِ ذکر است که این رویکرد برای سازگاری برای راه‌اندازی در سایرِ پلتفرم‌ها هنوز نیاز به توسعه دارد.

روشِ static یا مرده‌سازی پروژه

next build & next export

زمانی که دستورِ export در مستنداتِ این فریم‌ورک قرار گرفت و به صورت رسمی از آن رونمایی شد، نقطه عطفی بود بر اینکه یک نسخه freeze شده و به اصطلاح مرده و استاتیک از پروژه شاید بتواند جواب‌گوی استفاده آن به شکل CRA باشد. این روش دیگر وابستگی به سایرِ configها را به حداقل می‌رساند و تنها یک نسخه‌ای است که داده‌های ارسال شده به client به صورت cache شده و یا embedشده در فایل‌های html به صورت snapshot قابلِ دسترس می‌شود. اما static کردن دقیقاً رویکردی را دنبالِ می‌کند که CRA از آن بهره می‌برد و مهمترین مزیتی‌ که به نسبت آن دارد این‌است که، هر صفحه حاویِ فایل‌های resource مربوط به خودش است و در اصل به صورت physical path فرایندِ routing انجام می‌شود و از این رو مشکلِ وابستگی به وب سرور را حداقل به صفر می‌رساند و تکه‌تکه‌کردنِ فایل‌ها به ازای هر صفحه به صورت مجزاء انجام می‌شود.

ققنوس دوباره متولد می‌شود اما در کالبدی جدید

با وجودِ همه‌ی مشکلاتی که ممکن است در پیاده‌سازی و انتشارِ NextJS با آن دست و پنجه نرم کرد، بی‌شک یکی از محبوب‌ترین فریم‌ورک‌هاست که به‌خوبی سازگاریِ مناسبی با ReactJS دارد که سهولت در راه‌اندازی و عدمِ مواجههِ با یکپارچه‌سازی و بهینه‌کردن پروژه از دیگر مزایای آن است. علاوه بر آن پیاده کردنِ پروژه به روشِ SSR به صورتی‌کهِ حینِ render شدن و تولیدِ صفحه، جریانِ اجرای کد مستقیماً از سمتِ server به سمتِ client قبل از ایجاد و یا تغییری در state صفحه قابل اجرا است. ادغامِ جریانِ اجرایِ کد از سرور به کلاینت یکی از مزیت‌های بزرگ این روش است که مشابه آن در فریم‌ورک‌هایی شبیه به Asp.net یا Larave قابلِ اجراست، این راهکار، خلاءِ ادغامِ صفحات به دو سمتِ مختلف را پُر کرده و به‌جای نوشتن یک وب سرویس برای دستیابی به یک داده یا بدونِ این‌که کدهای بخشِ سرور تماماً در بخش سرور اجرا شوند و توسط props به کامپوننت ارسال شوند، بلافاصله داخل صفحه و در کلاینت، داده می‌تواند توسط اجرای کدِ سرور قابل دسترس باشد و قابلیت cache شدن مشابه روشِ static، صفحه را در نگاهِ browser به یک صفحه استاتیک تبدیل می‌کند‌.