ਰਹੱਸਮਈ ਬੱਗਾਂ ਤੋਂ ਬਿਨਾਂ ਸਥਿਰ API ਲਿਸਟਾਂ ਲਈ ਕਰਸਰ ਪੈਜੀਨੇਸ਼ਨ

ਸਮੱਸਿਆ: ਲਿਸਟਾਂ ਜੋ ਤੁਹਾਡੇ ਹੱਥ ਹੇਠਾਂ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ

ਤੁਸੀਂ ਇੱਕ ਫੀਡ ਖੋਲ੍ਹਦੇ ਹੋ, ਥੋੜ੍ਹਾ ਸਕ੍ਰੋਲ ਕਰਦੇ ਹੋ, ਅਤੇ ਸਭ ਕੁਝ ਠੀਕ ਲੱਗਦਾ ਹੈ ਜਦ ਤੱਕ ਉਹ ਨਹੀਂ ਹੁੰਦਾ। ਤੁਸੀਂ ਇੱਕੋ ਆਈਟਮ ਦੁਬਾਰਾ ਵੇਖਦੇ ਹੋ। ਕੋਈ ਚੀਜ਼ ਜੋ ਤੁਸੀਂ ਯਕੀਨਨ ਵੇਖੀ ਸੀ, ਉਹ ਗਾਇਬ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਰੋਅ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਟੈਪ ਕਰਨ ਵਾਲੇ ਸੀ ਥੱਲੇ ਖਿਸਕ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਗਲਤ ਡੀਟੇਲ ਪੇਜ਼ 'ਤੇ ਚਲੇ ਜਾਂਦੇ ਹੋ।

ਇਹ ਯੂਜ਼ਰ-ਦਿਖਾਈ ਦੇਣ ਵਾਲੀਆਂ ਬੱਗਾਂ ਹਨ, ਭਾਵੇਂ ਤੁਹਾਡੇ 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 ਦਿਓ” ਦੀ ਥਾਂ ਕਲਾਇੰਟ ਕਹਿੰਦਾ ਹੈ “ਇਥੋਂ ਜਾਰੀ ਰੱਖੋ।”

ਕੰਟ੍ਰੈਕਟ ਸਿੱਧਾ ਹੈ:

• API ਆਈਟਮਾਂ ਦੀ ਇੱਕ ਬੈਚ ਦੇ ਨਾਲ ਉਹ ਪੋਜ਼ੀਸ਼ਨ ਦਰਸਾਉਂਦਾ ਕਰਸਰ ਦਿੰਦਾ ਹੈ ਜੋ ਆਖਰੀ ਆਈਟਮ ਦੇ ਬਾਅਦ ਹੈ।
• ਕਲਾਇੰਟ ਉਸ ਕਰਸਰ ਨੂੰ ਫਿਰ ਅਗਲੀ ਬੈਚ ਲਈ ਭੇਜਦਾ ਹੈ।

ਇਹ ਇਨਸਰਟਸ ਅਤੇ ਡਿਲੀਟਸ ਨੂੰ ਬਿਹਤਰ ਸਹਿਣਸ਼ੀਲਤਾ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਕਰਸਰ ਗਿਣਤੀ ਦੀ ਥਾਂ ਸਾਰਟ ਕੀ ਕਰਨ ਵਾਲੀ ਸਥਿਤੀ ਨੂੰ ਅੰਕਿਤ ਕਰਦਾ ਹੈ।

ਅਣ-ਮੁਨਾਸਿਬ ਲੋੜ ਹੈ ਇੱਕ ਨਿਰਪੱਖ ਸੋਰਟ ਨਿਯਮ। ਤੁਹਾਨੂੰ ਇੱਕ ਸਥਿਰ ਆਦੇਸ਼ ਨਿਯਮ ਅਤੇ ਇੱਕ ਲਗਾਤਾਰ 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 ਆਕਾਰ

