Twenty items in a feed feels perfect. The scroll is butter. Your client is happy. Then you ship to production, the data

ਫੀਡ ਵਿੱਚ ਵੀਹ ਆਈਟਮਾਂ ਹੋਣਾ ਬਿਲਕੁਲ ਸਹੀ ਲੱਗਦਾ ਹੈ। ਸਕ੍ਰੋਲਿੰਗ ਬਹੁਤ ਸੁਚਾਰੂ ਹੁੰਦੀ ਹੈ। ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਖੁਸ਼ ਹੈ। ਫਿਰ ਤੁਸੀਂ ਇਸਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਲਾਂਚ ਕਰਦੇ ਹੋ, ਡਾਟਾ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਅਚਾਨਕ ਤੁਸੀਂ ਦੋ ਹਜ਼ਾਰ ਰੋਅਜ਼ (rows) ਦੇ ਸਾਹਮਣੇ ਹੁੰਦੇ ਹੋ। UI ਅਟਕਣ ਲੱਗ ਪੈਂਦਾ ਹੈ। ਮੈਮੋਰੀ ਇੰਨੀ ਵਧ ਜਾਂਦੀ ਹੈ ਕਿ OS ਐਪ ਨੂੰ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਨਿਰਾਸ਼ਾ ਵਿੱਚ, ਕੁਝ ਡਿਵੈਲਪਰ ਸਭ ਕੁਝ ਇੱਕ ScrollView ਵਿੱਚ ਲਪੇਟ ਦਿੰਦੇ ਹਨ ਅਤੇ ਆਪਣਾ ਕੰਮ ਖਤਮ ਕਰ ਲੈਂਦੇ ਹਨ। ਇਹ ਫੈਸਲਾ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਬੱਗ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਬਜਾਏ ਤਿੰਨ ਨਵੇਂ ਬੱਗਸ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਲਿਸਟਾਂ ਉਹ ਪਰਫਾਰਮੈਂਸ ਰੁਕਾਵਟ ਹਨ ਜੋ ਇਹ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਯੂਜ਼ਰ ਤੁਹਾਡੀ React Native ਐਪ ਨੂੰ ਕਿਵੇਂ ਦੇਖਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਐਪ ਨੇਟਿਵ (native) ਮਹਿਸੂਸ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਗਲਤੀ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਸਭ ਤੋਂ ਸੁੰਦਰ ਸਕ੍ਰੀਨ ਵੀ ਬਹੁਤ ਸੁਸਤ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਸਦਾ ਮੁੱਖ ਕਾਰਨ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਕੰਪੋਨੈਂਟ ਅਤੇ ਉਸ ਕੰਮ ਦੇ ਵਿਚਕਾਰ ਅਸੰਤੁਲਨ ਹੁੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ JavaScript ਅਤੇ UI threads ਨੂੰ ਕਰਨ ਲਈ ਕਹਿ ਰਹੇ ਹੋ। React Native ਦੋ ਟ੍ਰੈਕਾਂ 'ਤੇ ਚੱਲਦਾ ਹੈ। ਤੁਹਾਡਾ ਲੋਜਿਕ JS thread 'ਤੇ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਪੇਂਟਿੰਗ native UI thread 'ਤੇ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਵੱਡੀ ਲਿਸਟ ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਰੈਂਡਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਦੋਵੇਂ threads ਲੇਆਉਟ ਕੈਲਕੂਲੇਸ਼ਨਾਂ, re-renders, ਅਤੇ ਮੈਮੋਰੀ ਅਲੋਕੇਸ਼ਨਾਂ ਵਿੱਚ ਡੁੱਬਣ ਲੱਗ ਪੈਂਦੇ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ ਫਰੇਮ ਡ੍ਰੌਪ ਹੁੰਦੇ ਹਨ, ਸਕ੍ਰੀਨ ਖਾਲੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਅੰਤ ਵਿੱਚ ਐਪ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦੀ ਹੈ।

ਸਹੀ ਟੂਲ ਚੁਣੋ

ਲਿਸਟ ਕੰਪੋਨੈਂਟ ਦੀ ਚੋਣ ਇੱਕ ਸੋਚਿਆ-ਸਮਝਿਆ ਆਰਕੀਟੈਕਚਰਲ ਫੈਸਲਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਕੋਈ ਅਚਾਨਕ ਲਿਆ ਗਿਆ ਫੈਸਲਾ।

