TanStack ತನ್ನ ಲೈಬ್ರರಿಗಳಲ್ಲಿ React Server Components (RSC) ಅನ್ನು ಬಳಸುವುದನ್ನು ಅಧಿಕೃತವಾಗಿ ನಿಲ್ಲಿಸಿದೆ. ಸಂಕೀರ್ಣತೆ ಹೆಚ್ಚಾಗುವುದು, ನಮ್ಯತೆ (flexibility) ಕಡಿಮೆಯಾಗುವುದು, ಸಾಧಾರಣ ಮಟ್ಟದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಲಾಭಗಳು ಮತ್ತು ಅಭಿವೃದ್ಧಿಯ ವೇಗ ನಿಧಾನವಾಗುವುದು ಇದರ ಪ್ರಮುಖ ಕಾರಣಗಳಾಗಿವೆ. React ಆಧಾರಿತ ಪರಿಕರಗಳನ್ನು ನಿರ್ಮಿಸುವ ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಈ ನಿರ್ಧಾರವು ಮುಖ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ TanStack ಲೈಬ್ರರಿಗಳು ವ್ಯಾಪಕವಾಗಿ ಬಳಕೆಯಾಗುತ್ತವೆ ಮತ್ತು ಇಕೋಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಪ್ರಾಯೋಗಿಕ ಮಾನದಂಡಗಳನ್ನು ನಿಗದಿಪಡಿಸುತ್ತವೆ.

RSC ಏಕೆ ಆಕರ್ಷಕವಾಗಿ ಕಂಡಿತು

ಭಾರೀ ಡೇಟಾ-ಫೆಚಿಂಗ್ (data-fetching) ಮತ್ತು ರೆಂಡರಿಂಗ್ ಕೆಲಸವನ್ನು ಸರ್ವರ್‌ಗೆ ವರ್ಗಾಯಿಸಲು, ಕ್ಲೈಂಟ್ ಬಂಡಲ್‌ಗಳನ್ನು (client bundles) ಚಿಕ್ಕದಾಗಿರಿಸಲು ಮತ್ತು ಪೇಜ್ ಲೋಡ್ ವೇಗವನ್ನು ಹೆಚ್ಚಿಸಲು RSC ಒಂದು ಮಾರ್ಗವಾಗಿ ಬಂದಿತು. TanStack ತಂಡವು ತಮ್ಮ ಡೇಟಾ-ಗ್ರಿಡ್ ಮತ್ತು ಕ್ವೆರಿ ಲೈಬ್ರರಿಗಳ ಬಳಕೆದಾರ ಅನುಭವವನ್ನು ಸುಧಾರಿಸುವ ನಿರೀಕ್ಷೆಯಲ್ಲಿ ಈ ವಿಧಾನವನ್ನು ಪ್ರಯತ್ನಿಸಿತು.

ಅವರನ್ನು ಯಾವುದು ದೂರ ಮಾಡಿತು

  • ಸಂಕೀರ್ಣತೆ (Complexity) – RSC ಕೋಡ್ ಅನ್ನು ಡಿಬಗ್ ಮಾಡುವುದು (debugging) ಒಂದು ಪ್ರತ್ಯೇಕ ಮಾನಸಿಕ ಮಾದರಿಯನ್ನು ಬಯಸುತ್ತಿತ್ತು. ತಂಡವು ಸರ್ವರ್-ಸೈಡ್ ರೆಂಡರಿಂಗ್ ಸಮಸ್ಯೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ನಿಗದಿಪಡಿಸಿದ ಸಮಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಸಮಯವನ್ನು ವ್ಯಯಿಸಬೇಕಾಯಿತು.
  • ನಮ್ಯತೆ (Flexibility) – ಅನೇಕ ಥರ್ಡ್-ಪಾರ್ಟಿ ಲೈಬ್ರರಿಗಳು ಕೇವಲ ಕ್ಲೈಂಟ್ ಪರಿಸರವನ್ನು (client environment) ಅವಲಂಬಿಸಿರುತ್ತವೆ. RSC ನ ಸರ್ವರ್-ಓನ್ಲಿ (server-only) ಕಾರ್ಯನಿರ್ವಹಣೆಯು ಆ ಅವಲಂಬನೆಗಳನ್ನು ಮರುಬರೆಯದೆ ಅಥವಾ ಶಿಮ್ (shim) ಮಾಡದೆ ಸಂಯೋಜಿಸುವುದನ್ನು ಕಷ್ಟವಾಗಿಸಿತು.
  • ಕಾರ್ಯಕ್ಷಮತೆ (Performance) – ಅಳೆಯಲಾದ ವೇಗದ ಸುಧಾರಣೆಗಳು ಸಾಧಾರಣವಾಗಿದ್ದವು. ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ನಡುವಿನ ಗಡಿಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಹೊರೆ (overhead), ಹೆಚ್ಚಿನ ನೈಜ-ಪ್ರಪಂಚದ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಸಿಗುವ ಸಣ್ಣ ಲಾಭಗಳಿಗಿಂತ ಹೆಚ್ಚಾಗಿತ್ತು.
  • ವೇಗ (Velocity) – ಸರಳವಾದ, ಕ್ಲೈಂಟ್-ಓನ್ಲಿ ಮಾದರಿಗಳು ತಂಡಕ್ಕೆ ಅಪ್‌ಡೇಟ್‌ಗಳನ್ನು ವೇಗವಾಗಿ ಬಿಡುಗಡೆ ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಟ್ಟವು. RSC ನೊಂದಿಗೆ, ಪ್ರತಿಯೊಂದು ಬದಲಾವಣೆಯು ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಎರಡರ ಮೇಲೂ ಪರಿಶೀಲನೆಯನ್ನು ಬಯಸುತ್ತಿತ್ತು, ಇದು ಬಿಡುಗಡೆ ಚಕ್ರವನ್ನು (release cycle) ನಿಧಾನಗೊಳಿಸಿತು.