ਤੁਸੀਂ API ਸਤਹ ਨੂੰ ਛੋਟਾ ਰੱਖ ਸਕਦੇ ਹੋ: ਦੋ ਇਨਪੁੱਟ, ਦੋ ਆਉਟਪੁੱਟ।

1) ਰੀਕੁਐਸਟ: limit + cursor

limit (ਤੁਸੀਂ ਕਿੰਨੇ ਆਈਟਮ ਚਾਹੁੰਦੇ ਹੋ) ਅਤੇ ਇੱਕ ਵੈਕਲਪਿਕ cursor (ਕਿੱਥੋਂ ਜਾਰੀ ਰੱਖਣਾ) ਭੇਜੋ। ਜੇ ਕਰਸਰ ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਸਰਵਰ ਪਹਿਲਾ ਪੇਜ਼ ਵਾਪਸ ਕਰੇਗਾ।

ਉਦਾਹਰਨ ਰੀਕੁਐਸਟ:

GET /api/messages?limit=30\u0026cursor=eyJjcmVhdGVkX2F0IjoiMjAyNi0wMS0xNlQxMDowMDowMFoiLCJpZCI6Ijk4NzYifQ==

2) ਰਿਸਪਾਂਸ: items + next_cursor

ਆਈਟਮ ਅਤੇ 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 ਰੋਜ਼ ਲਵੋ।

3) ਕਰਸਰ encoding: opaque ਜਿੱਤਦਾ ਹੈ

ਤੁਸੀਂ ਕਰਸਰ ਨੂੰ base64 JSON blob ਵਜੋਂ encode ਕਰ ਸਕਦੇ ਹੋ (ਆਸਾਨ) ਜਾਂ signed/encrypted token (ਜਿਆਦਾ ਕੰਮ). Opaque ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਇੰਟਰਨਲ ਤਰੀਕੇ ਬਦਲ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਕਲਾਇੰਟ ਤੋੜੇ।

ਇਹ ਵੀ ਸਮਝੋ: ਮੋਬਾਈਲ ਲਈ ਸਮਝਦਾਰ ਡੀਫ਼ੋਲਟ (ਅਕਸਰ 20-30), ਵੈੱਬ ਲਈ ਡੀਫ਼ੋਲਟ (ਅਕਸਰ 50), ਅਤੇ ਸਰਵਰ 'ਤੇ ਇੱਕ ਸਖ਼ਤ ਸਰਹੱਦ ਰੱਖੋ ਤਾਂ ਕਿ ਕੋਈ ਬੱਗੀ ਕਲਾਇੰਟ 10,000 ਰੋਜ਼ ਨਾ ਮੰਗ ਸਕੇ।

ਇਨਸਰਟ, ਡਿਲੀਟ, ਅਤੇ ਐਡੀਟ ਕੀਤੇ ਆਈਟਮਾਂ ਨੂੰ ਹੈਂਡਲ ਕਰਨਾ

ਇੱਕ ਸਥਿਰ ਫੀਡ ਬਹੁਤ ਹੱਦ ਤੱਕ ਇੱਕ ਵਾਅਦਾ ਹੈ: ਜਦ ਯੂਜ਼ਰ ਅੱਗੇ ਸਕ੍ਰੋਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਉਹ ਆਈਟਮ ਜੋ ਉਹ ਅਜੇ ਤੱਕ ਨਹੀਂ ਵੇਖੇ, ਉਹ ਕਿਸੇ ਹੋਰ ਦੇ ਇਨਸਰਟ, ਡਿਲੀਟ ਜਾਂ ਐਡੀਟ ਨਾਲ ਨਹੀਂ ਝਟਕਣੇ ਚਾਹੀਦੇ।

