ორი სტრატეგია: offset-based (limit/offset) და cursor-based. GraphQL-ს ჩაშენებული pagination არ აქვს, მაგრამ საზოგადოების სტანდარტია Relay Connection სპეციფიკაცია, რომელიც cursor pagination-ს აფორმალებს.
ორი სტრატეგია: offset-based (limit/offset) და cursor-based. GraphQL-ს ჩაშენებული pagination არ აქვს, მაგრამ საზოგადოების სტანდარტია Relay Connection სპეციფიკაცია, რომელიც cursor pagination-ს აფორმალებს.
items(limit: 10, offset: 20)) მარტივია, მაგრამ ცოცხალ მონაცემზე ტყდება: თუ მომხმარებლის გვერდების გადათვალიერებისას ახალი მწკრივი ჩაემატა, ელემენტები იძვრება და ან დუბლიკატებს ხედავ, ან ხარვეზებს. ის ასევე ნელდება ღრმა offset-ებზე (DB ჯერ კიდევ სკანირებს გამოტოვებულ მწკრივებს).connection სიას ახვევს edges-ში (თითოს აქვს cursor და node) პლუს pageInfo:
type Query {
posts(first: Int!, after: String): PostConnection! # first = page size, after = cursor
}
type PostConnection {
edges: [PostEdge!]!
pageInfo: PageInfo!
}
type PostEdge {
cursor: String! # opaque token for THIS node's position
node: Post! # the actual item
}
type PageInfo {
endCursor: String # feed this back as 'after' for the next page
hasNextPage: Boolean! # so the client knows when to stop
}
// resolver: fetch ONE extra row to compute hasNextPage cheaply
const rows = await db.posts.find({ after: args.after, limit: args.first + 1 });
const hasNextPage = rows.length > args.first;
const page = rows.slice(0, args.first);
return {
edges: page.map((p) => ({ node: p, cursor: encodeCursor(p.id) })),
pageInfo: { endCursor: page.at(-1) && encodeCursor(page.at(-1).id), hasNextPage },
};
cursor არის გაუმჭვირვალე — ჩვეულებრივ sort key-ის base64 — ამიტომ კლიენტები მას token-ად აღიქვამენ და არა რიცხვად.
offset-ისა და cursor-ის არჩევა აჩვენებს, რომ გესმის მდგრადობა ერთდროული ჩაწერების პირობებში და ღრმა-გვერდის წარმადობა. Relay connection-ის ფორმის ცოდნას მნიშვნელობა აქვს, რადგან Apollo/Relay კლიენტებს მისთვის ჩაშენებული cache-ის მართვა აქვთ.
IT გასაუბრების კითხვების ბიბლიოთეკა დეტალური პასუხებით — Junior-დან Senior-მდე.
შემოწირულობა