TanStack رسماً استفاده از React Server Components (RSC) را در کتابخانه‌های خود متوقف کرد و عوامل تعیین‌کننده‌ای همچون افزایش پیچیدگی، کاهش انعطاف‌پذیری، بهبودهای اندک در عملکرد و کاهش سرعت توسعه را از این تصمیم دانست. این اقدام برای هر کسی که در حال ساخت ابزارهای مبتنی بر React است اهمیت دارد، زیرا کتابخانه‌های TanStack به طور گسترده مورد استفاده قرار می‌گیرند و اغلب استانداردهای عملی را برای این اکوسیستم تعیین می‌کنند.

چرا RSC جذاب به نظر می‌رسید

React Server Components به عنوان راهی برای انتقال کارهای سنگین واکشی داده (data-fetching) و رندرینگ به سمت سرور معرفی شد، با این وعده که حجم باندل‌های کلاینت را کمتر و سرعت بارگذاری صفحات را بیشتر کند. تیم TanStack این رویکرد را امتحان کرد، با این امید که تجربه کاربری کتابخانه‌های data-grid و query خود را بهبود بخشد.

چه چیزی آن‌ها را منصرف کرد

  • پیچیدگی – عیب‌یابی (Debugging) کدهای RSC مستلزم یک مدل ذهنی متفاوت بود. تیم بیش از آنچه توان داشت، وقت خود را صرف ردیابی مشکلات رندرینگ سمت سرور کرد.
  • انعطاف‌پذیری – بسیاری از کتابخانه‌های شخص ثالث (third-party) فرض را بر محیط خالص کلاینت می‌گذارند. اجرای صرفاً سرور‌محورِ RSC، ادغام آن‌ها را بدون بازنویسی یا استفاده از shim برای آن وابستگی‌ها دشوار می‌کرد.
  • عملکرد – بهبودهای اندازه‌گیری شده در سرعت، اندک بود. سربارِ هماهنگ‌سازی مرزهای سرور و کلاینت، در اکثر سناریوهای دنیای واقعی، بر مزایای جزئی به‌دست‌آمده غلبه می‌کرد.
  • سرعت توسعه – الگوهای ساده‌تر و کلاینت‌محور به تیم اجازه می‌داد تا به‌روزرسانی‌ها را سریع‌تر عرضه کند. با RSC، هر تغییر مستلزم اعتبارسنجی در هر دو سمت سرور و کلاینت بود که باعث کند شدن چرخه انتشار می‌شد.

پیامدهای گسترده‌تر

اگر یک ابزار پیشرو مانند TanStack از RSC عقب‌نشینی کند، پروژه‌های دیگر ممکن است در مورد هیجانات پیرامون آن تجدیدنظر کنند. این تصمیم نشان‌دهنده یک موازنه (trade-off) است: ویژگی‌های پیشرفته می‌توانند هزینه‌های پنهانی داشته باشند که به بهره‌وری توسعه‌دهنده و نگهداری طولانی‌مدت آسیب می‌زند. شرکت‌هایی که اولویت خود را بر تکرار سریع (rapid iteration) و سازگاری گسترده با کتابخانه‌ها می‌گذارند، ممکن است همین مسیر را دنبال کنند.

دیدگاه مخالف

برخی از توسعه‌دهندگان هنوز در موارد استفاده خاص، ارزش‌هایی را در RSC می‌بینند؛ به‌ویژه در جاهایی که پردازش داده در سمت سرور می‌تواند حجم داده‌های ارسالی (payload) را به شدت کاهش دهد. این رویکرد ممکن است تکامل یابد و ابزارهای آینده بتوانند نقاط ضعفی را که TanStack شناسایی کرده بود، برطرف کنند. در حال حاضر، اجماع نظر همچنان متفاوت است.

آنچه باید در آینده زیر نظر داشت

  • به‌روزرسانی ابزارها – بهبود در عیب‌یابی و پشتیبانی از ادغام می‌تواند مانع پیچیدگی را کاهش دهد.
  • بازخورد جامعه کاربری – با اشتراک‌گذاری داده‌های عملکرد توسط تیم‌های بیشتر، معادله هزینه-فایده ممکن است تغییر کند.
  • الگوهای جایگزین – تکنیک‌های رندرینگ تدریجی سرور یا رویکردهای ترکیبی (hybrid) ممکن است راه حلی میانه ارائه دهند.

نتیجه‌گیری: عقب‌نشینی TanStack از React Server Components به ما یادآوری می‌کند که جدیدتر بودن همیشه به معنای بهتر بودن نیست؛ توسعه‌دهندگان باید پیش از به‌کارگیری الگوهای نوظهور، هزینه واقعی آن‌ها بر گردش کار خود را در مقابل مزایای وعده‌داده‌شده بسنجند.

منبع: https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com