ਕਰਸਰ ਪੈਜੀਨੇਸ਼ਨ ਨਾਲ, ਇਨਸਰਟਸ ਸਭ ਤੋਂ ਆਸਾਨ ਹੁੰਦੇ ਹਨ। ਨਵੇਂ ਰਿਕਾਰਡ refresh 'ਤੇ ਦਿਖਣ ਚਾਹੀਦੇ ਹਨ, ਨਾ ਕਿ ਪਹਿਲਾਂ ਲੋਡ ਕੀਤੀਆਂ ਪੇਜਾਂ ਦੇ ਵਿਚਕਾਰ। ਜੇ ਤੁਸੀਂ created_at DESC, id DESC ਨਾਲ order ਕਰਦੇ ਹੋ, ਨਵੇਂ ਆਈਟਮ ਸੁਭਾਵਿਕ ਤੌਰ 'ਤੇ ਪਹਿਲੇ ਪੇਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਰਹਿਣਗੇ, ਇਸ ਲਈ ਮੌਜੂਦਾ ਕਰਸਰ ਬੁਜ਼ੁਰਗ ਆਈਟਮਾਂ ਵਿੱਚ ਕਨਟੀਨਿਊ ਕਰੇਗਾ।

ਡਿਲੀਟਸ ਲਿਸਟ ਨੂੰ ਖਿਸਕਾਉਣ ਨਹੀਂ ਚਾਹੀਦੀਆਂ। ਜੇ ਇੱਕ ਆਈਟਮ ਹਟ ਗਿਆ, ਉਹ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਵਾਪਸ ਨਹੀਂ ਹੋਵੇਗਾ ਜਦ ਤੁਸੀਂ ਉਸ ਨੂੰ ਫੈਚ ਕਰਦੇ। ਜੇ ਤੁਹਾਨੂੰ ਪੇਜ਼ ਸਾਈਜ਼ ਸਥਿਰ ਰੱਖਣੀ ਹੈ, ਤਾਂ limit ਤੱਕ ਦਿਖਣ ਯੋਗ ਆਈਟਮ ਇਕੱਠੇ ਹੋਣ ਤਕ ਫਿਰ ਤੋਂ ਫੈਚ ਕਰਦੇ ਰਹੋ।

ਐਡੀਟਸ ਉਹ ਜਗ੍ਹਾ ਹਨ ਜਿੱਥੇ ਟੀਮਾਂ ਗਲਤੀ ਨਾਲ ਫਿਰ ਬੱਗ ਦਿੰਦੇ ਹਨ। ਮੁੱਖ ਸਵਾਲ ਇਹ ਹੈ: ਕੀ ਕੋਈ ਐਡੀਟ ਸੋਰਟ ਪੋਜ਼ੀਸ਼ਨ ਬਦਲ ਸਕਦਾ ਹੈ?

snapshot ਵਿਹਾਰ ਜਾਂ live ਵਿਹਾਰ ਚੁਣੋ

ਸਕ੍ਰੋਲਿੰਗ ਲਿਸਟਾਂ ਲਈ ਆਮ ਤੌਰ 'ਤੇ snapshot-ਸਟਾਈਲ ਵਿਹਾਰ ਵਧੀਆ ਹੁੰਦਾ ਹੈ: ਇਕ ਅਟੱਲ ਕੁੰਜੀ ਜਿਵੇਂ created_at ਨਾਲ ਪੇਜ ਕਰੋ। ਐਡੀਟਸ ਸਮੱਗਰੀ ਬਦਲ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਆਈਟਮ ਆਪਣੀ ਪੋਜ਼ੀਸ਼ਨ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ।

Live-feed ਵਿਹਾਰ ਜਿਵੇਂ edited_at ਨਾਲ sort ਕਰਨਾ ਆਈਟਮਾਂ ਨੂੰ ਕੂਦਣ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਹ ਚੁਣਦੇ ਹੋ, ਤਾਂ ਲਿਸਟ ਨੂੰ ਲਗਾਤਾਰ ਬਦਲਦੇ ਹੋਏ ਦਰਸਾਉਣ ਲਈ UX ਡਿਜ਼ਾਇਨ ਕਰੋ ਅਤੇ refresh ਨੂੰ accept ਕਰੋ।

