TanStack ਨੇ Table v9 ਦਾ ਬੀਟਾ ਲਾਂਚ ਕੀਤਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਡਾਟਾ-ਗਰਿੱਡ ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਜੋ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਸਿਰਫ਼ ਉਹਨਾਂ ਫੀਚਰਾਂ ਨੂੰ ਚੁਣਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਉਹਨਾਂ ਨੂੰ ਲੋੜ ਹੈ। ਬੰਡਲ ਦਾ ਆਕਾਰ ਘਟ ਕੇ ਲਗਭਗ 5 KB ਰਹਿ ਜਾਂਦਾ ਹੈ ਅਤੇ interaction-to-next-paint (INP) ਵਿੱਚ ਹੋਣ ਵਾਲੀ ਦੇਰੀ, ਜਿਸ ਕਾਰਨ sorting ਜਾਂ filtering ਅਟਕਦੀਆਂ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਸਨ, ਹੁਣ ਖ਼ਤਮ ਹੋ ਗਈਆਂ ਹਨ।
ਇਹ ਬਦਲਾਅ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
v8 ਵਿੱਚ, ਲਾਇਬ੍ਰੇਰੀ ਗਰਿੱਡ ਲੌਜਿਕ ਦਾ ਹਰ ਹਿੱਸਾ—sorting, filtering, pagination, row selection, grouping—ਭੇਜਦੀ ਹੈ, ਭਾਵੇਂ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਵੇ ਜਾਂ ਨਾ। ਉਹ ਵਾਧੂ ਕੋਡ ਮੇਨ ਥ੍ਰੈਡ (main thread) 'ਤੇ ਚਲਦਾ ਹੈ, ਬੰਡਲ ਦੇ ਆਕਾਰ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਯੂਜ਼ਰ ਐਕਸ਼ਨਾਂ ਵਿੱਚ ਦੇਰੀ (latency) ਪੈਦਾ ਕਰਦਾ ਹੈ। ਉਹ ਡੈਸ਼ਬੋਰਡਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਰਿਸਪੌਂਸਿਵ ਟੇਬਲਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਕੁਝ ਮਿਲੀਸੈਕਿੰਡ ਦੀ ਦੇਰੀ INP ਸਕੋਰ ਨੂੰ ਖ਼ਰਾਬ ਰੇਂਜ ਵਿੱਚ ਲੈ ਜਾ ਸਕਦੀ ਹੈ।
v9 ਵਿੱਚ ਕੀ ਵੱਖਰਾ ਹੈ
- Opt-in feature modules – ਸਿਰਫ਼ ਉਹ ਹਿੱਸੇ ਇੰਪੋਰਟ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਵਰਤੋਂ ਕਰਦੇ ਹੋ। ਜੇਕਰ ਤੁਸੀਂ sorting ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹੋ, ਤਾਂ sorting ਕੋਡ ਬੰਡਲ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹੋਵੇਗਾ।
- TanStack Store integration – ਇੱਕ fine-grained store ਨਾਲ ਸਟੇਟ (state) ਨੂੰ ਮੈਨੇਜ ਕਰੋ, ਤਾਂ ਜੋ ਇੱਕ ਰੋਅ (row) ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਨਾਲ ਫਿਲਟਰ ਬਾਰ ਜਾਂ ਹੋਰ ਅਸੰਬੰਧਿਤ UI ਦਾ ਪੂਰਾ re-render ਟ੍ਰਿਗਰ ਨਾ ਹੋਵੇ।
- Reduced memory footprint – ਘੱਟ ਆਬਜੈਕਟ ਅਤੇ ਐਰੇ (arrays) ਲੰਬੇ ਸੈਸ਼ਨਾਂ ਦੌਰਾਨ JavaScript heap 'ਤੇ ਦਬਾਅ ਘਟਾਉਂਦੇ ਹਨ।
ਇਹ ਬਦਲਾਅ ਇੱਕ ਛੋਟੇ ਡਾਊਨਲੋਡ (ਇੱਕ ਸਾਧਾਰਨ ਲਿਸਟ ਲਈ ਲਾਇਬ੍ਰੇਰੀ ਲਗਭਗ 5 KB ਦੀ ਹੋ ਸਕਦੀ ਹੈ) ਅਤੇ ਜਦੋਂ ਗਰਿੱਡ ਬਿਜ਼ੀ ਹੋਵੇ ਤਾਂ ਵਧੇਰੇ ਸੁਚਾਰੂ ਇੰਟਰੈਕਸ਼ਨ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ।
ਕਿਸ ਨੂੰ ਫਾਇਦਾ ਹੋਵੇਗਾ
- Frontend teams ਜੋ ਅੰਦਰੂਨੀ ਟੂਲਸ, ਐਡਮਿਨ ਪੈਨਲ, ਜਾਂ SaaS ਡੈਸ਼ਬੋਰਡ ਬਣਾ ਰਹੇ ਹਨ ਜਿੱਥੇ ਟੇਬਲ ਮੁੱਖ UI ਐਲੀਮੈਂਟ ਹਨ।
- Performance-focused sites ਜੋ Core Web Vitals ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੀਆਂ ਹਨ; ਘੱਟ INP ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਇਸ ਮੈਟ੍ਰਿਕ ਨੂੰ ਸੁਧਾਰਦਾ ਹੈ।
v9 ਕੀ ਠੀਕ ਨਹੀਂ ਕਰਦਾ
ਇਹ ਸੁਧਾਰ ਉਸ ਕੋਡ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੇ ਹਨ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਕੰਟਰੋਲ ਕਰਦੇ ਹੋ। ਇਹ ਉਸ ਪੇਜ ਦੀ ਰਫ਼ਤਾਰ ਨੂੰ ਜਾਦੂਈ ਤੌਰ 'ਤੇ ਨਹੀਂ ਵਧਾਉਣਗੇ ਜੋ ਇੱਕ ਵਿਸ਼ਾਲ JSON payload ਖਿੱਚਦਾ ਹੈ, ਅਤੇ ਨਾ ਹੀ ਇਹ ਕਿਸੇ ਭਾਰੀ ਤੀਜੀ-ਧਿਰ (third-party) ਸਕ੍ਰਿਪਟ ਦੀ ਲਾਗਤ ਨੂੰ ਘਟਾਉਣਗੇ। ਵੱਡੇ ਡੇਟਾ ਸੈੱਟਾਂ ਲਈ ਅਜੇ ਵੀ ਸਹੀ pagination ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਨੈੱਟਵਰਕ ਲੇਟੈਂਸੀ (latency) ਇੱਕ ਵੱਖਰੀ ਚਿੰਤਾ ਬਣੀ ਹੋਈ ਹੈ।
ਇੱਕ ਵਿਵਹਾਰਕ ਮਾਈਗ੍ਰੇਸ਼ਨ ਮਾਰਗ
- ਸਭ ਤੋਂ ਭਾਰੀ ਟੇਬਲਾਂ ਦੀ ਪਛਾਣ ਕਰੋ – ਉਹਨਾਂ ਆਰਡਰ ਲਿਸਟਾਂ, ਇਨਵੈਂਟਰੀ ਗਰਿੱਡਾਂ, ਜਾਂ CRM ਵਿਊਜ਼ ਨੂੰ ਲੱਭੋ ਜੋ ਪਹਿਲਾਂ ਹੀ ਮਹਿਸੂਸ ਹੋਣਯੋਗ ਦੇਰੀ ਦਿਖਾ ਰਹੇ ਹਨ।
- ਬੇਸਲਾਈਨ ਮੈਟ੍ਰਿਕਸ ਕੈਪਚਰ ਕਰੋ – ਕਿਸੇ ਵੀ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਪੇਜਾਂ 'ਤੇ INP ਅਤੇ ਲੰਬੇ-ਟਾਸਕ (long-task) ਦੀ ਮਿਆਦ ਨੂੰ ਰਿਕਾਰਡ ਕਰੋ।
- ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਗਰਿੱਡ ਮਾਈਗ੍ਰੇਟ ਕਰੋ – v8 ਇੰਪੋਰਟ ਨੂੰ v9 ਮੋਡੀਊਲ ਸੈੱਟ ਨਾਲ ਬਦਲੋ, ਅਤੇ ਸਿਰਫ਼ ਉਹਨਾਂ ਫੀਚਰਾਂ ਨੂੰ ਚਾਲੂ ਕਰੋ ਜੋ ਸਕ੍ਰੀਨ ਅਸਲ ਵਿੱਚ ਵਰਤਦੀ ਹੈ।
stockFeaturesਬੰਡਲ ਤੋਂ ਬਚੋ – ਡਿਫੌਲਟ ਫੀਚਰ ਸੈੱਟ ਨੂੰ ਵਰਤਣ ਨਾਲ ਸਾਈਜ਼ ਬਚਾਉਣ ਦਾ ਉਦੇਸ਼ ਖ਼ਤਮ ਹੋ ਜਾਂਦਾ ਹੈ।- ਇੰਟਰੈਕਸ਼ਨਾਂ ਦੀ ਮੁੜ-ਪਰੀਖਣ ਕਰੋ – ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਲਾਭ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ sorting, filtering, ਅਤੇ selection ਨੂੰ ਦੁਬਾਰਾ ਮਾਪੋ।
ਵਿਰੋਧੀ ਨੁਕਤਾ: ਇਹ ਕੋਈ ਜਾਦੂਈ ਹੱਲ ਨਹੀਂ ਹੈ
ਕੁਝ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਲੱਗ ਸਕਦਾ ਹੈ ਕਿ v9 ਹਰ ਸੁਸਤ UI ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰ ਦੇਵੇਗਾ। ਅਸਲ ਵਿੱਚ, ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਫਾਇਦੇ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਕਿੰਨਾ ਕਸਟਮ ਕੋਡ ਘਟਾ ਸਕਦੇ ਹੋ। ਜੇਕਰ ਕਿਸੇ ਟੇਬਲ ਦੀ ਮੁੱਖ ਸਮੱਸਿਆ ਰੋਅ (rows) ਦੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗਿਣਤੀ ਜਾਂ ਇੱਕ ਅਸਮਰੱਥ ਸਰਵਰ API ਹੈ, ਤਾਂ ਬੰਡਲ-ਸਾਈਜ਼ ਵਿੱਚ ਕਮੀ ਦਾ ਪ੍ਰਭਾਵ ਸੀਮਤ ਹੋਵੇਗਾ।
ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ
ਸਿੱਖਿਆ (Takeaway): TanStack Table v9 ਤੁਹਾਨੂੰ ਬੇਕਾਰ ਗਰਿੱਡ ਫੰਕਸ਼ਨੈਲਿਟੀ ਲਈ ਭੁਗਤਾਨ ਕਰਨ ਤੋਂ ਰੋਕਣ ਦਾ ਇੱਕ ਠੋਸ ਤਰੀਕਾ ਦਿੰਦਾ ਹੈ। ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਮੋਡੀਊਲ ਇੰਪੋਰਟ ਕਰਕੇ ਅਤੇ ਇੱਕ fine-grained store ਦੀ ਵਰਤੋਂ ਕਰਕੇ, ਤੁਸੀਂ ਆਪਣੇ ਬੰਡਲਾਂ ਵਿੱਚੋਂ ਕਈ ਕਿਲੋਬਾਈਟ ਘਟਾ ਸਕਦੇ ਹੋ ਅਤੇ ਟੇਬਲ ਇੰਟਰੈਕਸ਼ਨਾਂ ਨੂੰ ਮਹਿਸੂਸਯੋਗ ਤੌਰ 'ਤੇ ਤੇਜ਼ ਬਣਾ ਸਕਦੇ ਹੋ—ਬਸ਼ਰਤੇ ਕਿ ਤੁਸੀਂ ਅੱਪਗ੍ਰੇਡ ਨੂੰ ਸਮਝਦਾਰ ਡੇਟਾ-ਹੈਂਡਲਿੰਗ ਰਣਨੀਤੀਆਂ ਨਾਲ ਜੋੜੋ।