ScrollView ਸਭ ਤੋਂ ਸਧਾਰਨ ਵਿਕਲਪ ਹੈ। ਇਹ ਤੁਹਾਡੇ ਦੁਆਰਾ ਦਿੱਤੇ ਗਏ ਹਰ ਚਾਈਲਡ ਨੂੰ ਲੈਂਦਾ ਹੈ, ਹਰ ਇੱਕ ਨੂੰ ਤੁਰੰਤ ਮੈਮੋਰੀ ਵਿੱਚ ਮਾਊਂਟ (mount) ਕਰਦਾ ਹੈ, ਅਤੇ ਪੂਰੇ ਢੇਰ ਨੂੰ native scroll engine ਨੂੰ ਸੌਂਪ ਦਿੰਦਾ ਹੈ। ਇਹ ਉਹੀ ਹੈ ਜੋ ਤੁਸੀਂ ਛੋਟੇ, ਫਿਕਸਡ ਕੰਟੈਂਟ ਲਈ ਚਾਹੁੰਦੇ ਹੋ ਜਿਵੇਂ ਕਿ ਸੈਟਿੰਗਜ਼ ਸਕ੍ਰੀਨ, ਲੌਗਇਨ ਫਾਰਮ, ਜਾਂ ਦਸ ਸੈਕਸ਼ਨਾਂ ਵਾਲਾ ਇੱਕ ਸਟੈਟਿਕ ਪ੍ਰੋਡਕਟ ਡਿਟੇਲ ਪੇਜ। ਇਹ ਭਰੋਸੇਯੋਗ ਹੈ ਅਤੇ ਇਸਨੂੰ ਸਟਾਈਲ ਕਰਨਾ ਆਸਾਨ ਹੈ। ਮੁੱਖ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਇਸ ਵਿੱਚ ਕੋਈ virtualization ਨਹੀਂ ਹੁੰਦਾ। ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਦੋ ਹਜ਼ਾਰ ਆਈਟਮਾਂ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਆਗਿਆਕਾਰੀ ਵਾਂਗ ਦੋ ਹਜ਼ਾਰ native views ਬਣਾ ਦੇਵੇਗਾ। ਵੱਡੇ ਜਾਂ ਡਾਇਨਾਮਿਕ ਡਾਟਾ ਸੈੱਟਾਂ ਲਈ ScrollView ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ। ਇਸਨੂੰ ਇੱਕ ਫਰੇਮ ਕੀਤੇ ਪੋਸਟਰ ਵਾਂਗ ਸਮਝੋ, ਨਾ ਕਿ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਸ਼ੈਲਫ ਵਾਂਗ।

FlatList ਲੰਬੀਆਂ, ਇੱਕੋ ਜਿਹੀਆਂ ਫੀਡਾਂ ਲਈ ਕੰਮ ਕਰਨ ਵਾਲਾ ਮੁੱਖ ਸਾਧਨ ਹੈ। ਇਹ ਕੰਟੈਂਟ ਨੂੰ virtualize ਕਰਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਸਿਰਫ਼ ਉਹਨਾਂ ਰੋਅਜ਼ ਨੂੰ ਮਾਊਂਟ ਕਰਦਾ ਹੈ ਜੋ ਇਸ ਸਮੇਂ ਦਿਖਾਈ ਦੇ ਰਹੇ ਹਨ ਜਾਂ ਵਿਊਪੋਰਟ (viewport) ਦੇ ਨੇੜੇ ਹਨ। ਜਿਵੇਂ ਹੀ ਯੂਜ਼ਰ ਸਕ੍ਰੋਲ ਕਰਦਾ ਹੈ, FlatList ਉਹਨਾਂ ਸੈੱਲਾਂ ਨੂੰ ਅਨਮਾਊਂਟ (unmount) ਕਰ ਦਿੰਦਾ ਹੈ ਜੋ ਸਕ੍ਰੀਨ ਤੋਂ ਬਾਹਰ ਚਲੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਨਵੇਂ ਡਾਟਾ ਲਈ ਰੀਸਾਈਕਲ (recycle) ਕਰਦਾ ਹੈ। ਇਹ ਮੈਮੋਰੀ ਨੂੰ ਸਥਿਰ ਰੱਖਦਾ ਹੈ ਭਾਵੇਂ ਤੁਹਾਡਾ ਐਰੇ (array) ਕਿੰਨਾ ਵੀ ਵੱਡਾ ਕਿਉਂ ਨਾ ਹੋ ਜਾਵੇ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਸੋਸ਼ਲ ਟਾਈਮਲਾਈਨ, ਨੋਟੀਫਿਕੇਸ਼ਨ ਸੈਂਟਰ, ਜਾਂ ਸਮਾਨ ਕਾਰਡਾਂ ਦਾ ਕੋਈ ਲਗਾਤਾਰ ਸਕ੍ਰੋਲ ਹੋਣ ਵਾਲਾ ਕਲੈਕਸ਼ਨ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ FlatList ਸਹੀ ਚੋਣ ਹੈ।