ਜਦ ਕਰਸਰ ਆਈਟਮ ਹੋਰ ਮੌਜੂਦ ਨਾ ਹੋਵੇ

ਕਰਸਰ ਨੂੰ “ਇਸ ਖਾਸ ਰੋਅ ਨੂੰ ਲੱਭੋ” 'ਤੇ ਨਿਰਭਰ ਨਾ ਬਣਾਓ। ਪੋਜ਼ੀਸ਼ਨ ਨੂੰ ਵੈਲਯੂज़ ਵਜੋਂ encode ਕਰੋ, ਜਿਵੇਂ ਆਖਰੀ ਵਾਪਸ ਕੀਤੇ ਆਈਟਮ ਦਾ {created_at, id}। ਫਿਰ ਅਗਲਾ ਕਵੈਰੀ ਮੁੱਲਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੋਵੇ, ਨਾਂ ਕਿ ਰੋਅ ਦੀ ਮੌਜੂਦਗੀ 'ਤੇ:

• ਘਟਦੇ ਆਦੇਸ਼ ਲਈ: WHERE (created_at, id) < (:created_at, :id)
• ਹਮੇਸ਼ਾਂ tie-breaker (id) ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ duplicates ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ
• ਜੇ ਆਖਰੀ ਆਈਟਮ ਡਿਲੀਟ ਹੋ ਗਿਆ, ਮੁੱਲ ਫਿਰ ਵੀ ਕੰਮ ਕਰਦੇ ਹਨ
• ਜੇ ਆਖਰੀ ਆਈਟਮ ਐਡੀਟ ਹੋ ਗਿਆ, ਇਹ ਤਬ ਤੱਕ ਚੱਲਦਾ ਹੈ ਜਦ ਤੇਰੇ ਸੋਰਟ ਕੀਜ਼ ਅਮਰ ਰਹਿਣ

ਪਿੱਛੇ ਪੇਜਿੰਗ, refresh, ਅਤੇ ਆਜ਼ਾਦੀ ਨਾਲ ਜੰਪ ਕਰਨਾ

ਅੱਗੇ ਪੇਜਿੰਗ ਆਸਾਨ ਹੈ। ਥੋੜੇ ਜ਼ਿਆਦਾ ਪੇਚੀਦਾ UX ਸਵਾਲ ਪਿੱਛੇ ਪੇਜਿੰਗ, refresh, ਅਤੇ ਰੈਂਡਮ ਆਕਸੈਸ ਹਨ।

ਪਿੱਛੇ ਪੇਜਿੰਗ ਲਈ ਦੋ ਤਰੀਕੇ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ:

• ਦੋਹਾਂ ਦਿਸ਼ਾਵਾਂ ਵਾਪਸ ਕਰੋ (next_cursor ਬੁਜ਼ੁਰਗਾਂ ਲਈ ਅਤੇ prev_cursor ਨਵੇਂ ਲਈ) ਜਦੋਂ ਇੱਕੋ ਨਜ਼ਰ ਕ੍ਰਮ ਰੱਖਿਆ ਜਾਵੇ।
• ਇੱਕ ਹੀ ਕਰਸਰ ਰੱਖੋ, ਪਰ ਯੂਜ਼ਰ ਜਦੋਂ ਉੱਪਰ ਸਕ੍ਰੋਲ ਕਰੇ ਤਾਂ ਰਿਵਰਸਡ ਸੋਰਟ ਮੰਗੋ।

ਕਰਸਰਾਂ ਨਾਲ ਰੈਂਡਮ ਜੰਪ ਕਰਨਾ ਔਖਾ ਹੈ ਕਿਉਂਕਿ “ਪੇਜ਼ 20” ਦਾ ਸਥਿਰ ਮਤਲਬ ਬਦਲ ਸਕਦਾ ਹੈ ਜਦ ਡੇਟਾ ਬਦਲਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਜੰਪ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਕਿਸੇ ਐਂਕਰ ‘ਤੇ ਜੰਪ ਕਰੋ ਜਿਵੇਂ "ਇਸ timestamp ਦੇ ਆਲੇ-ਦੁਆਲੇ" ਜਾਂ "ਇਸ message id ਤੋਂ ਸ਼ੁਰੂ ਕਰਕੇ," ਨਾਂ ਕਿ ਪੇਜ਼ ਇੰਡੈਕਸ।