ವಿಶಾಲವಾದ ಪರಿಣಾಮಗಳು

TanStack ನಂತಹ ಪ್ರಮುಖ ಟೂಲ್‌ಕಿಟ್ RSC ನಿಂದ ಹಿಂದೆ ಸರಿದರೆ, ಇತರ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳು ಕೂಡ ಇದರ ಬಗ್ಗೆ ಮರುಪರಿಶೀಲನೆ ನಡೆಸಬಹುದು. ಈ ನಿರ್ಧಾರವು ಒಂದು ವಿನಿಮಯವನ್ನು (trade-off) ಎತ್ತಿ ತೋರಿಸುತ್ತದೆ: ಅತ್ಯಾಧುನಿಕ ವೈಶಿಷ್ಟ್ಯಗಳು ಅಭಿವೃದ್ಧಿಪಡಿಸುವವರ ಉತ್ಪಾದಕತೆ ಮತ್ತು ದೀರ್ಘಕಾಲದ ನಿರ್ವಹಣೆಗೆ ಹಾನಿ ಮಾಡುವ ಗುಪ್ತ ವೆಚ್ಚಗಳನ್ನು ಪರಿಚಯಿಸಬಹುದು. ವೇಗದ ಪುನರಾವರ್ತನೆ (rapid iteration) ಮತ್ತು ವ್ಯಾಪಕ ಲೈಬ್ರರಿ ಹೊಂದಾಣಿಕೆಗೆ ಆದ್ಯತೆ ನೀಡುವ ಕಂಪನಿಗಳು ಕೂಡ ಇದೇ ಹಾದಿಯನ್ನು ಅನುಸರಿಸಬಹುದು.

ವಿರೋಧಾತ್ಮಕ ಅಂಶ

ಕೆಲವು ಡೆವಲಪರ್‌ಗಳು ನಿರ್ದಿಷ್ಟ ಬಳಕೆಗಳಿಗಾಗಿ (use cases) RSC ನಲ್ಲಿ ಮೌಲ್ಯವನ್ನು ಕಾಣುತ್ತಾರೆ—ವಿಶೇಷವಾಗಿ ಸರ್ವರ್-ಸೈಡ್ ಡೇಟಾ ಪ್ರೊಸೆಸಿಂಗ್ ಮೂಲಕ ಪೇಲೋಡ್ ಗಾತ್ರವನ್ನು (payload size) ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡಬಹುದಾದ ಸಂದರ್ಭಗಳಲ್ಲಿ. ಈ ವಿಧಾನವು ವಿಕಸನಗೊಳ್ಳಬಹುದು ಮತ್ತು ಭವಿಷ್ಯದ ಟೂಲಿಂಗ್ TanStack ಗುರುತಿಸಿದ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಬಹುದು. ಸದ್ಯಕ್ಕೆ, ಜನರ ಅಭಿಪ್ರಾಯವು ಮಿಶ್ರಿತವಾಗಿದೆ.

ಮುಂದೆ ಏನನ್ನು ಗಮನಿಸಬೇಕು

  • ಟೂಲಿಂಗ್ ಅಪ್‌ಡೇಟ್‌ಗಳು – ಡಿಬಗ್ಗಿಂಗ್ ಮತ್ತು ಸಂಯೋಜನಾ ಬೆಂಬಲದಲ್ಲಿನ ಸುಧಾರಣೆಗಳು ಸಂಕೀರ್ಣತೆಯ ಅಡೆತಡೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.
  • ಸಮುದಾಯದ ಪ್ರತಿಕ್ರಿಯೆ – ಹೆಚ್ಚಿನ ತಂಡಗಳು ಕಾರ್ಯಕ್ಷಮತೆಯ ಡೇಟಾವನ್ನು ಹಂಚಿಕೊಂಡಂತೆ, ವೆಚ್ಚ-ಪ್ರಯೋಜನಗಳ ಸಮೀಕರಣವು ಬದಲಾಗಬಹುದು.
  • ಪರ್ಯಾಯ ಮಾದರಿಗಳು – ಇನ್ಕ್ರಿಮೆಂಟಲ್ ಸರ್ವರ್ ರೆಂಡರಿಂಗ್ ತಂತ್ರಗಳು ಅಥವಾ ಹೈಬ್ರಿಡ್ ವಿಧಾನಗಳು ಮಧ್ಯಮ ಮಾರ್ಗವನ್ನು ಒದಗಿಸಬಹುದು.

ಸಾರಾಂಶ: React Server Components ನಿಂದ TanStack ನ ಹಿಂತೆಗೆತವು ನಮಗೆ ಒಂದು ವಿಷಯವನ್ನು ನೆನಪಿಸುತ್ತದೆ: ಹೊಸದಾಗಿದ್ದನೆಂದರೆ ಅದು ಯಾವಾಗಲೂ ಉತ್ತಮ ಎಂದಲ್ಲ; ಅಭಿವೃದ್ಧಿಪಡಿಸುವವರು ಹೊಸ ಮಾದರಿಗಳನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವ ಮೊದಲು, ಅವುಗಳಿಂದ ಸಿಗುವ ಲಾಭಗಳಿಗಿಂತ ತಮ್ಮ ಕೆಲಸದ ಹರಿವಿನ (workflow) ಮೇಲೆ ಅವು ಬೀರುವ ನೈಜ ವೆಚ್ಚವನ್ನು ಲೆಕ್ಕಹಾಕಬೇಕು.

ಮೂಲ: https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com