TanStack ਨੇ ਵਧ ਗਈ ਜਟਿਲਤਾ (complexity), ਘਟਦੀ ਲਚਕਤਾ (flexibility), ਮਾਮੂਲੀ ਪ੍ਰਦਰਸ਼ਨ ਲਾਭ (performance gains), ਅਤੇ ਵਿਕਾਸ ਦੀ ਹੌਲੀ ਗਤੀ (development velocity) ਨੂੰ ਨਿਰਣਾਇਕ ਕਾਰਕ ਦੱਸਦੇ ਹੋਏ, ਆਪਣੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ React Server Components (RSC) ਦੀ ਵਰਤੋਂ ਅਧਿਕਾਰਤ ਤੌਰ 'ਤੇ ਬੰਦ ਕਰ ਦਿੱਤੀ ਹੈ। ਇਹ ਕਦਮ ਉਹਨਾਂ ਸਾਰਿਆਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜੋ React-ਅਧਾਰਤ ਟੂਲ ਬਣਾ ਰਹੇ ਹਨ, ਕਿਉਂਕਿ TanStack ਦੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਅਪਣਾਇਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਹ ਅਕਸਰ ਈਕੋਸਿਸਟਮ ਲਈ ਵਿਵਹਾਰਕ ਮਿਆਰ ਸੈੱਟ ਕਰਦੀਆਂ ਹਨ।

RSC ਆਕਰਸ਼ਕ ਕਿਉਂ ਲੱਗ ਰਿਹਾ ਸੀ

React Server Components ਭਾਰੀ data-fetching ਅਤੇ rendering ਦੇ ਕੰਮ ਨੂੰ ਸਰਵਰ 'ਤੇ ਤਬਦੀਲ ਕਰਨ ਦੇ ਇੱਕ ਤਰੀਕੇ ਵਜੋਂ ਆਏ ਸਨ, ਜੋ ਕਿ ਛੋਟੇ client bundles ਅਤੇ ਤੇਜ਼ ਪੇਜ ਲੋਡ ਹੋਣ ਦਾ ਵਾਅਦਾ ਕਰਦੇ ਸਨ। TanStack ਟੀਮ ਨੇ ਆਪਣੀਆਂ data-grid ਅਤੇ query ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ ਯੂਜ਼ਰ ਐਕਸਪੀਰੀਅੰਸ ਨੂੰ ਸੁਧਾਰਨ ਦੀ ਉਮੀਦ ਵਿੱਚ ਇਸ ਪਹੁੰਚ ਨੂੰ ਅਜ਼ਮਾਇਆ ਸੀ।

ਕਿਸ ਚੀਜ਼ ਨੇ ਉਹਨਾਂ ਨੂੰ ਪਿੱਛੇ ਹਟਣ ਲਈ ਮਜਬੂਰ ਕੀਤਾ

  • Complexity – RSC ਕੋਡ ਦੀ debugging ਲਈ ਇੱਕ ਵੱਖਰੇ ਮਾਨਸਿਕ ਮਾਡਲ ਦੀ ਲੋੜ ਸੀ। ਟੀਮ ਨੇ ਸਰਵਰ-ਸਾਈਡ ਰੈਂਡਰਿੰਗ (server-side rendering) ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਲੱਭਣ ਵਿੱਚ ਉਨਾ ਸਮਾਂ ਬਰਬਾਦ ਕੀਤਾ ਜਿੰਨਾ ਉਹ ਚਾਹੁੰਦੇ ਨਹੀਂ ਸਨ।
  • Flexibility – ਬਹੁਤ ਸਾਰੀਆਂ third-party ਲਾਇਬ੍ਰੇਰੀਆਂ ਸਿਰਫ਼ client ਵਾਤਾਵਰਣ ਨੂੰ ਮੰਨ ਕੇ ਚੱਲਦੀਆਂ ਹਨ। RSC ਦੇ ਸਿਰਫ਼ ਸਰਵਰ 'ਤੇ ਚੱਲਣ ਕਾਰਨ, ਉਹਨਾਂ dependencies ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੇ ਜਾਂ shimming ਕੀਤੇ ਬਿਨਾਂ ਉਹਨਾਂ ਨੂੰ ਜੋੜਨਾ ਮੁਸ਼ਕਲ ਹੋ ਗਿਆ।
  • Performance – ਮਾਪੀ ਗਈ ਰਫ਼ਤਾਰ ਵਿੱਚ ਸੁਧਾਰ ਮਾਮੂਲੀ ਸੀ। ਸਰਵਰ ਅਤੇ client ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਸੰਚਾਲਿਤ ਕਰਨ ਦਾ ਵਾਧੂ ਬੋਝ (overhead) ਜ਼ਿਆਦਾਤਰ ਅਸਲ ਦੁਨੀਆ ਦੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਮਾਮੂਲੀ ਲਾਭਾਂ ਨਾਲੋਂ ਵੱਧ ਸੀ।
  • Velocity – ਸਰਲ, ਸਿਰਫ਼ client-only ਪੈਟਰਨਾਂ ਨੇ ਟੀਮ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਅੱਪਡੇਟ ਜਾਰੀ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ। RSC ਦੇ ਨਾਲ, ਹਰ ਬਦਲਾਅ ਲਈ ਸਰਵਰ ਅਤੇ client ਦੋਵਾਂ 'ਤੇ ਵੈਲੀਡੇਸ਼ਨ ਦੀ ਲੋੜ ਸੀ, ਜਿਸ ਨਾਲ ਰਿਲੀਜ਼ ਚੱਕਰ (release cycle) ਹੌਲੀ ਹੋ ਗਿਆ।