ਮੋਬਾਈਲ 'ਤੇ caching ਮਹੱਤਵਪੂਰਨ ਹੈ। ਕਰਸਰਾਂ ਨੂੰ ਹਰ ਲਿਸਟ ਸਟੇਟ (query + filters + sort) ਲਈ ਸਟੋਰ ਕਰੋ, ਅਤੇ ਹਰ ਟੈਬ/ਵਿਊ ਨੂੰ ਆਪਣੀ ਵੱਖਰੀ ਲਿਸਟ ਮਾਣੋ। ਇਸ ਨਾਲ "ਟੈਬ ਬਦਲੋ ਤੇ ਸਭ ਕੁਝ ਗੜਬੜ" ਵਾਲਾ ਵਰਤਾਰਾ ਰੁਕਦਾ ਹੈ।

ਆਮ ਗਲਤੀਆਂ ਜੋ ਰਹੱਸਮੀ ਬੱਗ ਬਣਾਉਂਦੀਆਂ ਹਨ

ਜ਼ਿਆਦਾਤਰ ਕਰਸਰ ਪੈਜੀਨੇਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਡੇਟਾਬੇਸ ਲਈ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹ ਉਹ ਛੋਟੀ ਅਸੰਗਤੀਆਂ ਹਨ ਜੋ ਸਿਰਫ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਹੇਠਾਂ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ।

ਸਭ ਤੋਂ ਵੱਡੇ ਦੋਸ਼ੀ:

• ਨਾਨ-ਯੂਨੀਕ ਕਰਸਰ ਵਰਤਣਾ (ਉਦਾਹਰਨ ਲਈ created_at ਕੇਵਲ) ਜਿਸ ਨਾਲ ਟਾਈਜ਼ duplicates ਜਾਂ missing ਆਈਟਮ ਬਣਦੇ ਹਨ।
• next_cursor ਵਾਪਸ ਕਰਨਾ ਜੋ ਅਸਲ ਵਿੱਚ ਆਖਰੀ ਵਾਪਸ ਕੀਤੇ ਗਏ ਆਈਟਮ ਨਾਲ ਮਿਲਦਾ-ਜੁਲਦਾ ਨਹੀਂ।
• ਰਿਕਵੈਸਟਾਂ ਦੇ ਵਿਚਕਾਰ ਫਿਲਟਰ ਜਾਂ ਸੋਰਟ ਆਰਡਰ ਬਦਲਣਾ।
• ਇੱਕੋ endpoint ਵਿੱਚ offset ਅਤੇ cursor ਮਿਲਾਉਣਾ।

ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਐਪ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਹ edge cases ਤੇਜ਼ੀ ਨਾਲ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਵੈੱਬ ਅਤੇ ਮੋਬਾਈਲ ਕਲਾਇੰਟ ਅਕਸਰ ਇੱਕੋ endpoint ਸਾਂਝੇ ਕਰਦੇ ਹਨ। ਇੱਕ ਸਪਸ਼ਟ ਕਰਸਰ કอนટ੍ਰੈਕਟ ਅਤੇ ਇੱਕ ਨਿਰਪੱਖ ordering rule ਦੋਹਾਂ ਕਲਾਇੰਟਾਂ ਨੂੰ ਸੰਗਠਿਤ ਰੱਖਦਾ ਹੈ।

ਸ਼ਿਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਰੰਤ ਚੈੱਕਲਿਸਟ