SectionList ਵਿਵਸਥਿਤ ਤਰੀਕੇ ਨਾਲ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ FlatList ਹੈ। ਇਸਦੀ ਵਰਤੋਂ ਉਦੋਂ ਕਰੋ ਜਦੋਂ ਤੁਹਾਡਾ ਡਾਟਾ ਸਮੂਹਾਂ (groups) ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਅਲਫਾਬੈਟਿਕਲ ਤੌਰ 'ਤੇ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਐਡਰੈੱਸ ਬੁੱਕ, ਮਿਤੀ ਦੁਆਰਾ ਵੰਡਿਆ ਗਿਆ ਵਰਕਆਊਟ ਲੌਗ, ਜਾਂ ਮਹੀਨੇ ਅਨੁਸਾਰ ਵਿਵਸਥਿਤ ਇਨਵੌਇਸ ਲਿਸਟ। ਇਹ ਸਟਿੱਕੀ ਸੈਕਸ਼ਨ ਹੈਡਰਾਂ ਨੂੰ ਰੈਂਡਰ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਲਈ ਗਰੁੱਪਿੰਗ ਲੋਜਿਕ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। ਇਸਦੇ ਅੰਦਰ ਇਹ FlatList ਵਾਂਗ ਹੀ ਉਹੀ virtualization engine ਵਰਤਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਟਾਈਟਲਡ ਪਾਰਟੀਸ਼ਨਾਂ ਦੇ ਵਾਧੂ ਢਾਂਚੇ ਦੇ ਨਾਲ ਇੱਕੋ ਜਿਹੇ ਮੈਮੋਰੀ ਲਾਭ ਮਿਲਦੇ ਹਨ।

FlashList ਉਦੋਂ ਕੰਮ ਆਉਂਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਡਿਵਾਈਸ ਤੋਂ ਹਰ ਇੱਕ ਆਖਰੀ ਫਰੇਮ ਕੱਢਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। RecyclerListView ecosystem 'ਤੇ ਬਣਿਆ ਹੋਇਆ, ਇਹ FlatList ਨਾਲੋਂ ਵਧੇਰੇ ਤੇਜ਼ੀ ਨਾਲ ਵਿਊਜ਼ ਨੂੰ ਰੀਸਾਈਕਲ ਕਰਦਾ ਹੈ ਅਤੇ ਮਿਡ-ਰੇਂਜ ਹਾਰਡਵੇਅਰ 'ਤੇ ਵੀ ਸੱਠ (60) ਫਰੇਮ ਪ੍ਰਤੀ ਸੈਕੰਡ ਬਣਾਈ ਰੱਖਣ ਦਾ ਟੀਚਾ ਰੱਖਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਉੱਚ-ਵਾਲੀਅਮ ਵਾਲਾ ਚੈਟ ਇੰਟਰਫੇਸ, ਤੇਜ਼ ਸਕ੍ਰੋਲ ਵਾਲਾ ਪ੍ਰੋਡਕਟ ਕੈਟਾਲਾਗ, ਜਾਂ ਕੋਈ ਅਜਿਹੀ ਸਕ੍ਰੀਨ ਬਣਾ ਰਹੇ ਹੋ ਜਿੱਥੇ ਮੁਲਾਇਮਤਾ (smoothness) ਇੱਕ ਮੁਕਾਬਲੇਬਾਜ਼ੀ ਦਾ ਫਾਇਦਾ ਹੈ, ਤਾਂ FlashList ਵਾਧੂ ਡਿਪੈਂਡੈਂਸੀ (dependency)

