ਜਦ ਡੇਟਾ ਬਦਲਦਾ ਹੈ ਤਾਂ ਕਰਸਰ ਪੈਜੀਨੇਸ਼ਨ ਲਿਸਟਾਂ ਨੂੰ ਸਥਿਰ ਰੱਖਦਾ ਹੈ। ਜਾਣੋ ਕਿ ਇਨਸਰਟਸ ਤੇ ਡਿਲੀਟਸ ਨਾਲ offset paging ਕਿਵੇਂ ਟੁੱਟਦੀ ਹੈ, ਅਤੇ ਸਾਫ਼ ਕਰਸਰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਣੇ ਹਨ।

ਤੁਸੀਂ ਇੱਕ ਫੀਡ ਖੋਲ੍ਹਦੇ ਹੋ, ਥੋੜ੍ਹਾ ਸਕ੍ਰੋਲ ਕਰਦੇ ਹੋ, ਅਤੇ ਸਭ ਕੁਝ ਠੀਕ ਲੱਗਦਾ ਹੈ ਜਦ ਤੱਕ ਉਹ ਨਹੀਂ ਹੁੰਦਾ। ਤੁਸੀਂ ਇੱਕੋ ਆਈਟਮ ਦੁਬਾਰਾ ਵੇਖਦੇ ਹੋ। ਕੋਈ ਚੀਜ਼ ਜੋ ਤੁਸੀਂ ਯਕੀਨਨ ਵੇਖੀ ਸੀ, ਉਹ ਗਾਇਬ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਰੋਅ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਟੈਪ ਕਰਨ ਵਾਲੇ ਸੀ ਥੱਲੇ ਖਿਸਕ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਗਲਤ ਡੀਟੇਲ ਪੇਜ਼ 'ਤੇ ਚਲੇ ਜਾਂਦੇ ਹੋ।
ਇਹ ਯੂਜ਼ਰ-ਦਿਖਾਈ ਦੇਣ ਵਾਲੀਆਂ ਬੱਗਾਂ ਹਨ, ਭਾਵੇਂ ਤੁਹਾਡੇ API ਰਿਸਪਾਂਸ ਇਕੱਲੇ ਵਿੱਚ “ਸਹੀ” ਲੱਗਣ। ਆਮ ਲੱਛਣ ਆਸਾਨੀ ਨਾਲ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ:
ਮੋਬਾਈਲ 'ਤੇ ਇਹ ਹੋਰ ਵੀ ਖਰਾਬ ਹੁੰਦਾ ਹੈ। ਲੋਕ ਰੁਕਦੇ ਹਨ, ਐਪਸ ਬਦਲਦੇ ਹਨ, ਕੁਨੈਕਟਿਵਿਟੀ ਖੋ ਬੈਠਦੇ ਹਨ, ਫਿਰ ਬਾਅਦ ਵਿੱਚ ਜਾਰੀ ਰੱਖਦੇ ਹਨ। ਉਸ ਦੌਰਾਨ ਨਵੇਂ ਆਈਟਮ ਆਉਂਦੇ ਹਨ, ਪੁਰਾਣੇ ਹਟਾਏ ਜਾਂਦੇ ਹਨ, ਤੇ ਕੁਝ ਐਡੀਟ ਹੁੰਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਐਪ page 3 ਲਈ ਓਫਸੈਟ ਵਰਤ ਕੇ ਕਈ ਵਾਰ ਪੁੱਛਦੀ ਰਹਿੰਦੀ ਹੈ, ਤਾਂ ਪੇਜ਼ ਸੀਮਾਵਾਂ ਯੂਜ਼ਰ ਦੇ ਮੱਝ ਸਕ੍ਰੋਲ ਦੌਰਾਨ ਖਿਸਕ ਸਕਦੀਆਂ ਹਨ। ਨਤੀਜਾ ਇੱਕ ਐਸਾ ਫੀਡ ਹੈ ਜੋ ਅਸਥਿਰ ਅਤੇ ਅਣਦੋਸਤ ਲੱਗਦਾ ਹੈ।
ਮਕਸਦ ਸਧਾਰਣ ਹੈ: ਜਦੋਂ ਇੱਕ ਯੂਜ਼ਰ ਅੱਗੇ ਸਕ੍ਰੋਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੇ, ਤਾਂ ਲਿਸਟ ਇੱਕ ਸਨੇਪਸ਼ਾਟ ਵਰਗੀ ਵਰਤੋਂ ਕਰੇ। ਨਵੇਂ ਆਈਟਮ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਯੂਜ਼ਰ ਦੁਆਰਾ ਪਹਿਲਾਂ ਵੇਖੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਦੁਬਾਰਾ ਨਹੀਂ ਲਗਾਉਣੇ ਚਾਹੀਦੇ। ਯੂਜ਼ਰ ਨੂੰ ਇੱਕ ਨਰਮ, ਭਵਿੱਵਾਨਸ਼ੀਲ ਕ੍ਰਮ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ।
ਕੋਈ ਵੀ ਪੈਜੀਨੇਸ਼ਨ ਵਿਧੀ ਪੂਰੀ ਨਹੀਂ। ਅਸਲ ਸਿਸਟਮਾਂ ਵਿੱਚ ਸਾਥੀ ਲਿਖਤਾਂ, ਐਡੀਟਸ, ਅਤੇ ਕਈ ਸੋਰਟ ਵਿਕਲਪ ਹੁੰਦੇ ਹਨ। ਪਰ ਕਰਸਰ ਪੈਜੀਨੇਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਓਫਸੈਟ ਪੈਜੀਨੇਸ਼ਨ ਨਾਲੋਂ ਸੁਰੱਖਿਅਤ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਸਥਿਰ ਕ੍ਰਮ ਵਿੱਚ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਸਥਿਤੀ ਤੋਂ ਪੇਜ ਕਰਦੀ ਹੈ, ਨਾਂ ਕਿ ਹਿਲਦੇ ਹੋਏ ਰੋਅ ਗਿਣਤੀ ਤੋਂ।
ਓਫਸੈਟ ਪੈਜੀਨੇਸ਼ਨ "skip N, take M" ਤਰੀਕਾ ਹੈ। ਤੁਸੀਂ API ਨੂੰ ਦੱਸਦੇ ਹੋ ਕਿ ਕਿੰਨੇ ਆਈਟਮ ਛੱਡਣੇ ਹਨ (offset) ਅਤੇ ਕਿੰਨੇ ਵਾਪਸ ਚਾਹੀਦੇ ਹਨ (limit). limit=20 ਨਾਲ, ਤੁਹਾਨੂੰ ਪ੍ਰਤੀ ਪੇਜ਼ 20 ਆਈਟਮ ਮਿਲਦੇ ਹਨ।
ਧਾਰਣਾਤਮਕ:
GET /items?limit=20\u0026offset=0 (ਪਹਿਲਾ ਪੇਜ਼)GET /items?limit=20\u0026offset=20 (ਦੂਜਾ ਪੇਜ਼)GET /items?limit=20\u0026offset=40 (ਤੀਜਾ ਪੇਜ਼)ਰਿਸਪਾਂਸ ਆਮ ਤੌਰ 'ਤੇ ਆਈਟਮਾਂ ਦੇ ਨਾਲ ਕਾਫ਼ੀ ਜਾਣਕਾਰੀ ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਅਗਲਾ ਪੇਜ਼ ਮੰਗਿਆ ਜਾ ਸਕੇ.
{
"items": [
{"id": 101, "title": "..."},
{"id": 100, "title": "..."}
],
"limit": 20,
"offset": 20,
"total": 523
}
ਇਹ ਲੋਕਪ੍ਰਿਯ ਹੈ ਕਿਉਂਕਿ ਇਹ ਟੇਬਲਾਂ, ਐਡਮਿਨ ਲਿਸਟਾਂ, ਖੋਜ ਨਤੀਜਿਆਂ, ਅਤੇ ਸਧਾਰਣ ਫੀਡਾਂ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮੈਚ ਕਰਦਾ ਹੈ। ਇਹ SQL ਵਿੱਚ LIMIT ਅਤੇ OFFSET ਨਾਲ ਵੀ ਆਸਾਨੀ ਨਾਲ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।
ਪਰ ਫੜ ਇਹ ਹੈ: ਲੁਕਿਆ ਹੋਇਆ ਮੰਨਣਾ ਇਹ ਹੈ ਕਿ ਡੇਟਾਸੇਟ ਰਿਕਵੈਸਟਸ ਦੌਰਾਨ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ। ਅਸਲ ਐਪਸ ਵਿੱਚ ਨਵੇਂ ਰੋਜ਼ ਇਨਸਰਟ ਹੋਂਦੇ ਹਨ, ਰੋਜ਼ ਡਿਲੀਟ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਸੋਰਟ ਕੀਜ਼ ਬਦਲਦੇ ਹਨ। ਇਥੇ ਹੀ “ਰਹੱਸਮੀ ਬੱਗ” ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ।
ਓਫਸੈਟ ਪੈਜੀਨੇਸ਼ਨ ਮੰਨਦਾ ਹੈ ਕਿ ਲਿਸਟ ਰਿਕਵੈਸਟਾਂ ਵਿੱਛਕਾਰ ਉਸੇ ਸਥਿਤੀ 'ਤੇ ਰਹਿੰਦੀ ਹੈ। ਪਰ ਅਸਲ ਲਿਸਟਾਂ ਹਿਲਦੀਆਂ ਹਨ। ਜਦ ਲਿਸਟ ਖਿਸਕਦੀ ਹੈ, ਤਾਂ skip 20 ਵਰਗਾ ਇੱਕ ਓਫਸੈਟ ਹੁਣ ਉਸੇ ਆਈਟਮਾਂ ਵੱਲ ਨਹੀਂ ਇਸ਼ਾਰਾ ਕਰਦਾ।
ਕਲਪਨਾ ਕਰੋ ਇੱਕ ਫੀਡ created_at desc (ਨਾਂਵਾ ਤੋਂ ਪੁਰਾਣਾ) ਨਾਲ ਹੈ, ਪੇਜ਼ ਸਾਈਜ਼ 3।
ਤੁਸੀਂ ਪੇਜ਼ 1 offset=0, limit=3 ਨਾਲ ਲੋਡ ਕਰਦੇ ਹੋ ਅਤੇ [A, B, C] ਮਿਲਦਾ ਹੈ।
ਹੁਣ ਇੱਕ ਨਵਾਂ ਆਈਟਮ X ਬਣਦਾ ਹੈ ਅਤੇ ਸਿਰ 'ਤੇ ਆ ਜਾਂਦਾ ਹੈ। ਲਿਸਟ ਹੁਣ [X, A, B, C, D, E, F, ...] ਹੈ। ਤੁਸੀਂ ਪੇਜ਼ 2 offset=3, limit=3 ਨਾਲ ਲੋਡ ਕਰਦੇ ਹੋ। ਸਰਵਰ [X, A, B] skip ਕਰਦਾ ਹੈ ਅਤੇ [C, D, E] ਵਾਪਸ ਕਰਦਾ ਹੈ।
ਤੁਸੀਂ C ਨੂੰ ਦੁਬਾਰਾ ਵੇਖ ਲਿਆ (ਡੁਪਲਿਕੇਟ), ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਤੁਸੀਂ ਇੱਕ ਆਈਟਮ ਛੱਡ ਦੇਵੋਗੇ ਕਿਉਂਕਿ ਸਭ ਕੁਝ ਥੱਲੇ ਖਿਸਕ ਗਿਆ।
ਡਿਲੀਟਸ ਉਲਟ ਨਤ<Result:
ਸ਼ੁਰੂ ਕਰੋ [A, B, C, D, E, F, ...] ਨਾਲ। ਤੁਸੀਂ ਪੇਜ਼ 1 ਲੋਡ ਕਰਦੇ ਹੋ ਅਤੇ [A, B, C] ਵੇਖਦੇ ਹੋ। ਪੇਜ਼ 2 ਤੋਂ ਪਹਿਲਾਂ B ਡਿਲੀਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਲਿਸਟ ਹੋ ਜਾਂਦੀ ਹੈ [A, C, D, E, F, ...]। offset=3 ਨਾਲ ਪੇਜ਼ 2 [A, C, D] skip ਕਰਦਾ ਹੈ ਅਤੇ [E, F, G] ਵਾਪਸ ਕਰਦਾ ਹੈ। D ਇੱਕ ਖੱਡ ਬਣ ਜਾਂਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਕਦੇ ਫੈਚ ਨਹੀਂ ਕਰਦੇ।
ਨਵੇਂ-ਪਹਿਲਾਂ ਫੀਡਾਂ ਵਿੱਚ, ਉੱਪਰ ਇਨਸਰਟਸ ਵਾਪਰਦੇ ਹਨ ਜੋ ਹਰ ਬਾਅਦਲੇ ਓਫਸੈਟ ਨੂੰ ਖਿਸਕਾ ਦਿੰਦੇ ਹਨ।
“ਸਥਿਰ ਲਿਸਟ” ਉਹੀ ਹੈ ਜੋ ਯੂਜ਼ਰ ਉਮੀਦ ਕਰਦੇ ਹਨ: ਜਦ ਉਹ ਅੱਗੇ ਸਕ੍ਰੋਲ ਕਰਦੇ ਹਨ, ਆਈਟਮਾਂ ਨਹੀਂ ਕੂਦਦੇ, ਦੁਹਰਾਏ ਜਾਂ ਅਣਝਾਇਜ਼ ਤੌਰ 'ਤੇ ਗਾਇਬ ਨਹੀਂ ਹੋਦੇ। ਇਹ ਸਮਾਂ ਰੋਕਣ ਦੀ ਬਜਾਏ pagination ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਬਾਰੇ ਹੈ।
ਦੋ ਵਿਚਾਰ ਆਕਸਰ ਮਿਲ ਜਾਂਦੇ ਹਨ:
created_at ਨਾਲ tie-breaker ਵਾਂਗ id) ਤਾਂ ਜੋ ਇੱਕੋ ਇਨਪੁੱਟ ਨਾਲ ਦੋ ਰਿਕਵੈਸਟ ਇੱਕੋ ਕ੍ਰਮ ਵਾਪਸ ਕਰਨ।Refresh ਅਤੇ scroll-forward ਵੱਖਰੇ ਲਤਵਾਰੇ ਹਨ। Refresh ਦਾ ਮਤਲਬ ਹੈ “ਹੁਣ ਨਵੀਆਂ ਚੀਜ਼ਾਂ ਦਿਖਾਓ,” ਇਸ ਲਈ ਸਿਰ ਉੱਤੇ बदਲ ਹੋ ਸਕਦਾ ਹੈ। Scroll-forward ਦਾ ਮਤਲਬ ਹੈ “ਜਿੱਥੋਂ ਮੈਂ ਸੀ ਉੱਥੋਂ ਜਾਰੀ ਰੱਖੋ,” ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਓਫਸੈਟ ਦੀ ਵਜ੍ਹਾ ਨਾਲ ਹੋਣ ਵਾਲੀ ਦੁਹਰਾਈ ਜਾਂ ਗੈਪ ਨਹੀਂ ਦੇਖਣੇ ਚਾਹੀਦੇ।
ਇੱਕ ਸਧਾਰਣ ਨਿਯਮ ਜੋ ਜ਼ਿਆਦਾਤਰ ਪੈਜੀਨੇਸ਼ਨ ਬੱਗ ਰੋਕਦਾ ਹੈ: ਅੱਗੇ ਸਕ੍ਰੋਲ ਕਰਦੇ ਸਮੇਂ ਕਦੇ ਵੀ ਦੁਹਰਾਵ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
ਕਰਸਰ ਪੈਜੀਨੇਸ਼ਨ ਪੇਜ਼ ਨੰਬਰ ਦੀ ਥਾਂ ਇੱਕ ਬੁੱਕਮਾਰਕ ਵਰਤਦਾ ਹੈ। “ਮੈਨੂੰ ਪੇਜ਼ 3 ਦਿਓ” ਦੀ ਥਾਂ ਕਲਾਇੰਟ ਕਹਿੰਦਾ ਹੈ “ਇਥੋਂ ਜਾਰੀ ਰੱਖੋ।”
ਕੰਟ੍ਰੈਕਟ ਸਿੱਧਾ ਹੈ:
ਇਹ ਇਨਸਰਟਸ ਅਤੇ ਡਿਲੀਟਸ ਨੂੰ ਬਿਹਤਰ ਸਹਿਣਸ਼ੀਲਤਾ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਕਰਸਰ ਗਿਣਤੀ ਦੀ ਥਾਂ ਸਾਰਟ ਕੀ ਕਰਨ ਵਾਲੀ ਸਥਿਤੀ ਨੂੰ ਅੰਕਿਤ ਕਰਦਾ ਹੈ।
ਅਣ-ਮੁਨਾਸਿਬ ਲੋੜ ਹੈ ਇੱਕ ਨਿਰਪੱਖ ਸੋਰਟ ਨਿਯਮ। ਤੁਹਾਨੂੰ ਇੱਕ ਸਥਿਰ ਆਦੇਸ਼ ਨਿਯਮ ਅਤੇ ਇੱਕ ਲਗਾਤਾਰ tie-breaker ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਕਰਸਰ ਇੱਕ ਭਰੋਸੇਯੋਗ ਬੁੱਕਮਾਰਕ ਨਹੀਂ ਰਹੇਗਾ।
شروع ਵਿੱਚ ਉਹੀ ਸੋਰਟ ਆਦੇਸ਼ ਚੁਣੋ ਜੋ ਲੋਕਾਂ ਦੇ ਪੜ੍ਹਨ ਦੇ ਤਰੀਕੇ ਨਾਲ ਮਿਲਦਾ ਹੋਵੇ। ਫੀਡ, ਸੁਨੇਹੇ, ਅਤੇ ਅਕਤਿਵਿਟੀ ਲਾਗ ਆਮ ਤੌਰ 'ਤੇ newest first ਹੁੰਦੇ ਹਨ। ਇਤਿਹਾਸ-ਸਬੰਧੀ ਚੀਜ਼ਾਂ ਜਿਵੇਂ invoices ਤੇ audit logs ਅਕਸਰ oldest first ਹੋਣ ਵਧੀਆ ਲੱਗਦਾ ਹੈ।
ਇੱਕ ਕਰਸਰ ਨੂੰ ਉਸ ਕ੍ਰਮ ਵਿੱਚ ਇੱਕ ਸਥਿਤੀ ਨੂੰ ਯੂਨੀਕ ਤੌਰ 'ਤੇ ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਦੋ ਆਈਟਮ ਇੱਕੋ ਕਰਸਰ ਵੈਲਯੂ ਸਾਂਝੇ ਕਰ ਸਕਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਅੰਤ ਵਿੱਚ duplicates ਜਾਂ gaps ਪਾਓਗੇ।
ਆਮ ਚੋਣਾਂ ਅਤੇ ਧਿਆਨ:
created_at ਕੇਵਲ: ਸਾਦਾ, ਪਰ ਠੀਕ ਨਹੀਂ ਜੇ ਬਹੁਤ ਸਾਰੇ ਰੋਅ ਇੱਕੋ ਟਾਈਮਸਟੈਮਪ ਰੱਖਦੇ ਹਨ।id ਕੇਵਲ: ਜੇ IDs monotonic ਹਨ ਤਾਂ ਸੁਰੱਖਿਅਤ, ਪਰ ਇਹ ਹਮੇਸ਼ਾ ਉਤਪਾਦ-ਵਰਗੀ ਕ੍ਰਮ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।created_at + id: ਆਮ ਤੌਰ 'ਤੇ ਚੰਗਾ ਮਿਕਸ (ਟਾਈਮਸਟੈਂਪ ਉਤਪਾਦੀ ਕ੍ਰਮ ਲਈ, id tie-breaker ਲਈ)।updated_at: infinite scroll ਲਈ ਖਤਰਨਾਕ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਐਡੀਟਸ ਆਈਟਮਾਂ ਨੂੰ ਪੇਜਾਂ ਵਿੱਚ ਘੁਮਾ ਸਕਦੇ ਹਨ।ਜੇ ਤੁਸੀਂ ਕਈ ਸੋਰਟ ਵਿਕਲਪ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਹਰ ਸੋਰਟ ਮੋਡ ਨੂੰ ਇੱਕ ਵੱਖਰੀ ਲਿਸਟ ਸਮਝੋ ਜਿਸ ਦੀ ਆਪਣੀ ਕਰਸਰ ਨਿਯਮ ਹੋਵੇ। ਇੱਕ ਕਰਸਰ ਸਿਰਫ ਇੱਕ ਨਿਰਧਾਰਤ ਕ੍ਰਮ ਲਈ ਮਾਨਯੋਗ ਹੁੰਦਾ ਹੈ।
ਤੁਸੀਂ API ਸਤਹ ਨੂੰ ਛੋਟਾ ਰੱਖ ਸਕਦੇ ਹੋ: ਦੋ ਇਨਪੁੱਟ, ਦੋ ਆਉਟਪੁੱਟ।
limit (ਤੁਸੀਂ ਕਿੰਨੇ ਆਈਟਮ ਚਾਹੁੰਦੇ ਹੋ) ਅਤੇ ਇੱਕ ਵੈਕਲਪਿਕ cursor (ਕਿੱਥੋਂ ਜਾਰੀ ਰੱਖਣਾ) ਭੇਜੋ। ਜੇ ਕਰਸਰ ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਸਰਵਰ ਪਹਿਲਾ ਪੇਜ਼ ਵਾਪਸ ਕਰੇਗਾ।
ਉਦਾਹਰਨ ਰੀਕੁਐਸਟ:
GET /api/messages?limit=30\u0026cursor=eyJjcmVhdGVkX2F0IjoiMjAyNi0wMS0xNlQxMDowMDowMFoiLCJpZCI6Ijk4NzYifQ==
ਆਈਟਮ ਅਤੇ next_cursor ਵਾਪਸ ਕਰੋ। ਜੇ ਅਗਲਾ ਕੋਈ ਪੇਜ਼ ਨਹੀਂ ਹੈ ਤਾਂ next_cursor: null ਕਰੋ। ਕਲਾਇੰਟ ਨੂੰ ਕਰਸਰ ਨੂੰ ਇਕ ਟੋਕਨ ਵਜੋਂ ਲੈਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਸਨੂੰ ਸੋਧਣ ਦਾ ਨਹੀਂ।
{
"items": [ {"id":"9876","created_at":"2026-01-16T10:00:00Z","subject":"..."} ],
"next_cursor": "...",
"has_more": true
}
ਸਰਵਰ-ਪਾਸੇ ਲਾਜਿਕ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ: ਇੱਕ ਸਥਿਰ ਕ੍ਰਮ ਵਿੱਚ sort ਕਰੋ, ਕਰਸਰ ਵਰਤ ਕੇ filter ਕਰੋ, ਫਿਰ limit ਲਗਾਓ।
ਜੇ ਤੁਸੀਂ newest first (created_at DESC, id DESC) ਨਾਲ sort ਕਰਦੇ ਹੋ, ਕਰਸਰ ਨੂੰ (created_at, id) ਵਿੱਚ decode ਕਰੋ, ਫਿਰ ਉਹ ਰੋਜ਼ ਲੱਭੋ ਜਿੱਥੇ (created_at, id) ਕਰਸਰ ਜੋੜੇ ਤੋਂ ਸਖ਼ਤੀ ਨਾਲ ਘੱਟ ਹਨ, ਉਹੀ ਆਦੇਸ਼ ਲਗਾਓ, ਅਤੇ limit ਰੋਜ਼ ਲਵੋ।
ਤੁਸੀਂ ਕਰਸਰ ਨੂੰ base64 JSON blob ਵਜੋਂ encode ਕਰ ਸਕਦੇ ਹੋ (ਆਸਾਨ) ਜਾਂ signed/encrypted token (ਜਿਆਦਾ ਕੰਮ). Opaque ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਇੰਟਰਨਲ ਤਰੀਕੇ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕਲਾਇੰਟ ਤੋੜੇ।
ਇਹ ਵੀ ਸਮਝੋ: ਮੋਬਾਈਲ ਲਈ ਸਮਝਦਾਰ ਡੀਫ਼ੋਲਟ (ਅਕਸਰ 20-30), ਵੈੱਬ ਲਈ ਡੀਫ਼ੋਲਟ (ਅਕਸਰ 50), ਅਤੇ ਸਰਵਰ 'ਤੇ ਇੱਕ ਸਖ਼ਤ ਸਰਹੱਦ ਰੱਖੋ ਤਾਂ ਕਿ ਕੋਈ ਬੱਗੀ ਕਲਾਇੰਟ 10,000 ਰੋਜ਼ ਨਾ ਮੰਗ ਸਕੇ।
ਇੱਕ ਸਥਿਰ ਫੀਡ ਬਹੁਤ ਹੱਦ ਤੱਕ ਇੱਕ ਵਾਅਦਾ ਹੈ: ਜਦ ਯੂਜ਼ਰ ਅੱਗੇ ਸਕ੍ਰੋਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਉਹ ਆਈਟਮ ਜੋ ਉਹ ਅਜੇ ਤੱਕ ਨਹੀਂ ਵੇਖੇ, ਉਹ ਕਿਸੇ ਹੋਰ ਦੇ ਇਨਸਰਟ, ਡਿਲੀਟ ਜਾਂ ਐਡੀਟ ਨਾਲ ਨਹੀਂ ਝਟਕਣੇ ਚਾਹੀਦੇ।
ਕਰਸਰ ਪੈਜੀਨੇਸ਼ਨ ਨਾਲ, ਇਨਸਰਟਸ ਸਭ ਤੋਂ ਆਸਾਨ ਹੁੰਦੇ ਹਨ। ਨਵੇਂ ਰਿਕਾਰਡ refresh 'ਤੇ ਦਿਖਣ ਚਾਹੀਦੇ ਹਨ, ਨਾ ਕਿ ਪਹਿਲਾਂ ਲੋਡ ਕੀਤੀਆਂ ਪੇਜਾਂ ਦੇ ਵਿਚਕਾਰ। ਜੇ ਤੁਸੀਂ created_at DESC, id DESC ਨਾਲ order ਕਰਦੇ ਹੋ, ਨਵੇਂ ਆਈਟਮ ਸੁਭਾਵਿਕ ਤੌਰ 'ਤੇ ਪਹਿਲੇ ਪੇਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਰਹਿਣਗੇ, ਇਸ ਲਈ ਮੌਜੂਦਾ ਕਰਸਰ ਬੁਜ਼ੁਰਗ ਆਈਟਮਾਂ ਵਿੱਚ ਕਨਟੀਨਿਊ ਕਰੇਗਾ।
ਡਿਲੀਟਸ ਲਿਸਟ ਨੂੰ ਖਿਸਕਾਉਣ ਨਹੀਂ ਚਾਹੀਦੀਆਂ। ਜੇ ਇੱਕ ਆਈਟਮ ਹਟ ਗਿਆ, ਉਹ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਵਾਪਸ ਨਹੀਂ ਹੋਵੇਗਾ ਜਦ ਤੁਸੀਂ ਉਸ ਨੂੰ ਫੈਚ ਕਰਦੇ। ਜੇ ਤੁਹਾਨੂੰ ਪੇਜ਼ ਸਾਈਜ਼ ਸਥਿਰ ਰੱਖਣੀ ਹੈ, ਤਾਂ limit ਤੱਕ ਦਿਖਣ ਯੋਗ ਆਈਟਮ ਇਕੱਠੇ ਹੋਣ ਤਕ ਫਿਰ ਤੋਂ ਫੈਚ ਕਰਦੇ ਰਹੋ।
ਐਡੀਟਸ ਉਹ ਜਗ੍ਹਾ ਹਨ ਜਿੱਥੇ ਟੀਮਾਂ ਗਲਤੀ ਨਾਲ ਫਿਰ ਬੱਗ ਦਿੰਦੇ ਹਨ। ਮੁੱਖ ਸਵਾਲ ਇਹ ਹੈ: ਕੀ ਕੋਈ ਐਡੀਟ ਸੋਰਟ ਪੋਜ਼ੀਸ਼ਨ ਬਦਲ ਸਕਦਾ ਹੈ?
ਸਕ੍ਰੋਲਿੰਗ ਲਿਸਟਾਂ ਲਈ ਆਮ ਤੌਰ 'ਤੇ snapshot-ਸਟਾਈਲ ਵਿਹਾਰ ਵਧੀਆ ਹੁੰਦਾ ਹੈ: ਇਕ ਅਟੱਲ ਕੁੰਜੀ ਜਿਵੇਂ created_at ਨਾਲ ਪੇਜ ਕਰੋ। ਐਡੀਟਸ ਸਮੱਗਰੀ ਬਦਲ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਆਈਟਮ ਆਪਣੀ ਪੋਜ਼ੀਸ਼ਨ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ।
Live-feed ਵਿਹਾਰ ਜਿਵੇਂ edited_at ਨਾਲ sort ਕਰਨਾ ਆਈਟਮਾਂ ਨੂੰ ਕੂਦਣ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਹ ਚੁਣਦੇ ਹੋ, ਤਾਂ ਲਿਸਟ ਨੂੰ ਲਗਾਤਾਰ ਬਦਲਦੇ ਹੋਏ ਦਰਸਾਉਣ ਲਈ UX ਡਿਜ਼ਾਇਨ ਕਰੋ ਅਤੇ refresh ਨੂੰ accept ਕਰੋ।
ਕਰਸਰ ਨੂੰ “ਇਸ ਖਾਸ ਰੋਅ ਨੂੰ ਲੱਭੋ” 'ਤੇ ਨਿਰਭਰ ਨਾ ਬਣਾਓ। ਪੋਜ਼ੀਸ਼ਨ ਨੂੰ ਵੈਲਯੂज़ ਵਜੋਂ encode ਕਰੋ, ਜਿਵੇਂ ਆਖਰੀ ਵਾਪਸ ਕੀਤੇ ਆਈਟਮ ਦਾ {created_at, id}। ਫਿਰ ਅਗਲਾ ਕਵੈਰੀ ਮੁੱਲਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੋਵੇ, ਨਾਂ ਕਿ ਰੋਅ ਦੀ ਮੌਜੂਦਗੀ 'ਤੇ:
WHERE (created_at, id) < (:created_at, :id)id) ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ duplicates ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇਅੱਗੇ ਪੇਜਿੰਗ ਆਸਾਨ ਹੈ। ਥੋੜੇ ਜ਼ਿਆਦਾ ਪੇਚੀਦਾ UX ਸਵਾਲ ਪਿੱਛੇ ਪੇਜਿੰਗ, refresh, ਅਤੇ ਰੈਂਡਮ ਆਕਸੈਸ ਹਨ।
ਪਿੱਛੇ ਪੇਜਿੰਗ ਲਈ ਦੋ ਤਰੀਕੇ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ:
next_cursor ਬੁਜ਼ੁਰਗਾਂ ਲਈ ਅਤੇ prev_cursor ਨਵੇਂ ਲਈ) ਜਦੋਂ ਇੱਕੋ ਨਜ਼ਰ ਕ੍ਰਮ ਰੱਖਿਆ ਜਾਵੇ।ਕਰਸਰਾਂ ਨਾਲ ਰੈਂਡਮ ਜੰਪ ਕਰਨਾ ਔਖਾ ਹੈ ਕਿਉਂਕਿ “ਪੇਜ਼ 20” ਦਾ ਸਥਿਰ ਮਤਲਬ ਬਦਲ ਸਕਦਾ ਹੈ ਜਦ ਡੇਟਾ ਬਦਲਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਜੰਪ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਕਿਸੇ ਐਂਕਰ ‘ਤੇ ਜੰਪ ਕਰੋ ਜਿਵੇਂ "ਇਸ timestamp ਦੇ ਆਲੇ-ਦੁਆਲੇ" ਜਾਂ "ਇਸ message id ਤੋਂ ਸ਼ੁਰੂ ਕਰਕੇ," ਨਾਂ ਕਿ ਪੇਜ਼ ਇੰਡੈਕਸ।
ਮੋਬਾਈਲ 'ਤੇ caching ਮਹੱਤਵਪੂਰਨ ਹੈ। ਕਰਸਰਾਂ ਨੂੰ ਹਰ ਲਿਸਟ ਸਟੇਟ (query + filters + sort) ਲਈ ਸਟੋਰ ਕਰੋ, ਅਤੇ ਹਰ ਟੈਬ/ਵਿਊ ਨੂੰ ਆਪਣੀ ਵੱਖਰੀ ਲਿਸਟ ਮਾਣੋ। ਇਸ ਨਾਲ "ਟੈਬ ਬਦਲੋ ਤੇ ਸਭ ਕੁਝ ਗੜਬੜ" ਵਾਲਾ ਵਰਤਾਰਾ ਰੁਕਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਕਰਸਰ ਪੈਜੀਨੇਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਡੇਟਾਬੇਸ ਲਈ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹ ਉਹ ਛੋਟੀ ਅਸੰਗਤੀਆਂ ਹਨ ਜੋ ਸਿਰਫ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਹੇਠਾਂ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ।
ਸਭ ਤੋਂ ਵੱਡੇ ਦੋਸ਼ੀ:
created_at ਕੇਵਲ) ਜਿਸ ਨਾਲ ਟਾਈਜ਼ duplicates ਜਾਂ missing ਆਈਟਮ ਬਣਦੇ ਹਨ।next_cursor ਵਾਪਸ ਕਰਨਾ ਜੋ ਅਸਲ ਵਿੱਚ ਆਖਰੀ ਵਾਪਸ ਕੀਤੇ ਗਏ ਆਈਟਮ ਨਾਲ ਮਿਲਦਾ-ਜੁਲਦਾ ਨਹੀਂ।ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਐਪ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ edge cases ਤੇਜ਼ੀ ਨਾਲ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਕਲਾਇੰਟ ਅਕਸਰ ਇੱਕੋ endpoint ਸਾਂਝੇ ਕਰਦੇ ਹਨ। ਇੱਕ ਸਪਸ਼ਟ ਕਰਸਰ કอนટ੍ਰੈਕਟ ਅਤੇ ਇੱਕ ਨਿਰਪੱਖ ordering rule ਦੋਹਾਂ ਕਲਾਇੰਟਾਂ ਨੂੰ ਸੰਗਠਿਤ ਰੱਖਦਾ ਹੈ।
ਪੈਜੀਨੇਸ਼ਨ ਨੂੰ "ਕੁੰਮਲ" ਘੋਸ਼ਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਨਸਰਟ, ਡਿਲੀਟ, ਅਤੇ retries ਹੇਠਾਂ ਵਿਹਾਰ ਦੀ ਜਾਂਚ ਕਰੋ।
next_cursor ਆਖਰੀ ਵਾਪਸ ਕੀਤੇ ਰੋਅ ਤੋਂ ਲਿਆ ਗਿਆ ਹੋਵੇlimit ਦਾ ਇੱਕ ਸੁਰੱਖਿਅਤ ਮੈਕਸ ਹੋਵੇ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਕੀਤਾ ਡੀਫ਼ੌਲਟ ਹੋਵੇRefresh ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਨਿਯਮ ਚੁਣੋ: ਯੂਜ਼ਰ ਪੂਲ-ਟੂ-ਰਿਫ੍ਰੈਸ਼ ਕਰਕੇ ਉੱਪਰ ਨਵੇਂ ਆਈਟਮ ਲਿਆਉਂ, ਜਾਂ ਵਾਰ-ਵਾਰ ਜਾਂਚ ਕਰੋ "ਮੇਰੇ ਪਹਿਲੇ ਆਈਟਮ ਤੋਂ ਨਵੇਂ ਕੁਝ ਹਨ?" ਅਤੇ ਇੱਕ "New items" ਬਟਨ ਦਿਖਾਓ। ਸਥਿਰਤਾ ਹੀ ਲਿਸਟ ਨੂੰ ਭਟਕਣ ਵਾਲੀ ਨਹੀਂ ਹੌਂਦੀ ਬਲਕਿ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।
ਕਲਪਨਾ ਕਰੋ ਇੱਕ support inbox ਜਿਸ ਨੂੰ ਏਜੰਟ ਵੈੱਬ 'ਤੇ ਵਰਤਦੇ ਹਨ ਅਤੇ ਮੈਨੇਜਰ ਮੋਬਾਈਲ 'ਤੇ ਵੇਖਦਾ ਹੈ। ਲਿਸਟ newest first ਹੈ। ਲੋਕ ਇੱਕ ਗੱਲ ਉਮੀਦ ਕਰਦੇ ਹਨ: ਜਦ ਉਹ ਅੱਗੇ ਸਕ੍ਰੋਲ ਕਰਦੇ ਹਨ, ਆਈਟਮ ਨਹੀਂ ਕੂਦਦੇ, ਦੁਹਰਾਏ ਜਾਂ ਗਾਇਬ ਨਹੀਂ ਹੁੰਦੇ।
ਓਫਸੈਟ ਪੈਜੀਨੇਸ਼ਨ ਨਾਲ, ਇੱਕ ਏਜੰਟ ਪੇਜ਼ 1 ਲੋਡ ਕਰਦਾ ਹੈ (ਆਈਟਮ 1-20), ਫਿਰ ਪੇਜ਼ 2 (offset=20) ਨੂੰ ਸਕ੍ਰੋਲ ਕਰਦਾ ਹੈ। ਜਦ ਉਹ ਪੜ੍ਹ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਦੋ ਨਵੇਂ ਸੁਨੇਹੇ ਉੱਪਰ ਆ ਜਾਂਦੇ ਹਨ। ਹੁਣ offset=20 ਉਹੀ ਥਾਂ ਨੂੰ ਨਹੀਂ ਦਰਸਾਉਂਦਾ ਜੋ ਇੱਕ ਸਕਿੰਟ ਪਹਿਲਾਂ ਸੀ। ਯੂਜ਼ਰ ਨੂੰ ਡੁਪਲਿਕੇਟ ਜਾਂ ਗੁੰਮ ਹੁੰਦੇ ਸੁਨੇਹੇ ਵੇਖਣ ਨੂੰ ਮਿਲਦੇ ਹਨ।
ਕਰਸਰ ਪੈਜੀਨੇਸ਼ਨ ਨਾਲ, ਐਪ “ਇਸ ਕਰਸਰ ਤੋਂ ਬਾਅਦ 20 ਆਈਟਮ” ਮੰਗਦਾ ਹੈ, ਜਿੱਥੇ ਕਰਸਰ ਆਖਰੀ ਵਾਪਸ ਕੀਤੇ ਆਈਟਮ 'ਤੇ ਆਧਾਰਿਤ ਹੁੰਦਾ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ (created_at, id)). ਨਵੇਂ ਸੁਨੇਹੇ ਦਿਨ ਭਰ ਆ ਸਕਦੇ ਹਨ, ਪਰ ਅਗਲਾ ਪੇਜ਼ ਹਮੇਸ਼ਾ ਉਸ ਆਖਰੀ ਸੁਨੇਹੇ ਦੇ ਬਾਅਦ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦਾ ਜਿਹੜਾ ਯੂਜ਼ਰ ਨੇ ਦੇਖਿਆ ਸੀ।
ਜਾਣਚ ਲਈ ਇਕ ਸਧਾਰਣ ਤਰੀਕਾ ਅੱਗੇ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ:
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ Koder.ai ਤੁਹਾਨੂੰ ਇੱਕ chat prompt ਤੋਂ endpoint ਅਤੇ ਕਲਾਇੰਟ ਫਲੋ scaffold ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ Planning Mode, snapshots ਅਤੇ rollback ਵਰਤ ਕੇ ਜਾਂਚ ਦੌਰਾਨ pagination ਬਦਲਾਅ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੋ ਕੇ ਦੁਹਰਾਓ।
Offset ਪੈਜੀਨੇਸ਼ਨ “skip N rows” ਨੂੰ ਦੇਖਦਾ ਹੈ, ਇਸ ਲਈ ਜਦ ਨਵੇਂ ਰੋਜ਼ ਇਨਸਰਟ ਹੋ ਜਾਂ ਪੁਰਾਣੇ ਰੋਜ਼ ਡਿਲੀਟ ਹੋ ਜਾਣ ਤਾਂ ਰੋਅ ਗਿਣਤੀ ਭਿੜ ਜਾਂਦੀ ਹੈ। ਇੱਕੋ offset ਅਚਾਨਕ ਦੂਜੇ ਆਈਟਮਾਂ ਵੱਲ ਸੰਕੇਤ ਕਰ ਸਕਦਾ ਹੈ ਜਿਹੜੇ ਪਹਿਲਾਂ ਨਹੀਂ ਸਨ — ਇਸ ਨਾਲ ਯੂਜ਼ਰ ਸਕ੍ਰੋਲ ਦੌਰਾਨ ਡੁਪਲਿਕੇਟ ਅਤੇ ਗੈਪ ਬਣਦੇ ਹਨ।
ਕਰਸਰ ਪੈਜੀਨੇਸ਼ਨ ਇੱਕ ਬੁੱਕਮਾਰਕ ਵਰਤੇਗੀ ਜੋ “ਮੈਂ ਜੋ ਆਖਰੀ ਆਈਟਮ ਵੇਖਿਆ ਉਸ ਤੋਂ ਬਾਅਦ ਦੀ ਪੋਜ਼ੀਸ਼ਨ” ਦੱਸਦੀ ਹੈ। ਅਗਲਾ ਰਿਕਵেস্ক ਉਸ ਪੋਜ਼ੀਸ਼ਨ ਤੋਂ ਜਾਰੀ ਰਹਿੰਦਾ ਹੈ ਇੱਕ ਨਿਰਪੱਖ ਕ੍ਰਮ ਵਿੱਚ, ਇਸ ਲਈ ਉੱਪਰ ਇਨਸਰਟ ਹੋਣ ਜਾਂ ਵਿਚਕਾਰ ਡਿਲੀਟ ਹੋਣ ਨਾਲ page boundary ਓਫਸੈਟ ਵਾਂਗ ਨਹੀਂ ਭਟਕਦੀ।
ਇੱਕ ਨਿਰਪੱਖ ਸੋਰਟ ਅਤੇ ਇੱਕ tie-breaker ਵਰਤੋ — ਸਭ ਤੋਂ ਆਮ (created_at, id) ਹੈ। created_at ਉਤਪਾਦ-ਮਿਤੀਬੱਧ ਕ੍ਰਮ ਦਿੰਦਾ ਹੈ ਤੇ id ਹਰ ਪੋਜ਼ੀਸ਼ਨ ਨੂੰ ਯੂਨੀਕ ਬਣਾਉਂਦਾ ਤਾਂ ਜੋ timestamp ਟਾਈਜ਼ ਹੋਣ 'ਤੇ ਵੀ ਤੁਸੀਂ ਆਈਟਮ ਦੁਹਰਾਉਂ ਜਾਂ ਛੱਡੋ ਨਾ।
updated_at 'ਤੇ ਸੋਰਟ ਕਰਨਾ ਆਈਟਮਾਂ ਨੂੰ ਪੇਜਾਂ ਵਿੱਚ ਹਿਲਾ ਸਕਦਾ ਹੈ ਜਦ ਉਨ੍ਹਾਂ ਨੂੰ ਐਡੀਟ ਕੀਤਾ ਜਾਵੇ, ਜੋ “ਸਥਿਰ ਅੱਗੇ ਸਕ੍ਰੋਲ” ਉਮੀਦ ਨੂੰ ਟੋੜਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਲਾਈਵ “ਸਭ ਤੋਂ ਹਾਲ ਹੀ ਵਿੱਚ ਅਪਡੇਟ” ਨਜ਼ਾਰਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ UI ਨੂੰ ਰਿਫ੍ਰੈਸ਼ ਲਈ ਤਿਆਰ ਰੱਖੋ ਅਤੇ reorder ਹੋਣ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰੋ।
Opaque token ਨੂੰ next_cursor ਵਜੋਂ ਵਾਪਸ ਕਰੋ ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਬਿਨਾ ਬਦਲੇ ਵਾਪਸ ਭੇஜਣ ਦਿਓ। ਇਕ ਸੀਧਾ ਢੰਗ base64 JSON blob ਵਿੱਚ ਆਖਰੀ ਆਈਟਮ ਦਾ (created_at, id) encode ਕਰਨਾ ਹੈ, ਪਰ ਇਸਨੂੰ opaque ਬਣਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਭਵਿੱਖ ਵਿੱਚ ਅੰਦਰੂਨੀ ਤਰੀਕੇ ਬਦਲ ਸਕੋ।
ਕਰਸਰ ਵੈਲਿਊਜ਼ 'ਤੇ ਆਧਾਰਿਤ ਅਗਲਾ ਕਵੈਰੀ ਬਣਾਓ, ਨਾ ਕਿ “ਇਸ ਖਾਸ ਰੋਅ ਨੂੰ ਲੱਭੋ” 'ਤੇ। ਜੇ ਆਖਰੀ ਆਈਟਮ ਡਿਲੀਟ ਹੋ ਗਿਆ, ਸਟੋਰ ਕੀਤਾ (created_at, id) ਫਿਰ ਵੀ ਇੱਕ ਪੋਜ਼ੀਸ਼ਨ ਵਰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਇੱਕ ਸਪਲੀਟ ਫਿਲਟਰ ਨਾਲ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹੋ।
ਕਠੋਰ ਤੁਲਨਾ (<), ਇੱਕ ਯੂਨੀਕ tie-breaker ਅਤੇ ਹਮੇਸ਼ਾਂ next_cursor ਨੂੰ ਆਖਰੀ ਵਾਪਸ ਕੀਤੇ ਗਏ ਰੋਅ ਤੋਂ ਲਓ। ਜ਼ਿਆਦਾਤਰ ਦੁਹਰਾਓ ਬੱਗ ਉਸ ਸਮੇਂ ਹੁੰਦੇ ਹਨ ਜਦ <= ਦੀ ਥਾਂ < ਵਰਤੀ ਜਾਂਦੀ ਹੈ, tie-breaker ਭੁੱਲ ਜਾਂ next_cursor ਗਲਤ ਰੋਅ ਤੋਂ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਸਾਫ ਨਿਯਮ ਚੁਣੋ: refresh ਉਪਰ ਨਵੇਂ ਆਈਟਮ ਲਿਆਉਂਦਾ ਹੈ, ਜਦਕਿ scroll-forward ਮੌਜੂਦਾ ਕਰਸਰ ਤੋਂ ਬੁਜ਼ੁਰਗ ਆਈਟਮਾਂ ਵੱਲ ਜਾਰੀ ਰਹਿੰਦਾ ਹੈ। refresh semantics ਨੂੰ ਉਹੀ ਕਰਸਰ ਫਲੋ ਵਿੱਚ ਨਾ ਮਿਲਾਓ, ਨਹੀਂ ਤਾਂ ਯੂਜ਼ਰ ਨੂੰ ਲਿਸਟ ਭਰਮਿਤ ਲੱਗੇਗੀ।
ਇੱਕ ਕਰਸਰ ਸਿਰਫ਼ ਇਕ ਹੀ ਕ੍ਰਮ ਅਤੇ ਫਿਲਟਰ ਸੈੱਟ ਲਈ ਵੈਧ ਹੁੰਦਾ ਹੈ। ਜੇ ਕਲਾਇੰਟ sort mode, ਖੋਜ ਜਾਂ ਫਿਲਟਰ ਬਦਲਦਾ ਹੈ ਤਾਂ ਨਵੀਂ pagination session ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਹਰ ਲਿਸਟ ਸਟੇਟ ਲਈ ਕਰਸਰ ਅਲੱਗ ਰੱਖੋ।
ਕਰਸਰ ਪੈਜੀਨੇਸ਼ਨ ਸੜੀਵਾਰ ਬਰਾਊਜ਼ਿੰਗ ਲਈ ਵਧੀਆ ਹੈ ਪਰ “ਪੇਜ 20” ਜਿਹਾ ਸਥਿਰ ਕਾਦੀਆਂ-ਕੁਦਿਆਂ ਵਾਲਾ ਜੰਪ ਨਹੀਂ ਦਿੰਦਾ ਕਿਉਂਕਿ ਡੇਟਾਸੇਟ ਬਦਲ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਜੰਪਿੰਗ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਕਿਸੇ ਐਂਕਰ ਲਈ ਜੰਪ ਕਰੋ—ਉਦਾਹਰਨ ਲਈ “ਇਸ timestamp ਦੇ ਆਲੇ-ਦੁਆਲੇ” ਜਾਂ “ਇਸ id ਤੋਂ ਬਾਅਦ ਸ਼ੁਰੂ ਕਰਦਿਆਂ” — ਫਿਰ ਓਥੇ ਤੋਂ ਕਰਸਰ ਨਾਲ paginate ਕਰੋ।