ਪੈਜੀਨੇਸ਼ਨ ਨੂੰ "ਕੁੰਮਲ" ਘੋਸ਼ਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਨਸਰਟ, ਡਿਲੀਟ, ਅਤੇ retries ਹੇਠਾਂ ਵਿਹਾਰ ਦੀ ਜਾਂਚ ਕਰੋ।

• ਸੋਰਟ ਸਪਸ਼ਟ, ਨਿਰਪੱਖ ਅਤੇ tie-breaker ਸ਼ਾਮਲ ਕਰਦਾ ਹੋਵੇ
• ਹਰ ਰਿਕਵੈਸਟ ਇੱਕੋ ਫਿਲਟਰ ਅਤੇ ਸੋਰਟ ਫੀਲਡ ਦੁਹਰਾਉਂਦਾ ਹੋਵੇ
• next_cursor ਆਖਰੀ ਵਾਪਸ ਕੀਤੇ ਰੋਅ ਤੋਂ ਲਿਆ ਗਿਆ ਹੋਵੇ
• limit ਦਾ ਇੱਕ ਸੁਰੱਖਿਅਤ ਮੈਕਸ ਹੋਵੇ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਕੀਤਾ ਡੀਫ਼ੌਲਟ ਹੋਵੇ
• ਰਿਫ੍ਰੈਸ਼ ਵਿਹਾਰ ਪਰਿਭਾਸ਼ਤ ਹੋਵੇ (ਨਵੇਂ ਆਈਟਮ ਕਿਵੇਂ ਦਿਖਦੇ ਹਨ)

Refresh ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਨਿਯਮ ਚੁਣੋ: ਯੂਜ਼ਰ ਪੂਲ-ਟੂ-ਰਿਫ੍ਰੈਸ਼ ਕਰਕੇ ਉੱਪਰ ਨਵੇਂ ਆਈਟਮ ਲਿਆਉਂ, ਜਾਂ ਵਾਰ-ਵਾਰ ਜਾਂਚ ਕਰੋ "ਮੇਰੇ ਪਹਿਲੇ ਆਈਟਮ ਤੋਂ ਨਵੇਂ ਕੁਝ ਹਨ?" ਅਤੇ ਇੱਕ "New items" ਬਟਨ ਦਿਖਾਓ। ਸਥਿਰਤਾ ਹੀ ਲਿਸਟ ਨੂੰ ਭਟਕਣ ਵਾਲੀ ਨਹੀਂ ਹੌਂਦੀ ਬਲਕਿ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।

ਇੱਕ ਹਕੀਕਤੀ ਉਦਾਹਰਨ: ਇਕ ਇਨਬਾਕਸ ਜੋ ਡਿਵਾਈਸਾਂ 'ਤੇ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ

ਕਲਪਨਾ ਕਰੋ ਇੱਕ support inbox ਜਿਸ ਨੂੰ ਏਜੰਟ ਵੈੱਬ 'ਤੇ ਵਰਤਦੇ ਹਨ ਅਤੇ ਮੈਨੇਜਰ ਮੋਬਾਈਲ 'ਤੇ ਵੇਖਦਾ ਹੈ। ਲਿਸਟ newest first ਹੈ। ਲੋਕ ਇੱਕ ਗੱਲ ਉਮੀਦ ਕਰਦੇ ਹਨ: ਜਦ ਉਹ ਅੱਗੇ ਸਕ੍ਰੋਲ ਕਰਦੇ ਹਨ, ਆਈਟਮ ਨਹੀਂ ਕੂਦਦੇ, ਦੁਹਰਾਏ ਜਾਂ ਗਾਇਬ ਨਹੀਂ ਹੁੰਦੇ।

