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」って何か変じゃない？という気もするけどmrsekut.icon
「count」とかの方が適切だと思う
これらは、互いに導出可能なので、どちらを選んでも内部に影響はない
offset = (page - 1) * limit
page = offset / limit + 1
除算したくないし、直感的だし、page / countを使いたいかなmrsekut.icon
APIとは関係ないけど、URLにqueryを表出させる場合もpageの方が理解しやすい
limitは表出させずに、/items?page=2のようにすればいい
この観点だと、pageを使ったほうがcacheもさせやすい
Cursor-based Paginationの返り値にcursorを含めるかどうか
cursorの計算をbackend/frontendのどちらでやるか、という話
backendでやるなら以下のようにcursorを明示的に返す感じになる
code: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をするかの選択で返り値を変えたくないmrsekut.icon
引数の方のinterfaceでpagenationの方法は確定するんだが。