30 ਦਸੰ 2025·8 ਮਿੰਟ
React ਵਿੱਚ ਅਨੁਮਾਨੀ UI ਅਪਡੇਟ: ਤੇਜ਼ ਅਨੁਭਵ, ਕੋਈ ਡੇਟਾ ਡ੍ਰਿਫਟ ਨਹੀਂ
React ਵਿੱਚ ਅਨੁਮਾਨੀ UI ਅਪਡੇਟਸ ਐਪ ਨੂੰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੀਆਂ ਹਨ। ਸਰਵਰ ਦੀ ਸੱਚਾਈ ਨਾਲ ਮਿਲਾਉਣ, ਨਾਕਾਮੀਆਂ ਨੂੰ ਸੰਭਾਲਣ ਅਤੇ ਡੇਟਾ ਡ੍ਰਿਫਟ ਰੋਕਣ ਲਈ ਸੁਰੱਖਿਅਤ ਪੈਟਰਨ ਸਿੱਖੋ।
React ਵਿੱਚ ਅਨੁਮਾਨੀ UI ਅਪਡੇਟਸ ਐਪ ਨੂੰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੀਆਂ ਹਨ। ਸਰਵਰ ਦੀ ਸੱਚਾਈ ਨਾਲ ਮਿਲਾਉਣ, ਨਾਕਾਮੀਆਂ ਨੂੰ ਸੰਭਾਲਣ ਅਤੇ ਡੇਟਾ ਡ੍ਰਿਫਟ ਰੋਕਣ ਲਈ ਸੁਰੱਖਿਅਤ ਪੈਟਰਨ ਸਿੱਖੋ।
React ਵਿੱਚ ਅਨੁਮਾਨੀ UI ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਸਕਰੀਨ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਅਪਡੇਟ ਕਰਦੇ ਹੋ ਜਿਵੇਂ ਕਿ ਬਦਲਾਅ ਪਹਿਲਾਂ ਹੀ ਸਫਲ ਹੋ ਚੁੱਕਾ ਹੈ, ਸਰਵਰ ਦੀ ਪੁਸ਼ਟੀ ਤੋਂ ਪਹਿਲਾਂ। ਕੋਈ ਬੰਦਾ Like 'ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ, ਗਿਣਤੀ ਤੁਰੰਤ ਵਧ ਜਾਦੀ ਹੈ, ਅਤੇ ਬੇਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਰਿਕਵੇਸਟ ਚੱਲਦੀ ਰਹਿੰਦੀ ਹੈ।
ਉਹ ਤੁਰੰਤ ਫੀਡਬੈਕ ਐਪ ਨੂੰ ਤੇਜ਼ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ। ਧੀਮੇ ਨੈੱਟਵਰਕ 'ਤੇ, ਇਹ ਆਮ ਤੌਰ 'ਤੇ "ਸਨੇਪੀ" ਅਤੇ "ਕੀ ਹੋਇਆ?" ਦੇ ਵਿਚਕਾਰ ਫ਼ਰਕ ਹੁੰਦਾ ਹੈ।
ਟਰੇਡ-ਆਫ ਡੇਟਾ ਡ੍ਰਿਫਟ ਹੈ: ਯੂਜ਼ਰ ਜੋ ਵੇਖ ਰਹੇ ਹਨ ਉਹ ਧੀਰੇ-ਧੀਰੇ ਸਰਵਰ ਦੀ ਸੱਚਾਈ ਨਾਲ ਮੇਲ ਖਾਣਾ ਛੱਡ ਸਕਦੇ ਹਨ। ਡ੍ਰਿਫਟ ਆਮ ਤੌਰ 'ਤੇ ਛੋਟੀਆਂ, ਨਿਰਾਸ਼ਜਨਕ ਅਸੰਗਤਿਆਵਾਂ ਵੱਜੋਂ ਆਉਂਦੀ ਹੈ ਜੋ ਟਾਈਮਿੰਗ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਦੁਹਰਾਉਣਾ ਔਖਾ ਹੁੰਦਾ ਹੈ।
ਯੂਜ਼ਰਾਂ ਨੂੰ ਅਕਸਰ ਡ੍ਰਿਫਟ ਉਹ ਸਮੇਂ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ ਜਦੋਂ ਬਾਅਦ ਵਿੱਚ "ਮਨ ਬਦਲ ਜਾਣਾ" ਵਰਗਾ ਕੁਝ ਹੁੰਦਾ ਹੈ: ਕਾਊਂਟਰ ਛੱਲਦਾ ਹੈ ਤੇ ਫਿਰ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ, ਆਈਟਮ ਪ੍ਰਗਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਰੀਫ੍ਰੈਸ਼ ਤੋਂ ਬਾਅਦ ਦੂਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਇੱਕ ਤਬਦੀਲੀ ਲੱਗਦੀ ਹੈ ਕਿ ਟਿਕ ਗਈ ਪਰ ਪੇਜ ਦੀ ਦੁਬਾਰੀ ਖੋਲ੍ਹਣ 'ਤੇ ਹੋਰ ਹੋ ਜਾਂਦੀ ਹੈ, ਜਾਂ ਦੋ ਟੈਬਾਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਕੀਮਤਾਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ।
ਇਹ ਇਸ ਕਰਕੇ ਹੁੰਦਾ ਹੈ ਕਿ UI ਇਕ ਅਨੁਮਾਨ ਲਾ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਅਖੀਰ 'ਚ ਵੱਖਰਾ ਨਤੀਜਾ ਦੇ ਸਕਦਾ ਹੈ। ਵੈਧਤਾ ਨਿਯਮ, ਡੈਡੀਪਿੰਗ, ਪਰਮਿਸ਼ਨ ਚੈੱਕ, ਰੇਟ-limits, ਜਾਂ ਹੋਰ ਡਿਵਾਈਸ ਉੱਤੇ ਹੋ ਰਹੀ ਸੰਸ਼ੋਧਨ ਇੱਕੋ ਰਿਕਾਰਡ ਨੂੰ ਵੀ ਫੈਨਲ ਨਤੀਜਾ ਬਦਲ ਸਕਦੇ ਹਨ। ਇੱਕ ਹੋਰ ਆਮ ਕਾਰਨ ਇੱਕੋ ਸਮੇਂ ਚੱਲ ਰਹੀਆਂ ਰਿਕਵੇਸਟਾਂ ਹਨ: ਇੱਕ ਪੁਰਾਣਾ ਰਿਸਪਾਂਸ ਆਖ਼ਿਰ 'ਚ ਆ ਕੇ ਨਵੇਂ ਯੂਜ਼ਰ ਐਕਸ਼ਨ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਦਿੰਦਾ ਹੈ।
ਉਦਾਹਰਣ: ਤੁਸੀਂ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਨੂੰ "Q1 Plan" ਦੇ ਨਾਂ ਨਾਲ ਰੀਨੇਮ ਕਰਦੇ ਹੋ ਅਤੇ ਹੈਡਰ ਵਿੱਚ ਤੁਰੰਤ ਦਿਖਾ ਦਿੰਦੇ ਹੋ। ਸਰਵਰ ਵ੍ਹਾਈਟਸਪੇਸ ਟ੍ਰਿਮ ਕਰ ਸਕਦਾ ਹੈ, ਕੈਰੈਕਟਰ ਰੀਜੈਕਟ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਇੱਕ slug ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਅਨੁਮਾਨੀ ਕੀਮਤ ਨੂੰ ਸਰਵਰ ਦੇ ਅੰਤਿਮ ਮੁੱਲ ਨਾਲ ਕਬਜ਼ਾ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ UI ਠੀਕ ਦਿਸਦੀ ਰਹੇਗੀ ਜਦ ਤੱਕ ਅਗਲਾ ਰੀਫ੍ਰੈਸ਼ ਨਾ ਹੋਵੇ, ਜਦੋਂ ਇਹ "ਰਹੱਸਮਈ ਤੌਰ 'ਤੇ" ਬਦਲ ਜਾਵੇਗਾ।
ਅਨੁਮਾਨੀ UI ਹਰ ਵਾਰੀ ਸਹੀ ਚੋਣ ਨਹੀਂ ਹੁੰਦੀ। ਪੈਸਾ ਅਤੇ ਬਿਲਿੰਗ, ਅਪਰੈਟਿਵ ਕਾਰਵਾਈਆਂ, ਰੋਲ ਅਤੇ ਪਰਮਿਸ਼ਨ ਤਬਦੀਲੀਆਂ, ਜਟਿਲ ਸਰਵਰ ਨਿਯਮਾਂ ਵਾਲੇ ਵਰਕਫਲੋਜ਼, ਜਾਂ ਕੋਈ ਵੀ ਗੱਲ ਜਿਸਦਾ ਸਾਈਡ-ਇਫੈਕਟ ਯੂਜ਼ਰ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਪੁਸ਼ਟੀ ਕਰਨੀ ਲੋੜੀਂਦੀ ਹੋਵੇ, ਇਨ੍ਹਾਂ ਲਈ ਸਾਵਧਾਨ ਰਹੋ (ਜਾਂ ਇਸ ਤੋਂ ਬਚੋ)।
ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਵਰਤਿਆ ਜਾਵੇ ਤਾਂ ਅਨੁਮਾਨੀ ਅਪਡੇਟਸ ਐਪ ਨੂੰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹਨ, ਪਰ ਇਸ ਲਈ ਤੁਸੀਂ reconciliation, ordering ਅਤੇ failure handling ਦੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਪੈਂਦੀ ਹੈ।
ਅਨੁਮਾਨੀ UI ਉਹਨਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਦੋ ਤਰ੍ਹਾਂ ਦੀ ਸਟੇਟ ਨੂੰ ਵੱਖਰੇ ਰੱਖਦੇ ਹੋ:
ਜਿਆਦਾਤਰ ਡ੍ਰਿਫਟ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਲੋਕਲ ਅਨੁਮਾਨ ਨੂੰ ਪੁਸ਼ਟੀ ਹੋਈ ਸਚਾਈ ਵਰਗਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਨ ਨਿਯਮ: ਜੇ ਕਿਸੇ ਵੈਲਯੂ ਦਾ ਬਿਜ਼ਨਸ ਮਤਲਬ ਮੌਜੂਦਾ ਸਕਰੀਨ ਤੋਂ ਬਾਹਰ ਹੈ, ਤਾਂ ਸਰਵਰ ਨੂੰ ਸਰੋਤ-ਸੱਚ ਮੰਨੋ। ਜੇ ਇਹ ਸਿਰਫ਼ ਸਕਰੀਨ ਦੇ ਵਿਹਰਣ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ (ਖੁੱਲ੍ਹ/ਬੰਦ, ਫੋਕਸ, ਡਰਾਫਟ ਟੈਕਸਟ), ਤਾਂ ਇਸਨੂੰ ਲੋਕਲ ਰੱਖੋ।
ਅਮਲ ਵਿੱਚ, ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਸਰਵਰ ਸੱਚ ਰੱਖੋ: ਪਰਮਿਸ਼ਨ, ਕੀਮਤਾਂ, ਬੈਲੈਂਸ, ਇਨਵੈਂਟਰੀ, ਕੰਪਿਊਟ ਕੀਤੀਆਂ ਜਾਂ ਵੈਲਿਡੇਟ ਕੀਤੀਆਂ ਫੀਲਡਾਂ, ਅਤੇ ਕੋਈ ਵੀ ਚੀਜ਼ ਜੋ ਹੋਰ ਥਾਂ ਤੇ ਬਦਲ ਸਕਦੀ ਹੈ (ਹੋਰ ਟੈਬ, ਹੋਰ ਯੂਜ਼ਰ)। ਲੋਕਲ UI ਸਟੇਟ ਲਈ ਰੱਖੋ: ਡਰਾਫਟ, "is editing" ਫਲੈਗ, ਅਸਥਾਈ ਫਿਲਟਰ, ਐਕਸਪੈਂਡ ਕੀਤੇ ਰੋਜ਼, ਅਤੇ ਐਨੀਮੇਸ਼ਨ ਟੋਗਲ।
ਕੁਝ ਕਾਰਵਾਈਆਂ "ਅਨੁਮਾਨ ਲਾਉਣ ਲਈ ਸੁਰੱਖਿਅਤ" ਹੁੰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਸਰਵਰ ਆਮ ਤੌਰ 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਲੈਂਦਾ ਹੈ ਅਤੇ ਇਹ ਵਾਪਸ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿਸੇ ਆਈਟਮ ਨੂੰ ਸਟਾਰ ਕਰਨਾ ਜਾਂ ਇੱਕ ਸਧਾਰਣ ਪਸੰਦ ਬਦਲਣਾ।
ਜਦੋਂ ਕੋਈ ਫੀਲਡ ਅਨੁਮਾਨ ਲਾਉਣ ਲਈ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੁੰਦੀ, ਤੁਸੀਂ ਫਿਰ ਵੀ ਐਪ ਨੂੰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦੇ ਹੋ ਬਗੈਰ ਇਹ ਦਿਖਾਉਣ ਦੇ ਕਿ ਤਬਦੀਲੀ ਅੰਤਿਮ ਹੈ। ਆਖ਼ਰੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਕੀਮਤ ਰੱਖੋ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ pending ਸੰਕੇਤ ਜੋੜੋ।
ਉਦਾਹਰਣ ਲਈ, CRM ਸਕਰੀਨ 'ਤੇ ਜਿੱਥੇ ਤੁਸੀਂ "Mark as paid" 'ਤੇ ਕਲਿੱਕ ਕਰਦੇ ਹੋ, ਸਰਵਰ ਇਸਨੂੰ ਰੀਜੈਕਟ ਕਰ ਸਕਦਾ ਹੈ (ਪਰਮਿਸ਼ਨ, ਵੈਲਿਡੇਸ਼ਨ, ਪਹਿਲਾਂ ਹੀ ਰੀਫੰਡ ਹੋ ਚੁੱਕਾ)। ਹਰ ਨੰਬਰ ਨੂੰ ਤੁਰੰਤ ਬਦਲਣ ਦੀ ਥਾਂ, ਸਟੇਟਸ ਨਾਲ ਇੱਕ ਹੌਲਕਾ "Saving..." ਲੇਬਲ ਦਿਖਾਓ, ਟੋਟਲਾਂ ਨੂੰ ਬਦਲਣ ਤੋਂ ਰੋਕੋ, ਅਤੇ ਸਿਰਫ ਪੁਸ਼ਟੀ ਤੋਂ ਬਾਅਦ ਟੋਟਲ ਅਪਡੇਟ ਕਰੋ।
ਵਧੀਆ ਪੈਟਰਨ ਸਧਾਰਨ ਅਤੇ ਲਗਾਤਾਰ ਹੁੰਦੇ ਹਨ: ਬਦਲੇ ਆਈਟਮ ਦੇ ਨੇੜੇ ਇੱਕ ਛੋਟਾ "Saving..." ਬੈਜ, ਕਾਰਵਾਈ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਅਪੰਗ ਕਰਨਾ (ਜਾਂ ਇਸਨੂੰ Undo ਬਣਾਉਣਾ) ਜਦ ਤੱਕ ਰਿਕਵੇਸਟ settle ਨਾ ਹੋ ਜਾਵੇ, ਜਾਂ ਅਨੁਮਾਨੀ ਮੂਲ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਵਿਜ਼ੁਅਲ ਰੂਪ ਵਿੱਚ ਦਰਸਾਉਣਾ (ਹਲਕੀ ਟੈਕਸਟ ਜਾਂ ਛੋਟਾ ਸਪੀਨਰ)।
ਜੇ ਸਰਵਰ ਜਵਾਬ ਕਈ ਥਾਵਾਂ 'ਤੇ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ (ਟੋਟਲ, ਸੌਰਟਿੰਗ, ਕੰਪਿਊਟ ਕੀਤੀਆਂ ਫੀਲਡਾਂ, ਪਰਮਿਸ਼ਨ), ਤਾਂ ਸਾਰਥਕ ਤੌਰ 'ਤੇ refetch ਕਰਨਾ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ ਬਜਾਏ ਹਰ ਚੌਕਸ ਚੀਜ਼ ਨੂੰ ਪੈਚ ਕਰਨ ਦੇ। ਜੇ ਇਹ ਇੱਕ ਛੋਟੀ, ਆਇਸੋਲੇਟਡ ਤਬਦੀਲੀ ਹੈ (ਨੋਟ ਦਾ ਨਾਮ ਬਦਲਨਾ, ਇੱਕ ਫਲੈਗ ਟੌਗਲ ਕਰਨਾ), ਤਾਂ ਲੋਕਲ ਪੈਚ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਬਹੂਤ ਉਪਯੋਗੀ ਨਿਯਮ: ਜਿਸ ਚੀਜ਼ ਨੂੰ ਯੂਜ਼ਰ ਨੇ ਬਦਲਿਆ ਉਸਨੂੰ ਪੈਚ ਕਰੋ, ਫਿਰ ਕਿਸੇ ਵੀ ਡੇਰਾਈਵਡ, ਏਗਰੀਗੇਟਡ ਜਾਂ ਸਾਂਝੇ ਡਾਟਾ ਨੂੰ ਰੀਫੈਚ ਕਰੋ।
ਜਦੋਂ ਤੁਹਾਡਾ ਡੇਟਾ ਮਾਡਲ ਪੁਸ਼ਟੀਤ ਅਤੇ ਅਨੁਮਾਨੀ ਹਿੱਸਿਆਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਦਾ ਹੈ ਤਾਂ ਅਨੁਮਾਨੀ UI ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਸ ਖਾਮੀ ਨੂੰ ਖੁੱਲ੍ਹ ਕੇ ਮਾਡਲ ਕਰਦੇ ਹੋ ਤਾਂ "ਕਿਉਂ ਇਹ ਵਾਪਸ ਹੋ ਗਿਆ?" ਵਾਲੇ ਮੋਮੈਂਟ ਘੱਟ ਹੋ ਜਾਂਦੇ ਹਨ।
ਨਵੀਨ ਬਣਾਈਆਂ ਆਈਟਮਾਂ ਲਈ, ਇੱਕ ਅਸਥਾਈ ਕਲਾਇਂਟ ID ਦੇ ਦਿਓ (ਜਿਵੇਂ temp_12345 ਜਾਂ UUID), ਫਿਰ ਜਦੋਂ ਸਰਵਰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਤਾਂ ਇਸ ਨੂੰ ਅਸਲੀ ਸਰਵਰ ID ਨਾਲ ਬਦਲੋ। ਇਸ ਨਾਲ ਲਿਸਟਾਂ, ਚੋਣ ਅਤੇ ਐਡੀਟ ਸਟੇਟ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ reconcile ਹੋ ਜਾਂਦੇ ਹਨ।
ਉਦਾਹਰਣ: ਯੂਜ਼ਰ ਇੱਕ ਟਾਸਕ ਜੋੜਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਤੁਰੰਤ render ਕਰਦੇ ਹੋ id: "temp_a1" ਨਾਲ। ਜਦੋਂ ਸਰਵਰ id: 981 ਰਿਟਰਨ ਕਰਦਾ ਹੈ, ਤੁਸੀਂ ਇੱਕ ਹੀ ਥਾਂ ID ਬਦਲਦੇ ਹੋ, ਅਤੇ ਜੋ ਕੁਝ ਵੀ ID ਨਾਲ ਕੀ ਕੀਤਾ ਗਿਆ, ਉਹ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ।
ਇੱਕ ਸਕਰੀਨ-ਸਤਰੀ loading ਫਲੈਗ ਬਹੁਤ ਮੁਟਿਆਲਾ ਹੈ। status ਨੂੰ ਉਸ ਆਈਟਮ (ਜਾਂ ਫੀਲਡ) 'ਤੇ ਟਰੇਕ ਕਰੋ ਜੋ ਬਦਲ ਰਿਹਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਸੁਖੜ pending UI ਦਿਖਾ ਸਕਦੇ ਹੋ, ਸਿਰਫ਼ ਨਾਕਾਮ ਹੋਏ ਹਿੱਸਿਆਂ ਨੂੰ retry ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਅਣਸੰਬੰਧਿਤ ਕਾਰਵਾਈਆਂ ਨੂੰ ਰੋਕ ਸਕਦੇ ਹੋ।
ਇੱਕ ਪ੍ਰਾਇਕਟਿਕ ਆਈਟਮ ਆਕਾਰ:
id: ਅਸਲੀ ਜਾਂ ਅਸਥਾਈstatus: pending | confirmed | failedoptimisticPatch: ਜੋ ਤੁਸੀਂ ਲੋਕਲ ਤੌਰ 'ਤੇ ਬਦਲਿਆ (ਛੋਟਾ ਤੇ ਵਿਸ਼ੇਸ਼)serverValue: ਆਖ਼ਰੀ ਪੁਸ਼ਟੀਤ ਡੇਟਾ (ਜਾਂ confirmedAt ਟਾਈਮਸਟੈਂਪ)rollbackSnapshot: ਪਹਿਲਾ ਪੁਸ਼ਟੀਤ ਮੁੱਲ ਜੋ ਤੁਸੀਂ ਰੀਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋਅਨੁਮਾਨੀ ਅਪਡੇਟ ਤਦੋਂ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਸਿਰਫ ਉਹੀ ਚੀਜ਼ ਛੂਹਦੇ ਹੋ ਜੋ ਯੂਜ਼ਰ ਨੇ ਵਾਸਤਵ ਵਿੱਚ ਬਦਲੀ ਹੈ (ਉਦਾਹਰਣ ਲਈ completed ਟੌਗਲ), ਨਾ ਕਿ ਪੂਰੇ ਆਬਜੈਕਟ ਨੂੰ ਇੱਕ ਅਨੁਮਾਨੀ "ਨਵੀਂ ਵਰਜ਼ਨ" ਨਾਲ ਬਦਲੋ। ਪੂਰੇ-ਆਬਜੈਕਟ ਰੀਪਲੇਸਮੈਂਟ ਨਾਲ ਨਵੀਆਂ ਸੋਧਾਂ, ਸਰਵਰ-ਜੋੜੀਆਂ ਫੀਲਡਾਂ ਜਾਂ ਸਮਕਾਲੀ ਬਦਲਾਵ ਸੌਖੇ ਨਾਲ ਖਤਮ ਹੋ ਸਕਦੇ ਹਨ।
ਚੰਗੀ ਅਨੁਮਾਨੀ ਅਪਡੇਟ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਦੀ ਹੈ, ਪਰ ਫਿਰ ਵੀ ਸਰਵਰ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ। ਅਨੁਮਾਨੀ ਤਬਦੀਲੀ ਨੂੰ ਅਸਥਾਈ ਮੰਨੋ, ਅਤੇ ਪਸ਼ਟੀ ਜਾਂ ਰੱਦ ਕਰਨ ਲਈ ਕਾਫੀ ਬੁੱਕਕੀਪਿੰਗ ਰੱਖੋ।
ਉਦਾਹਰਣ: ਯੂਜ਼ਰ ਇੱਕ ਲਿਸਟ ਵਿੱਚ ਟਾਸਕ ਦਾ ਟਾਈਟਲ ਸੋਧਦਾ ਹੈ। ਤੁਸੀਂ ਟਾਈਟਲ ਨੂੰ ਤੁਰੰਤ ਅਪਡੇਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਪਰ ਤੁਹਾਨੂੰ ਵੈਲਿਡੇਸ਼ਨ ਅਰਰਰਾਂ ਅਤੇ ਸਰਵਰ-ਸਾਈਡ ਫਾਰਮੈਟਿੰਗ ਦਾ ਵੀ ਧਿਆਨ ਰੱਖਣਾ ਪੈਦਾ ਹੈ।
ਲੋਕਲ ਸਟੇਟ ਵਿੱਚ ਤੁਰੰਤ ਅਨੁਮਾਨੀ ਬਦਲਾਅ ਲਾਗੂ ਕਰੋ। ਹਟਾਉਣ ਲਈ ਇੱਕ ਛੋਟਾ ਪੈਚ ਜਾਂ ਸਨੈਪਸ਼ਾਟ ਸਟੋਰ ਕਰੋ।
ਇੱਕ request ID ਨਾਲ ਰਿਕਵੇਸਟ ਭੇਜੋ (ਇੱਕ ਵੱਧਦਾ ਨੰਬਰ ਜਾਂ ਰੈਂਡਮ ID). ਇਹ ਤੁਹਾਨੂੰ ਜਵਾਬਾਂ ਨੂੰ ਉਸ ਐਕਸ਼ਨ ਨਾਲ ਮਿਲਾਉਣ ਦਿੰਦਾ ਹੈ।
ਆਈਟਮ ਨੂੰ pending ਮਾਰਕ ਕਰੋ। Pending UI ਨੂੰ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ UI ਬਲੌਕ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਇਹ ਇੱਕ ਛੋਟਾ ਸਪੀਨਰ, ਫੇਡ ਟੈਕਸਟ ਜਾਂ "Saving..." ਹੋ ਸਕਦਾ ਹੈ। ਕੀਮਤ ਅਜੇ ਪੁਸ਼ਟੀਤ ਨਹੀਂ ਹੈ ਇਹ ਯੂਜ਼ਰ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਸਫਲਤਾ 'ਤੇ, ਅਸਥਾਈ ਕਲਾਇਂਟ ਡੇਟਾ ਨੂੰ ਸਰਵਰ ਵਰਜ਼ਨ ਨਾਲ ਬਦਲੋ। ਜੇ ਸਰਵਰ ਨੇ ਕੁਝ ਐਡਜਸਟ ਕੀਤਾ (ਵ੍ਹਾਈਟਸਪੇਸ ਟ੍ਰਿਮ, ਕੇਸ ਬਦਲਿਆ, ਟਾਈਮਸਟੈਂਪ ਐਡ ਕੀਤਾ), ਤਾਂ ਲੋਕਲ ਸਟੇਟ ਨੂੰ ਮਿਲਾਓ।
ਨਾਕਾਮੀ 'ਤੇ, ਸਿਰਫ ਉਸੀ ਚੀਜ਼ ਨੂੰ ਵਾਪਸ ਲਿਆਓ ਜੋ ਇਸ ਰਿਕਵੇਸਟ ਨੇ ਬਦਲੀ ਸੀ ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ, ਲੋਕਲ error ਦਿਖਾਓ। ਅਣਸੰਬੰਧਿਤ ਸਕਰੀਨ ਹਿੱਸਿਆਂ ਨੂੰ ਰੋਲਬੈਕ ਕਰਨ ਤੋਂ ਬਚੋ।
ਇੱਥੇ ਇਕ ਛੋਟੀ ਸਰਗਠਨ ਜੋ ਤੁਸੀਂ ਫਾਲੋ ਕਰ ਸਕਦੇ ਹੋ (ਲਾਇਬ੍ਰੇਰੀ-ਨਿਰਪੇਕ):
const requestId = crypto.randomUUID();
applyOptimistic({ id, title: nextTitle, pending: requestId });
try {
const serverItem = await api.updateTask({ id, title: nextTitle, requestId });
confirmSuccess({ id, requestId, serverItem });
} catch (err) {
rollback({ id, requestId });
showError("Could not save. Your change was undone.");
}
ਦੋ ਵੇਰਵਿਆਂ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਬੱਗ ਰੋਕੇ ਜਾ ਸਕਦੇ ਹਨ: ਆਈਟਮ ਤੇ request ID ਸਟੋਰ ਕਰੋ ਜਦੋਂ ਇਹ pending ਹੋਵੇ, ਅਤੇ ਸਿਰਫ਼ ਉਹੇਸੇ ID ਮੈਚ ਹੋਣ 'ਤੇ ਪੁਸ਼ਟੀ ਜਾਂ ਰੋਲਬੈਕ ਕਰੋ। ਇਸ ਨਾਲ ਪੁਰਾਣੇ ਜਵਾਬ ਨਵੇਂ ਸੋਧਾਂ ਨੂੰ ਓਵਰਰਾਈਟ ਨਹੀਂ ਕਰਾਂਗੇ।
ਜਦੋਂ ਨੈੱਟਵਰਕ ਆਸਕਾਪ ਤੋਂ ਬਾਹਰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਤਾਂ ਅਨੁਮਾਨੀ UI ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ। ਇੱਕ ਆਮ ਗਲਤੀ: ਯੂਜ਼ਰ ਟਾਈਟਲ ਸੋਧਦਾ ਹੈ, ਫਿਰ ਤੂਅਰ ਤੇ ਫਿਰ ਸੋਧਦਾ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਰਿਕਵੇਸਟ ਆਖ਼ਰ ਵਿੱਚ ਆਉਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਉਸ ਦੇ ਆਧਾਰ 'ਤੇ UI ਅਪਡੇਟ ਕਰੋਗੇ ਤਾਂ UI ਪੁਰਾਣੀ ਕੀਮਤ 'ਤੇ ਜਾ ਸਕਦਾ ਹੈ।
ਇਸਦਾ ਫਿਕਸ ਇਹ ਹੈ ਕਿ ਹਰ ਰਿਸਪਾਂਸ ਨੂੰ "ਸ਼ਾਇਦ਼ ਲਾਗੂ ਹੋਵੇ" ਸਮਝੋ ਅਤੇ ਸਿਰਫ ਉਸ ਵੇਲੇ ਲਾਗੂ ਕਰੋ ਜਦੋਂ ਇਹ ਨਵੀ ਉਦੇਸ਼ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਵੇ।
ਇੱਕ ਪਰੈਥਿਕ ਪੈਟਰਨ ਹੈ ਕਿ ਹਰ ਅਨੁਮਾਨੀ ਬਦਲਾਅ ਨਾਲ ਇੱਕ ਕਲਾਇਟ ਰਿਕਵੇਸਟ ID (ਕਾਊਂਟਰ) ਜੁੜਿਆ ਹੋਵੇ। ਹਰ ਰਿਕਾਰਡ ਲਈ latest ID ਸਟੋਰ ਕਰੋ। ਜਦੋਂ ਜਵਾਬ ਆਵੇ, ID ਦੀ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਜਵਾਬ পুরਾਣਾ ਹੈ ਤਾਂ ਇਸਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ।
ਵਰਜ਼ਨ ਚੈੱਕ ਵੀ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੇ ਸਰਵਰ ਨੇ updatedAt, version, ਜਾਂ etag ਵਾਪਸ ਕੀਤਾ ਹੈ, ਤਾਂ ਸਿਰਫ ਉਹੀ ਰਿਸਪਾਂਸ ਮਨੋ ਜੋ UI ਵੱਲੋਂ ਦਰਸਾਏ ਹੋਏ ਤੋਂ ਨਵੇਂ ਹਨ।
ਤੁਸੀਂ ਇਹਨਾਂ ਨਾਲ ਕੁਝ ਹੋਰ ਵਿਕਲਪਾਂ ਜੋੜ ਸਕਦੇ ਹੋ:
ਉਦਾਹਰਣ (request ID guard):
let nextId = 1;
const latestByItem = new Map();
async function saveTitle(itemId, title) {
const requestId = nextId++;
latestByItem.set(itemId, requestId);
// optimistic update
setItems(prev => prev.map(i => i.id === itemId ? { ...i, title } : i));
const res = await api.updateItem(itemId, { title, requestId });
// ignore stale response
if (latestByItem.get(itemId) !== requestId) return;
// reconcile with server truth
setItems(prev => prev.map(i => i.id === itemId ? { ...i, ...res.item } : i));
}
ਜੇ ਯੂਜ਼ਰ ਤੇਜ਼ੀ ਨਾਲ ਟਾਈਪ ਕਰ ਸਕਦੇ ਹਨ (ਨੋਟ, ਟਾਈਟਲ, ਸਰਚ), ਤਾਂ ਸੋਚੋ ਕਿ saves ਨੂੰ ਰਦ ਜਾਂ ਡੀਲੇ ਕਰੋ ਜਦ ਤੱਕ ਉਹ ਰੁਕਣ ਨਾ — ਇਹ ਸਰਵਰ ਲੋਡ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਪੁਰਾਣੇ ਰਿਸਪਾਂਸਾਂ ਦੇ ਕਾਰਨ ਹੋਣ ਵਾਲੇ ਸਕ੍ਰੀਨ ਸਨੇਪਿੰਗ ਦੀ ਸੰਭਾਵਨਾ ਘਟਾਉਂਦਾ ਹੈ।
ਨਾਕਾਮੀਆਂ ਉਹ ਹਨ ਜਿੱਥੇ ਅਨੁਮਾਨੀ UI ਭਰੋਸਾ ਗਵਾ ਸਕਦੀ ਹੈ। ਸਭ ਤੋਂ ਵੱਡਾ ਅਨੁਭਵ ਉਹ ਹੈ ਜਦੋਂ ਇਕ ਅਚਾਨਕ ਰੋਲਬੈਕ ਹੋ ਜਾਵੇ ਬਿਨਾਂ ਸਮਝਾਏ।
ਸੋਧਾਂ ਲਈ ਚੰਗਾ ਡੀਫੌਲਟ ਇਹ ਹੈ: ਯੂਜ਼ਰ ਦੀ ਕੀਮਤ ਸਕਰੀਨ 'ਤੇ ਰੱਖੋ, ਇਸਨੂੰ "not saved" ਦੇ ਨਿਸ਼ਾਨ ਨਾਲ ਮਾਰਕ ਕਰੋ, ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਸੋਧ ਕੀਤੀ ਥਾਂ ਤੇ ਇੰਲਾਈਨ ਏਰਰ ਦਿਖਾਓ। ਜੇ ਕੋਈ ਪ੍ਰੋਜੈਕਟ "Alpha" ਤੋਂ "Q1 Launch" ਬਣਾਇਆ ਗਿਆ, ਤਾਂ ਇਸ ਨੂੰ "Alpha" 'ਤੇ ਵਾਪਸ ਨਾ ਖਿੱਚੋ ਬਲਕਿ "Q1 Launch — Not saved. Name already taken" ਜਿਹਾ ਸੁਨੇਹਾ ਦਿਖਾਓ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਦਿਓ।
ਇੰਲਾਈਨ ਫੀਡਬੈਕ ਉਸ ਖੇਤਰ ਜਾਂ ਪੰਗਤੀ ਨਾਲ ਜੁੜਿਆ ਰਹਿੰਦਾ ਹੈ ਜਿੱਥੇ ਨਾਕਾਮੀ ਹੋਈ। ਇਹ "ਕੀ ਹੋਇਆ?" ਵਾਲੇ ਪਲ ਨੂੰ ਘੱਟ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਇੱਕ ਟੋਸਟ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ ਪਰ UI ਚੁਪਚਾਪ ਵਾਪਸ ਬਦਲ ਜਾਂਦਾ ਹੈ।
ਭਰੋਸੇਯੋਗ ਸੂਕੇਤਾਂ ਵਿੱਚ "Saving..." ਦੌਰਾਨ, ਨਾਕਾਮੀ 'ਤੇ "Not saved", ਪ੍ਰਭਾਵਿਤ ਕਤਾਰ ਤੇ ਹੌਲਕਾ ਹਾਈਲਾਈਟ, ਅਤੇ ਇੱਕ ਛੋਟਾ ਸੁਨੇਹਾ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਅੱਗੇ ਕੀ ਕਰਨਾ ਹੈ, ਸ਼ਾਮਲ ਹਨ।
Retry ਆਮ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੈ। Undo ਉਨ੍ਹਾਂ ਤੇਜ਼ ਕਾਰਵਾਈਆਂ ਲਈ ਵਧੀਆ ਹੈ ਜੋ ਕਿਸੇ ਨੂੰ ਪਛਤਾਵੇ ਜੋਗ਼ ਹੋ ਸਕਦੀਆਂ ਹਨ (ਜਿਵੇਂ ਅਆਰਕਾਈਵ), ਪਰ ਸੋਧਾਂ ਲਈ ਜਿੱਥੇ ਯੂਜ਼ਰ ਸਾਫ਼ ਤੌਰ 'ਤੇ ਨਵੀਂ ਕੀਮਤ ਚਾਹੁੰਦਾ ਹੈ, ਇਹ ਗੁੰਝਲਦਾਰ ਹੋ ਸਕਦਾ ਹੈ।
ਜਦੋਂ ਮਿਊਟੇਸ਼ਨ ਫੇਲ ਹੁੰਦਾ ਹੈ:
ਜੇ ਤੁਹਾਨੂੰ ਰੋਲਬੈਕ ਕਰਨਾ ਹੀ ਪੈਂਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਪਰਮਿਸ਼ਨ ਨਾਲ ਸਬੰਧਤ), ਤਾਂ ਇਹ ਵਜਾਹ ਸਪਸ਼ਟ ਦੱਸੋ ਅਤੇ ਸਰਵਰ-ਸੱਚ ਨੂੰ ਰੀਸਟੋਰ ਕਰੋ: "Couldn’t save. You no longer have access to edit this." (ਇਸ ਤਰ੍ਹਾਂ ਨੀਤੀ ਨੂੰ ਸਮਝਣਾ ਆਸਾਨ ਰਹਿੰਦਾ ਹੈ)।
ਸਰਵਰ ਜਵਾਬ ਨੂੰ ਸਿਰਫ ਇੱਕ success flag ਨਾ ਮੰਨੋ — ਇਸਨੂੰ ਰਸੀਦ ਵਾਂਗ ਭਰੋਸੇਯੋਗ ਮੰਨੋ। ਰਿਕਵੇਸਟ ਮੁਕੰਮਲ ਹੋਣ 'ਤੇ reconcile ਕਰੋ: ਉਹ ਰੱਖੋ ਜੋ ਯੂਜ਼ਰ ਦੀ ਨੀਅਤ ਸੀ, ਅਤੇ ਉਹ ਸਵੀਕਾਰ ਕਰੋ ਜੋ ਸਰਵਰ ਬਿਹਤਰ ਜਾਣਦਾ ਹੈ।
ਜਦੋਂ ਸਰਵਰ ਤੁਹਾਡੇ ਲੋਕਲ ਅਨੁਮਾਨ ਤੋਂ ਵੱਧ ਬਦਲ ਸਕਦਾ ਹੈ, ਤਦ ਪੂਰਾ refetch ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੈ ਅਤੇ ਵਿਆਖਿਆ ਕਰਨ ਵਿੱਚ ਆਸਾਨ।
ਜਦੋਂ ਮਿਊਟੇਸ਼ਨ ਕਈ ਰਿਕਾਰਡਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ (ਆਈਟਮਾਂ ਨੂੰ ਲਿਸਟਾਂ ਵਿੱਚ ਮਵ ਕਰਨ), ਜਦੋਂ ਪਰਮਿਸ਼ਨ ਜਾਂ ਵਰਕਫਲੋ ਨਿਯਮ ਨਤੀਜੇ ਬਦਲ ਸਕਦੇ ਹਨ, ਜਦੋਂ ਸਰਵਰ ਪਹਿਲੀ ਪਾਰਸ਼ਲ ਡੇਟਾ ਦੇਂਦਾ ਹੈ, ਜਾਂ ਜਦੋਂ ਹੋਰ ਕਲਾਇੰਟ ਵਿੱਊ ਨੂੰ ਅਕਸਰ ਅਪਡੇਟ ਕਰਦੇ ਹਨ, ਤਦ refetch ਬਿਹਤਰ ਵਿਕਲਪ ਹੁੰਦਾ ਹੈ।
ਜੇ ਸਰਵਰ ਅਪਡੇਟਡ ਐਨਟੀਟੀ (ਜਾਂ ਕਾਫ਼ੀ ਫੀਲਡ) ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ merging ਬਿਹਤਰ ਅਨੁਭਵ ਦੇ ਸਕਦਾ ਹੈ: UI ਸਥਿਰ ਰਹਿੰਦੀ ਹੈ ਪਰ ਸਰਵਰ-ਸੱਚ ਨੂੰ ਵੀ ਸਵੀਕਾਰ ਕਰ ਲਿਆ ਜਾਂਦਾ ਹੈ।
ਡ੍ਰਿਫਟ ਆਮ ਤੌਰ 'ਤੇ ਸਰਵਰ-ਮਲਕੀਅਤ ਵਾਲੀਆਂ ਫੀਲਡਾਂ ਨੂੰ ਅਣਦੇਖਾ ਕਰਨ ਕਾਰਨ ਹੁੰਦਾ ਹੈ। ਸੋਚੋ ਕਿ ਤੁਸੀਂ likedByMe=true ਅਤੇ likeCount ਨੂੰ ਅਨੁਮਾਨੀ ਤੌਰ 'ਤੇ ਵਧਾ ਦਿੱਤਾ। ਸਰਵਰ ਡਿਡੈਪ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਵੱਖਰਾ likeCount ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ।
ਸੰਪੂਰਨ ਮੇਰਜ ਪਹੁੰਚ:
ਜਦੋਂ ਟਕਰਾਅ ਹੋਵੇ, ਤਾਂ ਪਹਿਲਾਂ ਤੋਂ ਨਿਰਣਯ ਕਰੋ। "Last write wins" ਟੌਗਲਾਂ ਲਈ ਠੀਕ ਹੈ। ਫਾਰਮਾਂ ਲਈ ਫੀਲਡ-ਲੇਵਲ ਮੇਰਜ ਬਿਹਤਰ ਹੈ।
ਇੱਕ per-field "dirty since request" ਫਲੈਗ (ਜਾਂ ਲੋਕਲ ਵਰਜ਼ਨ ਨੰਬਰ) ਤੁਹਾਨੂੰ ਸਰਵਰ ਮੁੱਲ ਨੂੰ ਉਹਨਾਂ ਫੀਲਡਾਂ ਲਈ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਦਿੰਦਾ ਹੈ ਜੋ ਯੂਜ਼ਰ ਨੇ ਮਿਊਟੇਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸੋਧੇ ਹਨ, ਜਦਕਿ ਹੋਰ ਸਭ ਲਈ ਸਰਵਰ-ਸੱਚ ਨੂੰ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਜੇ ਸਰਵਰ ਮਿਊਟੇਸ਼ਨ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਹੈਲਪਫੁਲ, ਹਲਕੀ-ਫ਼ੈਸਲੇ ਵਾਲੀ ਏਰਰ ਦਿਓ ਸਪਸ਼ਟ ਰੋਲਬੈਕ ਦੀ ਥਾਂ। ਯੂਜ਼ਰ ਦੀ ਇਨਪੁਟ ਰੱਖੋ, ਫੀਲਡ ਨੂੰ ਉਜਾਗਰ ਕਰੋ, ਅਤੇ ਸੁਨੇਹਾ ਦਿਖਾਓ। ਰੋਲਬੈਕ ਉਹਨਾਂ ਕੇਸਾਂ ਲਈ ਰੱਖੋ ਜਿੱਥੇ ਕਾਰਵਾਈ ਸੱਚਮੁੱਚ ਰੁਕੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ ਸਰਵਰ ਨੇ ਆਈਟਮ ਨੂੰ ਮਿਟਾ ਦਿੱਤਾ ਪਰ ਡੀਲੀਟ ਕਰਨਾ ਨਾਕਾਮ ਰਿਹਾ)।
ਲਿਸਟਾਂ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਅਨੁਮਾਨੀ UI ਵਧੀਆ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ ਪਰ ਆਸਾਨੀ ਨਾਲ ਟੁੱਟ ਵੀ ਸਕਦੀ ਹੈ। ਇੱਕ ਆਈਟਮ ਦੀ ਇੱਕ ਤਬਦੀਲੀ ordering, totals, filters, ਅਤੇ ਕਈ ਪੇਜ਼ਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀ ਹੈ।
ਕ੍ਰੀਏਟ ਲਈ, ਨਵੀਂ ਆਈਟਮ ਨੂੰ ਤੁਰੰਤ ਦਿਖਾਓ ਪਰ ਇਸਨੂੰ pending ਨੇੜੇ ਇੱਕ ਅਸਥਾਈ ID ਨਾਲ ਮਾਰਕ ਕਰੋ। ਇਸਦੀ ਪੋਜ਼ੀਸ਼ਨ ਨੂੰ ਸਥਿਰ ਰੱਖੋ ਤਾਂ ਕਿ ਇਹ ਕੂਦੇ ਨਾ।
ਡਿਲੀਟ ਲਈ, ਇੱਕ ਸੁਰੱਖਿਅਤ ਪੈਟਰਨ ਹੈ ਕਿ ਆਈਟਮ ਨੂੰ ਤੁਰੰਤ ਲੁਕਾਓ ਪਰ ਇੱਕ ਛੋਟਾ-ਅਰਸੇ ਲਈ "ਘੋਸਟ" ਰਿਕਾਰਡ ਮੈਮੋਰੀ ਵਿੱਚ ਰੱਖੋ ਤਾਕਿ Undo ਦਾ ਸਮਰਥਨ ਹੋਵੇ ਅਤੇ ਨਾਕਾਮੀਆਂ ਨੂੰ ਸੰਭਾਲਣਾ ਆਸਾਨ ਹੋਵੇ।
ਰੀਆਰੇਂਜਿੰਗ ਜਟਿਲ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕਈ ਆਈਟਮਾਂ ਨੂੰ ਛੂਹਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਅਨੁਮਾਨੀ ਤੌਰ 'ਤੇ ਰੀਆਰੇਂਜ ਕਰੋ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲੀ ਆਰਡਰ ਨੂੰ ਸਟੋਰ ਕਰੋ ਤਾਂ ਜੋ ਲੋੜ ਪੈਣ 'ਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਰੀਸਟੋਰ ਕਰ ਸਕੋ।
Pagination ਜਾਂ infinite scroll ਨਾਲ, ਫੈਸਲਾ ਕਰੋ ਕਿ ਅਨੁਮਾਨੀ ਇਨਸਰਟ ਕਿੱਥੇ ਰੱਖੀਏ। ਫੀਡਜ਼ ਵਿੱਚ ਨਵੀਆਂ ਆਈਟਮ ਆਮ ਤੌਰ 'ਤੇ ਸਿਖਰ ਤੇ ਜਾਂਦੀਆਂ ਹਨ। ਸਰਵਰ-ਰੈਂਕਡ ਕੈਟਲੌਗਾਂ ਵਿੱਚ ਲੋਕਲ ਇਨਸਰਟ ਮੰਚੂ ਕਦੇ-ਕਦੇ ਗਲਤ ਨਤੀਜਾ ਦਿਖਾ ਸਕਦੀ ਹੈ। ਇੱਕ практикаਕ ਸਮਝੌਤਾ ਇਹ ਹੈ ਕਿ ਵਿਜ਼ੀਬਲ ਲਿਸਟ ਵਿੱਚ ਇਨਸਰਟ ਕਰੋ ਦ pending ਬੈਜ ਨਾਲ, ਅਤੇ ਸਰਵਰ ਜਵਾਬ ਤੋਂ ਬਾਅਦ ਆਖ਼ਰੀ sort key ਵੱਖਰਾ ਹੋਵੇ ਤਾਂ ਇਸਨੂੰ ਹਿਲਾਉਣ ਲਈ ਤਿਆਰ ਰਹੋ।
ਜਦੋਂ ਇੱਕ ਅਸਥਾਈ ID ਅਸਲੀ ID ਬਣਦੀ ਹੈ, ਤਾਂ stable key ਵੱਲੋਂ dedupe ਕਰੋ। ਜੇ ਤੁਸੀਂ ਸਿਰਫ ID ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇਕੋ ਆਈਟਮ ਨੂੰ ਦੋ ਵਾਰ (temp ਅਤੇ confirmed) ਦਿਖਾ ਸਕਦੇ ਹੋ। tempId-to-realId ਨਕਸ਼ਾ ਰੱਖੋ ਅਤੇ ਥਾਂ 'ਤੇ ਬਦਲੋ ਤਾਂ ਕਿ ਸਕ੍ਰੋਲ ਪੋਜ਼ੀਸ਼ਨ ਅਤੇ ਚੋਣ ਰੀਸੈਟ ਨਾ ਹੋਵੇ।
ਕਾਊਂਟਸ ਅਤੇ ਫਿਲਟਰ ਵੀ ਲਿਸਟ ਸਟੇਟ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਯਕੀਨ ਹੋ ਕਿ ਸਰਵਰ ਸਹਿਮਤ ਹੋਵੇਗਾ ਤਾਂ ਹੀ ਕਾਊਂਟਸ ਨੂੰ ਅਨੁਮਾਨੀ ਤੌਰ 'ਤੇ ਅਪਡੇਟ ਕਰੋ। ਨਹੀਂ ਤਾਂ, ਉਨ੍ਹਾਂ ਨੂੰ refreshing ਦਿਖਾ ਕੇ ਜਵਾਬ ਤੋਂ ਬਾਅਦ reconcile ਕਰੋ।
ਅਧਿਕਤਰ ਅਨੁਮਾਨੀ-ਅਪਡੇਟ ਬੱਗਾਂ ਅਸਲ ਵਿੱਚ React ਦੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹ ਇਸ ਕਰਕੇ ਹੁੰਦੀਆਂ ਹਨ ਕਿ ਅਨੁਮਾਨੀ ਤਬਦੀਲੀ ਨੂੰ "ਨਵੀਂ ਸਚਾਈ" ਮੰਨ ਲਿਆ ਜਾਂਦਾ ਹੈ ਨਾ ਕਿ ਇੱਕ ਅਸਥਾਈ ਅਨੁਮਾਨ।
ਜਦੋਂ ਤੁਸੀਂ ਪੂਰੇ ਆਬਜੈਕਟ ਜਾਂ ਸਕਰੀਨ ਨੂੰ ਅਨੁਮਾਨੀ ਤੌਰ 'ਤੇ ਅਪਡੇਟ ਕਰਦੇ ਹੋ ਜਦ ਕਿ ਸਿਰਫ ਇੱਕ ਫੀਲਡ ਬਦਲੀ ਹੈ, ਤਾਂ ਬਲਾਸਟ ਰੇਡੀਅਸ ਵਧ ਜਾਂਦਾ ਹੈ। ਬਾਅਦ ਵਿੱਚ ਸਰਵਰ ਸਹੀ ਕਰੇ ਤਾਂ ਪ੍ਰਸੰਗ ਬਾਹਰਲੇ ਸੋਧਾਂ ਨੂੰ ਵੀ ਓਵਰਰਾਈਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਉਦਾਹਰਣ: ਇੱਕ ਪ੍ਰੋਫਾਈਲ ਫਾਰਮ user ਆਬਜੈਕਟ ਨੂੰ ਬਦਲਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਇੱਕ ਸੈਟਿੰਗ ਟੌਗਲ ਕਰਦੇ ਹੋ। ਰਿਕਵੇਸਟ ਫਲਾਇੰਗ ਦੌਰਾਨ ਯੂਜ਼ਰ ਨਾਮ ਸੋਧਦਾ ਹੈ। ਜਦ ਜਵਾਬ ਆ ਜਾਂਦਾ ਹੈ, ਤੁਹਾਡੀ ਰੀਪਲੇਸਮੈਂਟ ਪੁਰਾਣਾ ਨਾਮ ਵਾਪਸ ਰੱਖ ਸਕਦੀ ਹੈ।
ਛੋਟੇ ਅਤੇ ਕੇਂਦ੍ਰਿਤ ਪੈਚ ਰੱਖੋ।
ਹੋਰ ਡ੍ਰਿਫਟ ਦਾ ਸਰੋਤ pending ਫਲੈਗ ਨੂੰ ਸਫਾਈ ਨਾਲ ਹਟਾਉਣਾ ਭੁੱਲ ਜਾਣਾ ਹੈ। UI ਅੱਧਾ-ਲੋਡ ਹੋਇਆ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਬਾਅਦ ਦੀ ਲਾਜਿਕ ਇਸਨੂੰ ਅਜੇ ਵੀ ਅਨੁਮਾਨੀ ਮੰਨ ਸਕਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ pending ਸਟੇਟ ਨੂੰ ਹਰ ਆਈਟਮ ਲਈ ਟਰੇਕ ਕਰਦੇ ਹੋ ਤਾਂ ਇਸਨੂੰ ਉਸੇ key ਨਾਲ ਸਾਫ਼ ਕਰੋ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਇਸਨੂੰ ਸੈੱਟ ਕੀਤਾ ਸੀ। ਅਸਥਾਈ IDs ਅਕਸਰ "ਘੋਸਟ pending" ਆਈਟਮ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜਦੋਂ ਅਸਲੀ ID ਹਰ ਥਾਂ ਮੈਪ ਨਹੀਂ ਹੁੰਦੀ।
Rollback ਬੱਗ ਉਸ ਵੇਲੇ ਹੁੰਦੀਆਂ ਹਨ ਜਦੋਂ snapshot ਬਹੁਤ ਦੇਰ ਨਾਲ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਾਂ ਬਹੁਤ ਵਿਆਪਕ ਸਕੋਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਜੇ ਯੂਜ਼ਰ ਦੋ ਤੇਜ਼ ਸੋਧਾਂ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸੋਧ #2 ਨੂੰ edit #1 ਤੋਂ ਪਹਿਲਾਂ ਦੇ snapshot ਨਾਲ ਰੋਲਬੈਕ ਕਰ ਸਕਦੇ ਹੋ। UI ਉਸ ਅਵਸਥਾ 'ਤੇ ਲੰਘ ਜਾਂਦਾ ਹੈ ਜੋ ਯੂਜ਼ਰ ਨੇ ਕਦੇ ਨਹੀਂ ਵੇਖੀ।
ਸਹੀ ਤਰੀਕਾ: ਜਿਸ ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਤੁਸੀਂ ਰੀਸਟੋਰ ਕਰਨ ਵਾਲੇ ਹੋ, ਉਸ ਦੇ ਐਕਜ਼ੈਕਟ ਸਲਾਈਸ ਨੂੰ ਲਵੋ, ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਖਾਸ ਮਿਊਟੇਸ਼ਨ ਕੋਸ਼ਿਸ਼ ਨਾਲ ਸਕੋਪ ਕਰੋ (ਅਕਸਰ request ID ਦੀ ਵਰਤੋਂ ਨਾਲ)।
ਅਸਲੀ ਸੇਵਾਂ ਅਕਸਰ ਕਈ-ਕਦਮ ਵਾਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਦੂਜੇ ਕਦਮ (ਉਦਾਹਰਨ ਲਈ, ਇਮੇਜ ਅਪਲੋਡ) ਨਾਕਾਮ ਹੋ ਜਾਵੇ, ਤਾਂ ਪਹਿਲੇ ਕਦਮ ਨੂੰ ਚੁੱਪਚਾਪ ਰੀਵਰਟ ਨਾ ਕਰੋ। ਦਿਖਾਓ ਕੀ ਸੇਵ ਹੋਇਆ, ਕੀ ਨਹੀਂ, ਅਤੇ ਅਗਲਿਆਂ ਲਈ ਯੂਜ਼ਰ ਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਇਸਦੇ ਨਾਲ ਨਾਲ, ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਸਰਵਰ ਵੀਚਾਰ ਤੇ ਵਾਪਸ ਠੀਕ ਉਹੀ ਰਿਟਰਨ ਕਰੇਗਾ ਜੋ ਤੁਸੀਂ ਭੇਜਿਆ — ਸਰਵਰ ਟੈਕਸਟ ਨਾਰਮਲਾਈਜ਼ ਕਰਦਾ ਹੈ, ਪਰਮਿਸ਼ਨ ਲਗਾਉਂਦਾ ਹੈ, ਟਾਈਮਸਟੈਂਪ ਜੋੜਦਾ ਹੈ, ID ਐਸਾਈਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਫੀਲਡ ਛੱਡ ਸਕਦਾ ਹੈ। ਸਦਾ ਰਿਸਪਾਂਸ (ਜਾਂ refetch) ਤੋਂ reconcile ਕਰੋ, ਨਾ ਕਿ ਅਨੁਮਾਨੀ ਪੈਚ ਤੇ ਸਦਾ ਭਰੋਸਾ ਰੱਖੋ।
ਅਨੁਮਾਨੀ UI ਤਦੋਂ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਇਹ ਭਵਿਖ-ਅਨੁਮਾਨਯੋਗ ਹੋਵੇ। ਹਰ ਅਨੁਮਾਨੀ ਬਦਲਾਅ ਨੂੰ ਇੱਕ ਛੋਟੀ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ ਵਾਂਗ ਸੋਚੋ: ਇਸਦਾ ਇੱਕ ID ਹੁੰਦਾ ਹੈ, ਇੱਕ ਵਿਜ਼ੀਬਲ pending ਸਟੇਟ, ਇੱਕ ਸਪਸ਼ਟ success swap, ਅਤੇ ਇੱਕ ਨਾਕਾਮੀ ਰਾਹ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਹੈਰਾਨ ਨਾ ਕਰੇ।
ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਮੀਖਿਆ ਲਈ ਚੈਕਲਿਸਟ:
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲੀ ਵਰਜ਼ਨ ਨੂੰ ਛੋਟਾ ਰੱਖੋ: ਇੱਕ ਸਕਰੀਨ, ਇੱਕ ਮਿਊਟੇਸ਼ਨ, ਇੱਕ ਲਿਸਟ ਅਪਡੇਟ। ਐਸੇ ਟੂਲ Koder.ai ਤੁਹਾਨੂੰ UI ਅਤੇ API ਤੇਜ਼ੀ ਨਾਲ ਖਾਕਾ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਉਹੀ ਨਿਯਮ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: pending vs confirmed ਸਟੇਟ ਮਾਡਲ ਕਰੋ ਤਾਂ ਕਿ ਕਲਾਇੰਟ ਕਦੇ ਵੀ ਇਹ ਨਾ ਭੁੱਲੇ ਕਿ ਸਰਵਰ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਸਵੀਕਾਰ ਕੀਤਾ।
Optimistic UI ਸਕਰੀਨ ਨੂੰ ਫੌਰاً ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਸਰਵਰ ਦੀ ਪੁਸ਼ਟੀ ਤੋਂ ਪਹਿਲਾਂ। ਇਹ ਐਪ ਨੂੰ ਤੁਰੰਤ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ, ਪਰ UI ਨੂੰ ਸਰਵਰ ਰਿਪਲਾਈ ਨਾਲ ਮਿਲਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ ਤਾਂ ਕਿ ਡੇਟਾ ਡ੍ਰਿਫਟ ਨਾ ਹੋਵੇ।
ਡੇਟਾ ਡ੍ਰਿਫਟ ਉਸ ਸਮੇਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ UI ਨੇ ਜੋ ਅਨੁਮਾਨ ਲਾਇਆ ਉਹ ਪੱਕਾ ਮੰਨ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਸਰਵਰ ਕੁਝ ਹੋਰ ਸੇਵ ਕਰਦਾ ਹੈ ਜਾਂ ਨਾਕਾਰਦਾਤਾ ਕਰਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਰੀਫ੍ਰੈਸ਼, ਹੋਰ ਟੈਬ, ਜਾਂ ਧੀਮੇ ਨੈੱਟਵਰਕ ਕਾਰਨ ਆਉਟ-ਆਫ-ਆਰਡਰ ਜਵਾਬਾਂ ਨਾਲ ਵੱਖਰਾ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ।
ਪੈਸੇ, ਬਿਲਿੰਗ, ਅਪਰੈਟਿਵ ਕਾਰਵਾਈਆਂ, ਪਰਮਿਸ਼ਨ-ਸੰਬੰਧੀ ਤਬਦੀਲੀਆਂ ਅਤੇ ਜਟਿਲ ਸਰਵਰ ਨਿਯਮਾਂ ਵਾਲੇ ਵਰਕਫਲੋਜ਼ ਲਈ ਅਨੁਮਾਨੀ UI ਤੋਂ ਬਚੋ ਜਾਂ ਬਹੁਤ ਸਾਵਧਾਨ ਰਵੱਈਆ ਰੱਖੋ। ਇਨ੍ਹਾਂ ਮਾਮਲਿਆਂ ਲਈ, ਇਕ ਸਪਸ਼ਟ pending ਸਟੇਟ ਦਿਖਾਉਣਾ ਅਤੇ ਪੁਸ਼ਟੀ ਦੀ ਉਡੀਕ ਕਰਨਾ ਵਧੀਆ ਹੈ।
ਜੇ ਕਿਸੇ ਵੈਲਯੂ ਦਾ ਵਪਾਰਕ ਪ੍ਰਸੰਗ ਸਕ੍ਰੀਨ ਤੋਂ ਬਾਹਰ ਹੈ (ਜਿਵੇਂ ਕੀਮਤ, ਪਰਮਿਸ਼ਨ, ਸਾਂਝੇ ਕਾਊਂਟਰ), ਤਾਂ ਸਰਵਰ ਨੂੰ ਸਰੋਤ-ਸੱਚ ਮੰਨੋ। ਡਰਾਫਟ, ਫੋਕਸ, 'is editing' ਫਲੈਗ ਅਤੇ ਅਸਥਾਈ ਫਿਲਟਰਾਂ ਲਈ ਲੋਕਲ UI ਸਟੇਟ ਰੱਖੋ।
ਬਦਲਾਅ ਸਿੱਧੇ ਉਸ ਥਾਂ ਤੇ ਦਿਖਾਓ ਜੇਥੇ ਉਹ ਹੋਇਆ: ਛੋਟਾ "Saving..." ਬੈਜ, ਫੀਲਡ ਨੂੰ ਹਲਕਾ ਫੇਡ ਕਰਨਾ ਜਾਂ ਇੱਕ ਸੁਘੜ ਸਪੀਨਰ। ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਯੂਜ਼ਰ ਨੂੰ ਪਤਾ ਲੱਗੇ ਕਿ ਇਹ ਅਸਤਾਈ ਹੈ ਬਿਨਾਂ ਪੂਰੀ ਸਕਰੀਨ ਨੂੰ ਬਲਾਕ ਕੀਤੇ।
ਜਦੋਂ ਸਰਵਰ ID ਦੇਂਦਾ ਨਹੀਂ, ਇੱਕ ਅਸਥਾਈ ਕਲਾਇਂਟ ID ਵਰਤੋ (ਜਿਵੇਂ temp_... ਜਾਂ UUID) ਅਤੇ ਸਰਵਰ ਜਵਾਬ ਤੇ ਇਸ ਨੂੰ ਅਸਲੀ ID ਨਾਲ ਬਦਲੋ। ਇਸ ਨਾਲ ਲਿਸਟ ਦੀ ਕੀ-ਅਧਾਰਿਤ ਸਥਿਤੀ, ਸਕ੍ਰੋਲ ਅਤੇ ਚੋਣ ਸਥਿਰ ਰਹਿੰਦੀਆਂ ਹਨ।
ਗਲੋਬਲ ਲੋਡਿੰਗ ਫਲੈਗ ਦੀ ਥਾਂ ਹਰ ਆਈਟਮ ਜਾਂ ਫੀਲਡ ਲਈ pending ਸਟੇਟ ਟਰੇਕ ਕਰੋ। ਇੱਕ ਛੋਟਾ optimisticPatch ਅਤੇ rollbackSnapshot ਸਟੋਰ ਕਰੋ ਤਾਂ ਕਿ ਸਿਰਫ਼ ਉਹੀ ਬਦਲਾਅ ਪੂਸ਼ਟੀ ਜਾਂ ਰੋਲਬੈਕ ਹੋਵੇ।
ਹਰ ਮਿਊਟੇਸ਼ਨ ਨੂੰ ਇੱਕ request ID (ਗਿਣਤੀ ਜਾਂ ਰੈਂਡਮ ID) ਦੇ ਕੇ ਅਟੈਚ ਕਰੋ ਅਤੇ ਪ੍ਰਤੀ ਰਿਕਾਰਡ ਸਭ ਤੋਂ ਨਵਾਂ ID ਰੱਖੋ। ਜਦੋਂ ਜਵਾਬ ਆਵੇ, ਤਾਂ ਸਿਰਫ ਉਹੀ ਲਾਗੂ ਕਰੋ ਜੇ 이것 ID ਮੈਚ ਕਰਦੀ ਹੋ, ਨਹੀਂ ਤਾਂ ਪੁਰਾਣਾ ਜਵਾਬ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ।
ਅਕਸਰ ਬਿਹਤਰ ਅਨੁਭਵ ਇਹ ਹੈ ਕਿ ਯੂਜ਼ਰ ਦੀ ਕੀਮਤ ਸਕਰੀਨ 'ਤੇ ਹੀ ਰਹੇ, ਪਰ ਇੱਕ ਇੰਲਾਈਨ ਏਰਰ ਦੇ ਕੇ ਦਿਖਾਇਆ ਜਾਵੇ ਕਿ ਇਹ ਸੇਵ ਨਹੀਂ ਹੋਈ। Retry ਦੇ ਵਿਕਲਪ ਨੂੰ ਇੰਲਾਈਨ ਰੱਖੋ। ਸਿਰਫ ਉਹੀ ਹਾਲਤ ਜਦੋਂ ਖੁੱਲ੍ਹ ਕੇ ਮੁੜ-ਸਥਾਪਨਾ ਹੀ ਸਹੀ ਹੋਵੇ, ਤਦ ਰੋਲਬੈਕ ਕਰੋ।
ਜਦੋਂ ਸਰਵਰ ਵੱਧ ਫੀਲਡ ਜਾਂ ਰਿਕਾਰਡਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਤਦ ਪੂਰਾ refetch ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ। ਜੇ ਸਰਵਰ ਅਪਡੇਟਡ ਐਨਟੀਟੀ ਵਾਪਸ ਦਿੰਦਾ ਹੈ ਤੇ ਉਹ ਕਾਫ਼ੀ ਹੈ, ਤਾਂ ਮੇਰਜ ਕਰਨਾ ਬਿਹਤਰ UX ਰੱਖ ਸਕਦਾ ਹੈ।
ਸਰਵਰ-ਮੈਨੇਜ ਕੀਤੇ ਫੀਲਡ (ਕਾਊਂਟਰ, computed ਮੁੱਲ, timestamps) ਨੂੰ ਸਰਵਰ ਜਵਾਬ ਤੋਂ ਪੈਚ ਕਰੋ ਅਤੇ ਉਹ ਫੀਲਡ ਰੱਖੋ ਜੋ ਯੂਜ਼ਰ ਨੇ ਮਿਊਟੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਬਦਲੇ ਨਹੀਂ। ਫ਼ੀਲਡ-ਲੇਵਲ dirty ਫਲੈਗ ਯੂਜ਼ਰ ਦੀਆਂ ਬਾਅਦੀ ਸੋਧਾਂ ਨੂੰ ਬਚਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਲਿਸਟਾਂ ਵਿੱਚ ਨਵੀਆਂ ਆਈਟਮਾਂ ਤੁਰੰਤ ਦਿਖਾਉਣਾ ਸੁਖਦਾਇਕ ਹੈ ਪਰ ਥੋਰੜੀ ਗਲਤ ਜਗ੍ਹਾ ਤੇ ਦਿਖਾ ਸਕਦਾ ਹੈ ਜੇ ਸਰਵਰ ਵੱਖਰਾ ਸੋਰਟ ਕੀ ਹੈ। ਡੀਊਪਿੰਗ ਲਈ tempId-to-realId ਨਕਸ਼ਾ ਰੱਖੋ ਅਤੇ ਜਦੋਂ ਅਸਲੀ ID ਮਿਲੇ ਤਾਂ ਇੱਕ ਹੀ ਆਈਟਮ ਵਿੱਚ ਬਦਲੋ, ਤਾਂ ਜੋ ਸਕ੍ਰੋਲ ਤੇ ਚੋਣ ਟੁੱਟਣ ਨਾ ਪਾਏ।
ਅਕਸਰ ਗਲਤੀਆਂ ਇਹ ਹੁੰਦੀਆਂ ਹਨ ਕਿ ਅਨੁਮਾਨੀ ਸੋਧ ਨੂੰ ਨਵੀਂ ਸੱਚਾਈ ਸਮਝ ਲਿਆ ਜਾਂਦਾ ਹੈ। ਛੋਟੇ, ਨਿਸ਼ਾਨਾ ਪੈਚ ਰੱਖੋ; pending ਫਲੈਗ ਸਾਫ਼ ਕਰੋ; ਰੋਲਬੈਕ ਲਈ ਸਹੀ ਸਨੈਪਸ਼ਾਟ ਸੰਭਾਲੋ; ਅਤੇ ਸਰਵਰ ਰੀਰਾਈਟਸ ਜਾਂ ਪਾਰਸ਼ਲ ਫੇਲਯੂਰ ਨੂੰ ਮਾਨੋ।