ਓਫਸੈਟ ਪੈਜੀਨੇਸ਼ਨ ਨਾਲ, ਇੱਕ ਏਜੰਟ ਪੇਜ਼ 1 ਲੋਡ ਕਰਦਾ ਹੈ (ਆਈਟਮ 1-20), ਫਿਰ ਪੇਜ਼ 2 (offset=20) ਨੂੰ ਸਕ੍ਰੋਲ ਕਰਦਾ ਹੈ। ਜਦ ਉਹ ਪੜ੍ਹ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਦੋ ਨਵੇਂ ਸੁਨੇਹੇ ਉੱਪਰ ਆ ਜਾਂਦੇ ਹਨ। ਹੁਣ offset=20 ਉਹੀ ਥਾਂ ਨੂੰ ਨਹੀਂ ਦਰਸਾਉਂਦਾ ਜੋ ਇੱਕ ਸਕਿੰਟ ਪਹਿਲਾਂ ਸੀ। ਯੂਜ਼ਰ ਨੂੰ ਡੁਪਲਿਕੇਟ ਜਾਂ ਗੁੰਮ ਹੁੰਦੇ ਸੁਨੇਹੇ ਵੇਖਣ ਨੂੰ ਮਿਲਦੇ ਹਨ।

ਕਰਸਰ ਪੈਜੀਨੇਸ਼ਨ ਨਾਲ, ਐਪ “ਇਸ ਕਰਸਰ ਤੋਂ ਬਾਅਦ 20 ਆਈਟਮ” ਮੰਗਦਾ ਹੈ, ਜਿੱਥੇ ਕਰਸਰ ਆਖਰੀ ਵਾਪਸ ਕੀਤੇ ਆਈਟਮ 'ਤੇ ਆਧਾਰਿਤ ਹੁੰਦਾ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ (created_at, id)). ਨਵੇਂ ਸੁਨੇਹੇ ਦਿਨ ਭਰ ਆ ਸਕਦੇ ਹਨ, ਪਰ ਅਗਲਾ ਪੇਜ਼ ਹਮੇਸ਼ਾ ਉਸ ਆਖਰੀ ਸੁਨੇਹੇ ਦੇ ਬਾਅਦ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦਾ ਜਿਹੜਾ ਯੂਜ਼ਰ ਨੇ ਦੇਖਿਆ ਸੀ।

ਜਾਣਚ ਲਈ ਇਕ ਸਧਾਰਣ ਤਰੀਕਾ ਅੱਗੇ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ:

• ਇੱਕ ਸਕ੍ਰਿਪਟ ਚਲਾਉਂਦੇ ਹੋਏ ਪੇਜ਼ੇ ਫੈਚ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਹਰ ਸੈਕਿੰਡ ਨਵਾਂ ਸੁਨੇਹਾ ਇਨਸਰਟ ਕਰਦਾ ਹੈ
• ਮੱਝ ਸਕ੍ਰੋਲ ਦੌਰਾਨ ਕੁਝ ਸੁਨੇਹੇ ਡਿਲੀਟ ਕਰੋ
• ਇੱਕ ਸੁਨੇਹੇ ਨੂੰ ਐਡੀਟ ਕਰੋ (ਉਸਦੇ ordering fields ਬਦਲੇ ਬਿਨਾਂ)
• ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਦੇ ਵੀ duplicates, gaps ਜਾਂ out-of-order ਆਈਟਮ ਨਹੀਂ ਪਾਉਂਦੇ
• ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਮੋਬਾਈਲ ਐਪ ਅਤੇ ਵੈੱਬ ਐਪ ਸਮਾਨ ਪੇਜ਼ ਬਾਊਂਡਰੀਆਂ ਦਿਖਾਉਂਦੇ ਹਨ

ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ Koder.ai ਤੁਹਾਨੂੰ ਇੱਕ chat prompt ਤੋਂ endpoint ਅਤੇ ਕਲਾਇੰਟ ਫਲੋ scaffold ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ Planning Mode, snapshots ਅਤੇ rollback ਵਰਤ ਕੇ ਜਾਂਚ ਦੌਰਾਨ pagination ਬਦਲਾਅ ਤੋਂ ਸੁਰੱਖਿਅਤ ਹੋ ਕੇ ਦੁਹਰਾਓ।