PagenationのAPI
from Pagination
APIのinterfaceを、DB側の都合に合わせて設計することになる
利用者目線ではなく、実装の都合によって決まってしまう
というか、それに合わせてUIを考えないといけない
DBの都合でUIが変わるとか変な話だけども。
SQLでPaginationの要件を比べてどちらがふさわしいかを考えて決定するぐらいしかできない
Offset-based Paginationを採用するなら、
APIとして、以下の2つの選択肢がある
limit / offset DBのinterfaceをそのまま表出させた感じ
page / limit Pagerの形態と合致している
例えば、各ページ12項目表示する時に、3ページ目を見たければ、
page=3, limit=12 とする利用者シーンの感覚に合っている
件数を表すのに「limit」って何か変じゃない？という気もするけど
「count」とかの方が適切だと思う
これらは、互いに導出可能なので、どちらを選んでも内部に影響はない
offset = (page - 1) * limit page = offset / limit + 1 除算したくないし、直感的だし、
page / count を使いたいかなAPIとは関係ないけど、URLにqueryを表出させる場合も
page の方が理解しやすい limit は表出させずに、 /items?page=2 のようにすればいいこの観点だと、
page を使ったほうがcacheもさせやすいCursor-based Paginationの返り値にcursorを含めるかどうか
cursorの計算をbackend/frontendのどちらでやるか、という話
backendでやるなら以下のようにcursorを明示的に返す感じになる
ts const results = await prisma.fabric.findMany({
where: { ... },
take: limit,
...(cursor == null
? {}
: {
skip: 1,
cursor: {
id: cursor,
},
}),
orderBy: { id: 'asc' },
});
return {
items: results,
cursor: results.at(-1)?.id,
};でも、情報量的には
items さえあればfrontendでも計算できるどちらのPagenationをするかの選択で返り値を変えたくない
引数の方のinterfaceでpagenationの方法は確定するんだが。