ਉਹ DOM ਬੋਟਲਨੇਕ (Bottleneck) ਜਿਸ ਬਾਰੇ ਕੋਈ ਗੱਲ ਨਹੀਂ ਕਰਦਾ
ਇੱਕ ਸਪੋਰਟ ਡੈਸ਼ਬੋਰਡ ਦੀ ਕਲਪਨਾ ਕਰੋ ਜੋ ਦਸ ਹਜ਼ਾਰ ਲੌਗ ਐਂਟਰੀਆਂ (log entries) ਖਿੱਚ ਰਿਹਾ ਹੋਵੇ। ਜਾਂ ਇੱਕ CRM ਜੋ ਇੱਕ ਸਿੰਗਲ ਸਕ੍ਰੋਲੇਬਲ ਟੇਬਲ ਵਿੱਚ ਹਰ ਸੰਪਰਕ ਨੂੰ ਦਿਖਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੋਵੇ। React ਵਿੱਚ, ਇਸ ਨੂੰ ਬਣਾਉਣ ਵਾਲਾ ਕੋਡ ਕਾਫ਼ੀ ਮਾਸੂਮ ਲੱਗਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਐਰੇ (array) ਉੱਤੇ ਮੈਪ (map) ਕਰਦੇ ਹੋ, ਕੁਝ JSX ਰਿਟਰਨ ਕਰਦੇ ਹੋ, ਅਤੇ ਫਰੇਮਵਰਕ ਨੂੰ ਆਪਣਾ ਕੰਮ ਕਰਨ ਦਿੰਦੇ ਹੋ। ਡਿਵੈਲਪਮੈਂਟ ਵਿੱਚ ਸੌ ਰੋਅਜ਼ (rows) ਦੇ ਨਾਲ ਸਭ ਕੁਝ ਠੀਕ ਕੰਮ ਕਰਦਾ ਹੈ। ਫਿਰ ਜਦੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਡੇਟਾ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਪੇਜ ਬਹੁਤ ਹੌਲੀ ਹੋ ਜਾਂਦਾ ਹੈ।
ਬ੍ਰਾਊਜ਼ਰ ਆਲਸੀ ਨਹੀਂ ਹੋ ਰਿਹਾ। ਇਹ ਉਹੀ ਕਰ ਰਿਹਾ ਹੈ ਜੋ ਤੁਸੀਂ ਇਸਨੂੰ ਕਰਨ ਲਈ ਕਿਹਾ ਹੈ, ਅਤੇ ਇਹੀ ਸਮੱਸਿਆ ਹੈ। ਹਰ ਰੋਅ (row) ਇੱਕ DOM ਨੋਡ ਬਣ ਜਾਂਦੀ ਹੈ। ਹਰ ਨੋਡ ਨੂੰ ਸਟਾਈਲ (style) ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਲੇਆਉਟ (layout) ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪੇਂਟ (paint) ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਮੈਮੋਰੀ ਵਿੱਚ ਟ੍ਰੈਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਸਕ੍ਰੋਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਪੂਰੇ ਟ੍ਰੀ (tree) ਲਈ ਸਥਿਤੀਆਂ ਦੀ ਮੁੜ-ਗਣਨਾ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਉਸ ਹਿੱਸੇ ਦੀ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਦੇਖ ਰਹੇ ਹੋ। ਇਵੈਂਟ ਲਿਸਨਰ (event listeners) ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਮੈਮੋਰੀ ਵਧ ਜਾਂਦੀ ਹੈ। ਅੰਤ ਵਿੱਚ, ਮੇਨ ਥ੍ਰੈਡ (main thread) ਇੰਨਾ ਜ਼ਿਆਦਾ ਰੁਕ ਜਾਂਦਾ ਹੈ ਕਿ ਇੰਟਰਫੇਸ ਕਲਿੱਕ, ਕੀਸਟ੍ਰੋਕਸ, ਜਾਂ ਸਕ੍ਰੋਲ ਨੂੰ ਵੀ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਕ੍ਰੈਸ਼ ਨਹੀਂ ਹੋਈ ਹੈ, ਪਰ ਇਸਦੇ ਸਾਹਮਣੇ ਬੈਠੇ ਯੂਜ਼ਰ ਲਈ, ਅਨੁਭਵ ਖਰਾਬ ਹੋ ਚੁੱਕਾ ਹੁੰਦਾ ਹੈ।
ਇਹ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਇੱਕੋ ਸਮੇਂ ਹਰ ਇੱਕ ਐਲੀਮੈਂਟ ਨੂੰ ਐਕਟਿਵ ਮੈਮੋਰੀ ਵਿੱਚ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। React ਤੁਹਾਡੇ UI ਦੇ ਵਰਚੁਅਲ ਵੇਰਵੇ (virtual descriptions) ਬਣਾਉਣ ਵਿੱਚ ਕੁਸ਼ਲ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇੱਕ ਵਾਰ ਜਦੋਂ ਉਹ ਵੇਰਵੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਅਸਲੀ ਨੋਡ ਬਣ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਦੀ ਕੀਮਤ ਉਨੀ ਹੀ ਹੁੰਦੀ ਹੈ ਜਿੰਨੀ ਹੱਥ ਨਾਲ ਲਿਖੇ HTML ਦੀ। ਫਰੇਮਵਰਕ ਵਿੱਚ ਹੀ ਇਸ ਤੋਂ ਬਚਣ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਇਸ ਗੱਲ ਵਿੱਚ ਇੱਕ ਸੰਰਚਨਾਤਮਕ ਤਬਦੀਲੀ (structural change) ਦੀ ਲੋੜ ਹੈ ਕਿ ਤੁਸੀਂ DOM ਨੂੰ ਲਿਸਟ ਕਿਵੇਂ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹੋ।
Virtualization ਦਾ ਅਸਲ ਮਤਲਬ ਕੀ ਹੈ
Virtualization ਉਹ ਸੰਰਚਨਾਤਮਕ ਤਬਦੀਲੀ ਹੈ। React ਨੂੰ ਪੂਰਾ ਐਰੇ ਰੈਂਡਰ (render) ਕਰਨ ਲਈ ਕਹਿਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਸਿਰਫ਼ ਉਹਨਾਂ ਆਈਟਮਾਂ ਨੂੰ ਰੈਂਡਰ ਕਰਦੇ ਹੋ ਜੋ ਵਿਊਪੋਰਟ (viewport) ਦੇ ਅੰਦਰ ਆ ਸਕਦੀਆਂ ਹਨ, ਨਾਲ ਹੀ ਉੱਪਰ ਅਤੇ ਹੇਠਾਂ ਇੱਕ ਛੋਟਾ ਬਫਰ (buffer)। ਜਿਵੇਂ-ਜਿਵੇਂ ਯੂਜ਼ਰ ਸਕ੍ਰੋਲ ਕਰਦਾ ਹੈ, ਐਪਲੀਕੇਸ਼ਨ ਉਹਨਾਂ ਨੋਡਾਂ ਨੂੰ ਹਟਾ ਦਿੰਦੀ ਹੈ ਜੋ ਨਜ਼ਰ ਤੋਂ ਬਾਹਰ ਚਲੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਦੂਜੀ ਧਿਰ ਤੋਂ ਆਉਣ ਵਾਲੇ ਨਵੇਂ ਨੋਡਾਂ ਨੂੰ ਬਣਾਉਂਦੀ ਹੈ। ਯੂਜ਼ਰ ਲਈ, ਇਹ ਅਜੇ ਵੀ ਇੱਕ ਲਗਾਤਾਰ ਲਿਸਟ ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਕੁੱਲ ਸਕ੍ਰੋਲੇਬਲ ਉਚਾਈ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਿੰਗਲ ਉੱਚੇ ਕੰਟੇਨਰ ਐਲੀਮੈਂਟ ਜਾਂ ਧਿਆਨ ਨਾਲ ਗਣਨਾ ਕੀਤੇ ਗਏ ਸਪੇਸਰ (spacer) ਰਾਹੀਂ। ਦਿਖਾਈ ਦੇਣ ਵਾਲੀਆਂ ਆਈਟਮਾਂ ਸਿਰਫ਼ ਡੇਟਾਸੈੱਟ ਦੇ ਉੱਪਰ ਫਿਰਦੀ ਇੱਕ ਖਿੜਕੀ ਵਾਂਗ ਹੁੰਦੀਆਂ ਹਨ।
ਇਸਨੂੰ ਪ੍ਰੋਜੈਕਟਰ ਗੇਟ ਰਾਹੀਂ ਚੱਲ ਰਹੀ ਫਿਲਮ ਦੀ ਰੀਲ ਵਾਂਗ ਸਮਝੋ। ਦਰਸ਼ਕ ਸੁਚੱਜੀ ਗਤੀ ਦੇਖਦੇ ਹਨ, ਪਰ ਮਸ਼ੀਨਰੀ ਸਿਰਫ਼ ਉਸ ਫਰੇਮ ਨੂੰ ਰੋਸ਼ਨੀ ਦਿੰਦੀ ਹੈ ਜੋ ਇਸ ਸਮੇਂ ਸਥਿਤੀ ਵਿੱਚ ਹੈ। ਰੀਲ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਫੀਡ ਅਤੇ ਟੇਕ-ਅੱਪ ਸਪੂਲਜ਼ (spools) 'ਤੇ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਰੋਸ਼ਨੀ ਦੇ ਮਾਰਗ ਵਿੱਚ। Virtualized ਲਿਸਟਾਂ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਡੇਟਾਸੈੱਟ ਰੀਲ ਹੈ। ਵਿਊਪੋਰਟ ਗੇਟ ਹੈ।
ਇਹ ਰਵਾਇਤੀ ਅਰਥਾਂ ਵਿੱਚ lazy loading ਨਹੀਂ ਹੈ। Lazy loading ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਨੂੰ ਉਦੋਂ ਤੱਕ ਟਾਲ ਦਿੰਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਯੂਜ਼ਰ ਇਸਦੇ ਨੇੜੇ ਸਕ੍ਰੋਲ ਨਹੀਂ ਕਰਦਾ। Virtualization ਇਹ ਮੰਨ ਕੇ ਚੱਲਦੀ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਡੇਟਾ ਹੈ, ਪਰ ਤੁਸੀਂ ਚੁਣ ਕੇ ਦੱਸਦੇ ਹੋ ਕਿ ਕਿਹੜੇ ਹਿੱਸੇ ਨੂੰ ਅਸਲੀ DOM ਐਲੀਮੈਂਟਾਂ ਵਿੱਚ ਬਦਲਣਾ ਹੈ। ਇਹ ਦੋਵੇਂ ਤਕਨੀਕਾਂ ਇਕੱਠੇ ਕੰਮ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਵੱਖ-ਵੱਖ ਸਮੱਸਿਆਵਾਂ ਦਾ ਹੱਲ ਕਰਦੀਆਂ ਹਨ।
ਫਰਕ ਤੁਰੰਤ ਕਿਉਂ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ
ਇਸਦੇ ਫਾਇਦੇ ਚਾਰ ਥਾਵਾਂ 'ਤੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਜੋ ਸਾਰੇ ਇੱਕੋ ਹੀ ਅਸਲ ਰਾਹਤ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ: ਤੁਸੀਂ ਉਸ ਚੀਜ਼ ਲਈ ਕੀਮਤ ਚੁਕਾਉਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਜੋ ਯੂਜ਼ਰ ਨਹੀਂ ਦੇਖ ਸਕਦਾ।
ਤੇਜ਼ ਸ਼ੁਰੂਆਤੀ ਲੋਡ ਸਮਾਂ। ਜਦੋਂ ਬ੍ਰਾਊਜ਼ਰ ਪੇਜ ਖੋਲ੍ਹਦਾ ਹੈ, ਤਾਂ ਇਹ ਪੰਦਰਾਂ ਹਜ਼ਾਰ ਦੀ ਬਜਾਏ ਸ਼ਾਇਦ ਪੰਦਰਾਂ ਰੋਅਜ਼ (rows) ਪੇਂਟ ਕਰਦਾ ਹੈ। ਪਹਿਲਾ ਮਤਲਬ ਰੱਖਣ ਵਾਲਾ ਪੇਂਟ (meaningful paint) ਜਲਦੀ ਆਉਂਦਾ ਹੈ। Time-to-interactive ਘਟ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ JavaScript ਇੰਜਣ ਨੋਡ ਬਣਾਉਣ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਨਾਲ ਜੋੜਨ ਵਿੱਚ ਘੱਟ ਸਮਾਂ ਬਿਤਾਉਂਦਾ ਹੈ।
ਘੱਟ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ। ਇੱਕ DOM ਨੋਡ ਇੱਕ ਮਹਿੰਗੀ ਆਬਜੈਕਟ ਹੈ। ਹਰ ਇੱਕ ਵਿੱਚ ਸਟਾਈਲ ਨਿਯਮਾਂ, ਲੇਆਉਟ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਇਵੈਂਟ ਬਾਈਂਡਿੰਗਜ਼ ਦੇ ਰੈਫਰੈਂਸ ਹੁੰਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਐਕਟਿਵ ਨੋਡਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਕੁਝ ਦਰਜਨ ਤੱਕ ਘਟਾ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਬਹੁਤ ਘੱਟ ਜਾਂਦੀ ਹੈ। ਘੱਟ ਸਮਰੱਥਾ ਵਾਲੇ ਡਿਵਾਈਸਾਂ
ਪਹਿਲਾਂ, ਕੰਟੇਨਰ (container) ਦੀ ਇੱਕ ਨਿਰਧਾਰਤ ਉਚਾਈ (defined height) ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਜੇਕਰ ਲਿਸਟ ਕਿਸੇ ਅਜਿਹੇ ਪੇਰੈਂਟ (parent) ਦੇ ਅੰਦਰ ਹੈ ਜੋ ਆਪਣੇ ਬੱਚਿਆਂ ਦੇ ਅਨੁਸਾਰ ਵਧਦਾ ਹੈ, ਤਾਂ virtualization ਇਹ ਗਣਨਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿ ਕਿਹੜੀਆਂ ਆਈਟਮਾਂ ਦਿਖਾਈ ਦੇ ਰਹੀਆਂ ਹਨ ਕਿਉਂਕਿ ਕੋਈ ਵੀਅੂਪੋਰਟ ਬਾਊਂਡਰੀ (viewport boundary) ਨਹੀਂ ਹੁੰਦੀ। ਤੁਹਾਨੂੰ ਲਿਸਟ ਨੂੰ ਇੱਕ ਫਿਕਸਡ ਉਚਾਈ (fixed height) ਜਾਂ ਜਾਣੇ-ਪਛਾਣੇ ਨਿਯਮਾਂ ਵਾਲੇ ਫਲੈਕਸ ਕੰਟੇਨਰ (flex container) ਵਿੱਚ ਲੌਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਦੂਜਾ, ਆਈਟਮ ਦਾ ਸਾਈਜ਼ (item sizing) ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਫਿਕਸਡ-ਹਾਈਟ ਰੋਅਜ਼ (Fixed-height rows) ਸਭ ਤੋਂ ਸੌਖਾ ਮਾਮਲਾ ਹਨ। ਲਾਇਬ੍ਰੇਰੀ ਰੋਅ ਦੀ ਉਚਾਈ ਨੂੰ ਇੰਡੈਕਸ (index) ਨਾਲ ਗੁਣਾ ਕਰਦੀ ਹੈ ਅਤੇ ਜਾਣਦੀ ਹੈ ਕਿ ਹਰੇਕ ਐਲੀਮੈਂਟ ਨੂੰ ਕਿੱਥੇ ਰੱਖਣਾ ਹੈ। ਵੈਰੀਏਬਲ-ਹਾਈਟ ਕੰਟੈਂਟ (Variable-height content), ਜਿਵੇਂ ਕਿ ਇਮਬੈਡਡ ਚਿੱਤਰਾਂ ਵਾਲੇ ਚੈਟ ਮੈਸੇਜ ਜਾਂ ਕਮੈਂਟ ਥ੍ਰੈਡਸ, ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਮਾਊਂਟ (mount) ਤੋਂ ਬਾਅਦ ਮਾਪਣ ਅਤੇ ਤੁਰੰਤ ਅਨੁਕੂਲਿਤ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਇਹ ਮਾਪਣ ਦਾ ਕਦਮ ਬਹੁਤ ਦੇਰੀ ਨਾਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਸ ਨਾਲ ਸਕ੍ਰੋਲ ਜਿੱਟਰ (scroll jitter) ਹੋ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡਾ ਡੇਟਾ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇੱਕਸਾਰ ਉਚਾਈਆਂ ਜਾਂ ਘੱਟੋ-ਘੱਟ ਉਚਾਈਆਂ ਲਾਗੂ ਕਰੋ। ਜੇਕਰ ਨਹੀਂ, ਤਾਂ ਵੈਰੀਏਬਲ-ਹਾਈਟ ਵਰਚੁਅਲਾਈਜ਼ਰ (variable-height virtualizer) ਦੀ ਵਰਤੋਂ ਕਰੋ ਅਤੇ ਵਾਧੂ ਗੁੰਝਲਦਾਰਤਾ ਨੂੰ ਸਵੀਕਾਰ ਕਰੋ।
ਤੀਜਾ, ਓਵਰਸਕੈਨਿੰਗ (overscanning) ਤੁਹਾਡਾ ਦੋਸਤ ਹੈ। ਸਕ੍ਰੀਨ 'ਤੇ ਜੋ ਕੁਝ ਫਿੱਟ ਹੁੰਦਾ ਹੈ ਸਿਰਫ਼ ਉਸੇ ਨੂੰ ਰੈਂਡਰ (render) ਕਰਨ ਨਾਲ ਉਦੋਂ ਖਾਲੀ ਚਿੱਟੀਆਂ ਪੱਟੀਆਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ ਜਦੋਂ ਯੂਜ਼ਰ ਤੇਜ਼ੀ ਨਾਲ ਸਕ੍ਰੋਲ ਕਰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਤੁਹਾਨੂੰ ਫੋਲਡ (fold) ਦੇ ਉੱਪਰ ਅਤੇ ਹੇਠਾਂ ਕੁਝ ਵਾਧੂ ਆਈਟਮਾਂ ਰੈਂਡਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ। DOM ਨੂੰ ਦੁਬਾਰਾ ਵਧਾਏ ਬਿਨਾਂ ਜੋੜਾਂ ਨੂੰ ਲੁਕਾਉਣ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਜਾਂ ਤਿੰਨ ਰੋਅਜ਼ ਦਾ ਓਵਰਸਕੈਨ (overscan) ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ।
ਚੌਥਾ, key prop ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਾ ਕਰੋ। ਇੱਕ ਵਰਚੁਅਲਾਈਜ਼ਡ ਲਿਸਟ ਵਿੱਚ, ਜਿਵੇਂ-ਜਿਵੇਂ ਤੁਸੀਂ ਸਕ੍ਰੋਲ ਕਰਦੇ ਹੋ, ਆਈਟਮਾਂ DOM ਨੋਡਸ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਦੀਆਂ ਹਨ। ਸਟੇਬਲ ਕੀਜ਼ (Stable keys) React ਨੂੰ ਰੀਕੰਸਲੀਏਸ਼ਨ (reconciliation) ਦੌਰਾਨ ਗਲਤ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਅਤੇ ਰੋਅ ਕੰਪੋਨੈਂਟਸ ਦੇ ਅੰਦਰ ਸਟੇਟ (state) ਨੂੰ ਤਬਾਹ ਕਰਨ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ। ਜੇਕਰ ਤੁਹਾਡੀ ਲਿਸਟ ਦੀਆਂ ਰੋਅਜ਼ ਵਿੱਚ ਇਨਪੁੱਟਸ, ਟੌਗਲਜ਼, ਜਾਂ ਵਧਣਯੋਗ ਸੈਕਸ਼ਨ ਹਨ, ਤਾਂ ਮਾੜੀਆਂ ਕੀਜ਼ UI ਸਟੇਟ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਖਰਾਬ ਕਰ ਦੇਣਗੀਆਂ ਜੋ ਤੁਹਾਡੇ ਡੇਟਾ ਲੇਅਰ ਵਿੱਚ ਬੱਗ ਵਾਂਗ ਲੱਗ ਸਕਦੇ ਹਨ ਪਰ ਅਸਲ ਵਿੱਚ ਰੈਂਡਰਿੰਗ ਦੀਆਂ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।
ਇੱਕ ਬਾਰੀਕ ਜਿਹਾ ਜਾਲ ਬ੍ਰਾਊਜ਼ਰ ਦਾ find-in-page ਹੈ। ਕਿਉਂਕਿ ਲੁਕਾਈਆਂ ਹੋਈਆਂ ਆਈਟਮਾਂ DOM ਵਿੱਚ ਮੌਜੂਦ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਇਸ ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਸਰਚ ਬਾਕਸ ਉਹਨਾਂ ਨੂੰ ਨਹੀਂ ਦੇਖ ਸਕੇਗਾ। ਜੇਕਰ ਤੁਹਾਡੇ ਯੂਜ਼ਰ ਵੱਡੀ ਲਿਸਟ ਦੇ ਅੰਦਰ ਟੈਕਸਟ ਲੱਭਣ ਲਈ Ctrl+F 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਕਸਟਮ ਸਰਚ ਬਣਾਉਣੀ ਪਵੇਗੀ ਜੋ ਡਾਕੂਮੈਂਟ ਦੇ ਨਹੀਂ, ਸਗੋਂ ਡੇਟਾਸੈੱਟ ਦੇ ਵਿਰੁੱਧ ਕੰਮ ਕਰੇ। ਜੇਕਰ ਲਿਸਟ ਦੇ ਸੈਮੈਂਟਿਕਸ ਨੂੰ ਧਿਆਨ ਨਾਲ ਨਹੀਂ ਸੰਭਾਲਿਆ ਗਿਆ, ਤਾਂ ਸਕ੍ਰੀਨ ਰੀਡਰ ਵੀ ਸੰਦਰਭ ਗੁਆ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਸਹਾਇਕ ਤਕਨਾਲੋਜੀ ਨਾਲ ਟੈਸਟ ਕਰੋ ਅਤੇ ਡਾਇਨਾਮਿਕ ਲੋਡਿੰਗ ਲਈ ਲਾਈਵ ਰੀਜਨ ਐਨਾਂਸਮੈਂਟਸ ਜੋੜਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।
ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਕਦੋਂ ਛੱਡ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ
ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਮੁਫ਼ਤ ਨਹੀਂ ਹੈ। ਇਹ ਡਿਪੈਂਡੈਂਸੀ ਵੇਟ, ਕੋਆਰਡੀਨੇਟ ਮੈਥ, ਅਤੇ ਕੰਸਟ੍ਰੇਂਟ ਓਵਰਹੈੱਡ ਵਧਾਉਂਦੀ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੀ ਲਿਸਟ ਪੰਜਾਹ ਜਾਂ ਇੱਕ ਸੌ ਆਈਟਮਾਂ ਤੱਕ ਹੀ ਸੀਮਾ ਰੱਖਦੀ ਹੈ, ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਇਸਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਮਦਦ ਦੇ ਸੰਭਾਲ ਸਕਦਾ ਹੈ। ਪੂਰੀ ਚੀਜ਼ ਨੂੰ ਰੈਂਡਰ ਕਰੋ ਅਤੇ ਅੱਗੇ ਵਧੋ। ਇਹੀ ਗੱਲ ਉਦੋਂ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ ਜੇਕਰ ਤੁਹਾਡੀਆਂ ਲਿਸਟ ਆਈਟਮਾਂ ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ ਬਹੁਤ ਗੁੰਝਲਦਾਰ ਹਨ। ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਤੁਹਾਨੂੰ ਹਜ਼ਾਰਾਂ ਨੋਡਸ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ, ਪਰ ਇਹ ਤੁਹਾਨੂੰ ਇੱਕ ਅਜਿਹੇ ਨੋਡ ਤੋਂ ਨਹੀਂ ਬਚਾ ਸਕਦੀ ਜਿਸ ਵਿੱਚ ਇੱਕ ਵਿਸ਼ਾਲ ਚਾਰਟ ਜਾਂ ਵੀਡੀਓ ਐਲੀਮੈਂਟ ਹੋਵੇ। ਪਹਿਲਾਂ ਆਈਟਮ ਦੇ ਵਾਧੂ ਭਾਰ ਨੂੰ ਠੀਕ ਕਰੋ।
ਜਦੋਂ ਲਿਸਟ ਸਕ੍ਰੋਲ ਨਹੀਂ ਹੁੰਦੀ, ਤਾਂ ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਤੋਂ ਬਚੋ। ਜੇਕਰ ਤੁਸੀਂ next ਅਤੇ previous ਬਟਨਾਂ ਨਾਲ ਪੇਜਿੰਗ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਪ੍ਰਤੀ ਪੇਜ ਸਿਰਫ਼ ਵੀਹ ਆਈਟਮਾਂ ਦਿਖਾ ਰਹੇ ਹੋ, ਤਾਂ ਵਿੰਡੋ ਕਰਨ ਲਈ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ। ਇਹ ਤਕਨੀਕ ਉਦੋਂ ਹੀ ਫਾਇਦੇਮੰਦ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਯੂਜ਼ਰ ਇੱਕ ਵੱਡੀ ਲਗਾਤਾਰ ਲੜੀ ਵਿੱਚ ਸਕ੍ਰੋਲ ਕਰਨ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ।
ਅਸਲ ਸਿੱਖਿਆ
ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਚੋਣ ਘੱਟ ਅਤੇ ਇੱਕ ਮਾਨਸਿਕਤਾ (mindset) ਜ਼ਿਆਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਮੰਨਣ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ ਕਿ DOM ਇੱਕ ਸੀਮਤ ਸਰੋਤ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਅਨੰਤ ਕੈਨਵਸ। ਇਸਨੂੰ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ, Chrome DevTools ਖੋਲ੍ਹੋ, ਇੱਕ ਪਰਫਾਰਮੈਂਸ ਪ੍ਰੋਫਾਈਲ ਰਿਕਾਰਡ ਕਰੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੀ ਲੇਆਉਟ ਜਾਂ ਪੇਂਟ ਟਾਈਮ ਹੀ ਅਸਲ ਵਿੱਚ ਮੁੱਖ ਕਾਰਨ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਹਾਨੂੰ ਪਤਾ ਲੱਗ ਜਾਵੇ ਕਿ DOM ਹੀ ਰੁਕਾਵਟ ਹੈ, ਤਾਂ ਕੰਸਟ੍ਰੇਂਟਸ ਨੂੰ ਅਪਣਾਓ। ਆਪਣੀਆਂ ਉਚਾਈਆਂ ਨੂੰ ਲੌਕ ਕਰੋ, ਆਪਣੀਆਂ ਕੀਜ਼ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ, ਮਿਡਲਮ ਪੱਧਰ 'ਤੇ ਓਵਰਸਕੈਨ ਕਰੋ, ਅਤੇ ਆਪਣੀ ਐਕਸੈਸਬਿਲਟੀ ਦਾ ਟੈਸਟ ਕਰੋ। ਜੇਕਰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਜਾਵੇ, ਤਾਂ ਇੱਕ ਵਰਚੁਅਲਾਈਜ਼ਡ ਲਿਸਟ ਇੱਕ ਅਸਮਰੱਥ ਡੇਟਾ ਦੀ ਕੰਧ ਨੂੰ ਅਜਿਹੀ ਚੀਜ਼ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ ਜੋ ਇੱਕ ਨੇਟਿਵ ਸਕ੍ਰੋਲ ਵਿਊ ਵਾਂਗ ਹਲਕੀ ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਲੜਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਤੁਹਾਡੇ ਯੂਜ਼ਰ ਇੰਤਜ਼ਾਰ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਐਪ ਅੰਤ ਵਿੱਚ ਉਸ ਤੇਜ਼ ਇੰਟਰਫੇਸ ਵਾਂਗ ਕੰਮ ਕਰਦੀ ਹੈ ਜਿਸ ਨੂੰ ਬਣਾਉਣ ਦਾ ਤੁਸੀਂ ਇਰਾਦਾ ਰੱਖਿਆ ਸੀ।