ਵਿਆਪਕ ਪ੍ਰਭਾਵ

ਜੇਕਰ TanStack ਵਰਗਾ ਇੱਕ ਪ੍ਰਮੁੱਖ ਟੂਲਕਿੱਟ RSC ਤੋਂ ਪਿੱਛੇ ਹਟਦਾ ਹੈ, ਤਾਂ ਹੋਰ ਪ੍ਰੋਜੈਕਟ ਵੀ ਇਸ ਦੇ ਚਰਚੇ (hype) 'ਤੇ ਮੁੜ ਵਿਚਾਰ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਫੈਸਲਾ ਇੱਕ ਸਮਝੌਤੇ (trade-off) ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ: ਅਤਿ-ਆਧੁਨਿਕ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਜਿਹੀਆਂ ਲੁਕੀਆਂ ਹੋਈਆਂ ਲਾਗਤਾਂ ਲਿਆ ਸਕਦੀਆਂ ਹਨ ਜੋ ਡਿਵੈਲਪਰ ਦੀ ਉਤਪਾਦਕਤਾ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੇ ਰੱਖ-ਰਖਾਅ (maintenance) ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀਆਂ ਹਨ। ਉਹ ਕੰਪਨੀਆਂ ਜੋ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਾਅ (rapid iteration) ਅਤੇ ਵਿਆਪਕ ਲਾਇਬ੍ਰੇਰੀ ਅਨੁਕੂਲਤਾ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੀਆਂ ਹਨ, ਉਹ ਵੀ ਅਜਿਹਾ ਹੀ ਕਰ ਸਕਦੀਆਂ ਹਨ।

ਵਿਰੋਧੀ ਪੱਖ

ਕੁਝ ਡਿਵੈਲਪਰ ਅਜੇ ਵੀ ਖਾਸ ਮਾਮਲਿਆਂ ਲਈ RSC ਵਿੱਚ ਮੁੱਲ ਦੇਖਦੇ ਹਨ—ਖਾਸ ਕਰਕੇ ਜਿੱਥੇ ਸਰਵਰ-ਸਾਈਡ ਡਾਟਾ ਪ੍ਰੋਸੈਸਿੰਗ payload ਦੇ ਆਕਾਰ ਨੂੰ ਕਾਫ਼ੀ ਘਟਾ ਸਕਦੀ ਹੈ। ਇਹ ਪਹੁੰਚ ਵਿਕਸਿਤ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਭਵਿੱਖ ਦੇ ਟੂਲ ਉਹਨਾਂ ਮੁਸ਼ਕਲਾਂ ਨੂੰ ਹੱਲ ਕਰ ਸਕਦੇ ਹਨ ਜੋ TanStack ਨੇ ਦੱਸੀਆਂ ਹਨ। ਫਿਲਹਾਲ, ਇਸ ਬਾਰੇ ਵਿਚਾਰ ਮਿਲੇ-ਜੁਲੇ ਹਨ।

ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ

  • Tooling updates – Debugging ਅਤੇ integration ਸਪੋਰਟ ਵਿੱਚ ਸੁਧਾਰ ਜਟਿਲਤਾ ਦੀ ਰੁਕਾਵਟ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਨ।
  • Community feedback – ਜਿਵੇਂ-ਜਿਵੇਂ ਹੋਰ ਟੀਮਾਂ ਪ੍ਰਦਰਸ਼ਨ (performance) ਦਾ ਡਾਟਾ ਸਾਂਝਾ ਕਰਨਗੀਆਂ, ਲਾਗਤ-ਲਾਭ ਦਾ ਹਿਸਾਬ ਬਦਲ ਸਕਦਾ ਹੈ।
  • Alternative patterns – Incremental server rendering ਤਕਨੀਕਾਂ ਜਾਂ ਹਾਈਬ੍ਰਿਡ ਪਹੁੰਚ ਇੱਕ ਵਿਚਕਾਰਲਾ ਰਸਤਾ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੀਆਂ ਹਨ।

ਮੁੱਖ ਨੁਕਤਾ (Takeaway): React Server Components ਤੋਂ TanStack ਦਾ ਪਿੱਛੇ ਹਟਣਾ ਸਾਨੂੰ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹੈ ਕਿ ਨਵਾਂ ਹੋਣਾ ਹਮੇਸ਼ਾ ਬਿਹਤਰ ਨਹੀਂ ਹੁੰਦਾ; ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਨਵੇਂ ਪੈਟਰਨਾਂ ਨੂੰ ਅਪਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਵਰਕਫਲੋ 'ਤੇ ਪੈਣ ਵਾਲੀ ਅਸਲ ਲਾਗਤ ਅਤੇ ਵਾਅਦਾ ਕੀਤੇ ਲਾਭਾਂ ਦਾ ਮੁਕਾਬਲਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਸਰੋਤ: https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com