ਛੋਟੀਆਂ ਰਣਨੀਤਕਮਾਨ ਆਦਤਾਂ ਇੱਕ ਅਜਿਹੀ ਲਿਸਟ ਨੂੰ ਜੋ ਸਿਰਫ਼ ਕੰਮ ਕਰਦੀ ਹੈ, ਉਸ ਤੋਂ ਵੱਖ ਕਰਦੀਆਂ ਹਨ ਜੋ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲਦੀ ਹੈ।

ਸਟੇਬਲ (stable) keys ਦੀ ਵਰਤੋਂ ਕਰੋ। ਹਮੇਸ਼ਾ ਆਪਣੇ ਡੇਟਾ ਸੈੱਟ ਤੋਂ ਇੱਕ ਅਸਲੀ ਆਈਡੈਂਟੀਫਾਇਰ (identifier) ਨੂੰ key prop ਵਿੱਚ ਪਾਸ ਕਰੋ। ਕਦੇ ਵੀ ਐਰੇ (array) ਇੰਡੈਕਸ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਡੀ ਲਿਸਟ ਰੀਆਰਡਰ (reorder) ਹੁੰਦੀ ਹੈ, ਫਿਲਟਰ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਆਈਟਮਾਂ ਜੋੜਦੀ ਹੈ, ਤਾਂ ਇੰਡੈਕਸ-ਅਧਾਰਤ key React ਨੂੰ ਗਲਤ ਡੇਟਾ ਨੂੰ ਗਲਤ ਰੀਸਾਈਕਲ ਕੀਤੇ ਕੰਪੋਨੈਂਟ ਨਾਲ ਜੋੜਨ ਲਈ ਭਰਮਾਉਂਦੀ ਹੈ। ਉਹ ਗਲਤੀ ਬੇਲੋੜੇ unmounts, state mismatches, ਅਤੇ ਕੈਸਕੇਡਿੰਗ re-renders ਦਾ ਕਾਰਨ ਬਣਦੀ ਹੈ। ਇੱਕ ਸਹੀ ID React ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਦੱਸਦੀ ਹੈ ਕਿ ਕਿਹੜੀ ਰੋਅ (row) ਕਿੱਥੇ ਗਈ ਹੈ।

Rows ਨੂੰ memoize ਕਰੋ। ਆਪਣੇ row component ਨੂੰ React.memo ਵਿੱਚ ਲਪੇਟੋ (wrap) ਤਾਂ ਜੋ ਇਹ ਉਦੋਂ ਹੀ re-render ਹੋਵੇ ਜਦੋਂ ਇਸਦੇ props ਅਸਲ ਵਿੱਚ ਬਦਲਦੇ ਹਨ। ਇਸ ਸੁਰੱਖਿਆ ਦੇ ਬਿਨਾਂ, ਕੋਈ ਵੀ parent state update ਹਰ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ row ਵਿੱਚ render pass ਨੂੰ ਟ੍ਰਿਗਰ ਕਰ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਉਹਨਾਂ ਦਾ ਡੇਟਾ ਇੱਕੋ ਜਿਹਾ ਹੀ ਕਿਉਂ ਨਾ ਹੋਵੇ। ਇੱਕ ਲੰਬੀ ਲਿਸਟ ਵਿੱਚ, ਉਹ ਬਰਬਾਦ ਹੋਏ ਸਾਈਕਲ (cycles) ਤੇਜ਼ੀ ਨਾਲ ਵਧਦੇ ਜਾਂਦੇ ਹਨ।

renderItem ਨੂੰ ਸਟੇਬਲ ਰੱਖੋ। ਹਰ parent render 'ਤੇ renderItem prop ਦੇ ਅੰਦਰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਨਵਾਂ ਫੰਕਸ਼ਨ ਬਣਾਉਣ ਤੋਂ ਬਚੋ। renderItem={({ item }) => <Row data={item} />} ਵਰਗਾ ਇੱਕ inline arrow function ਹਰ ਵਾਰ parent ਅਪਡੇਟ ਹੋਣ 'ਤੇ ਇੱਕ ਨਵਾਂ reference ਬਣਾਉਂਦਾ ਹੈ। FlatList ਇੱਕ ਬਦਲਿਆ ਹੋਇਆ prop ਦੇਖਦਾ ਹੈ ਅਤੇ ਬੇਲੋੜੇ ਤੌਰ 'ਤੇ row ਨੂੰ ਰੀਸਾਈਕਲ ਕਰਦਾ ਹੈ। Render ਫੰਕਸ਼ਨ ਨੂੰ component ਦੇ ਬਾਹਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜਾਂ useCallback ਨਾਲ ਇਸਨੂੰ memoize ਕਰੋ ਤਾਂ ਜੋ reference ਸਟੇਬਲ ਰਹੇ।

ਜਦੋਂ ਵੀ ਸੰਭਵ ਹੋਵੇ getItemLayout ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਡੀਆਂ rows ਦੀ ਉਚਾਈ (height) ਨਿਸ਼ਚਿਤ ਜਾਂ ਅਨੁਮਾਨਿਤ ਹੈ, ਤਾਂ FlatList ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਦੱਸੋ। ਇਹ prop ਲਿਸਟ ਨੂੰ ਮਹਿੰਗੇ native measurement calls ਨੂੰ ਛੱਡਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। Mount ਹੋਣ ਤੋਂ ਬਾਅਦ ਹਰੇਕ cell ਨੂੰ ਮਾਪਣ ਦੀ ਬਜਾਏ, ਲਿਸਟ ਗਣਿਤਕ ਤੌਰ 'ਤੇ (mathematically) ਸਥਿਤੀ ਦੀ ਗਣਨਾ ਕਰਦੀ ਹੈ। ਇਹ ਫਰਕ ਖਾਸ ਕਰਕੇ ਸੈਂਕੜੇ ਜਾਂ ਹਜ਼ਾਰਾਂ ਆਈਟਮਾਂ ਵਾਲੀਆਂ ਲਿਸਟਾਂ 'ਤੇ ਸਾਫ਼ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਜਿੱਥੇ onLayout chatter JS thread ਨੂੰ ਬਹੁਤ ਹੌਲੀ ਕਰ ਸਕਦਾ ਹੈ।

Images ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ optimize ਕਰੋ। ਅਨਬਾਊਂਡਡ (Unbounded) images ਲਿਸਟ ਲਈ ਜ਼ਹਿਰ ਵਾਂਗ ਹਨ। ਹਮੇਸ਼ਾ ਸਪੱਸ਼ਟ width ਅਤੇ height ਸੈੱਟ ਕਰੋ ਤਾਂ ਜੋ image decode ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ native layer ਜਗ੍ਹਾ ਰਾਖਵੀਂ ਰੱਖ ਲਵੇ। ਰਿਮੋਟ images ਲਈ, Expo Image ਵਰਗੀ caching library ਜਾਂ ਇਸਦੇ equivalent ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੋ memory caching, disk persistence, ਅਤੇ format optimization ਨੂੰ ਸੰਭਾਲਦੀ ਹੈ। ਡਿਫੌਲਟ React Native Image component prototypes ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ production feeds ਲਈ memory ਅਤੇ loading states 'ਤੇ ਵਧੇਰੇ ਕੰਟਰੋਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

Scroll containers ਨੂੰ nesting ਕਰਨ ਤੋਂ ਬਚੋ। ਕਦੇ ਵੀ ਇੱਕ vertical FlatList ਨੂੰ vertical ScrollView ਦੇ ਅੰਦਰ ਨਾ ਰੱਖੋ। Parent ScrollView ਸਾਰੇ scroll events ਨੂੰ ਕੈਪਚਰ ਕਰ ਲੈਂਦਾ ਹੈ ਅਤੇ child FlatList ਦੀ ਆਪਣੇ viewport ਨੂੰ ਮਾਪਣ ਦੀ ਸਮਰੱਥਾ ਨੂੰ ਵਿਗਾੜ ਦਿੰਦਾ ਹੈ। Virtualization ਟੁੱਟ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ FlatList ਨੂੰ ਹੁਣ ਇਹ ਨਹੀਂ ਪਤਾ ਹੁੰਦਾ ਕਿ ਕਿਹੜੀਆਂ rows ਦਿਖਾਈ ਦੇਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਨਤੀਜਾ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਹਰ row ਫਿਰ ਵੀ mount ਹੋ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ virtualization ਦਾ ਪੂਰਾ ਮਕਸਦ ਹੀ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਲਿਸਟ ਦੇ ਉੱਪਰ header ਦੀ ਲੋੜ ਹੈ