Skip to content

feat(pagination): add ability to overwrite pagination text#79

Merged
mattrothenberg merged 2 commits intocloudflare:mainfrom
dochne:main
Feb 13, 2026
Merged

feat(pagination): add ability to overwrite pagination text#79
mattrothenberg merged 2 commits intocloudflare:mainfrom
dochne:main

Conversation

@dochne
Copy link
Contributor

@dochne dochne commented Feb 11, 2026

What have you changed?

This adds support for a text argument for the Pagination component. I've done this by adding a text argument which accepts a method that can return React.ReactNode. It takes a prop argument of all the variables that a user might want to use to generate custom text.

What are you trying to achieve?

I have a table of data which can have thousands of entries in it. Pagination is done via token.

In current usage, we are aware of what the totalCount is, which allows me to pass it in and this will all work fine.

However, we are looking at adding search functionality to this table. In this new circumstance, we will not be aware of what the total count is. Two things are true of our current API design:

  1. in order to have a next button enabled, totalCount needs to be set
  2. if we have totalCount set, it will appear in this text

While the wrapping interface will be a little ugly, this will allow me to "fake" the totalCount if I have a continuation token - while ensuring that this isn't shown in the text.

What other possibilities are there?

I've explored this space a bit in my previous PR, which introduced "simple" pagination for this component. Even if this is a little gross on my side, this feels the cleanest way from a this API point of view.

Other possible iterations on the text={({perPage}) => `Hey! ${perPage}`} solution could be either:

  • just allow text text={`Hey! ${perPage}`} - as all of the context is technically being passed into the Pagination component, you could avoid the method. I like the fact that our current method gives us easy access to the {pageShowingRange} variable however
  • allow this in addition to the callback (e.g. support text={"my text"} and text={() => "my text"}
  • instead of passing {pageShowingRange} as a single variable that looks like 1-9, we could pass a {lowerItem} and {upperItem} instead (or similar), as the dash feels a bit like a presentation concern

Other potential changes here could be that text isn't a great prop name - description could work better? Happy to change if there are any better suggestions

@pkg-pr-new
Copy link

pkg-pr-new bot commented Feb 11, 2026

npm i https://pkg.pr.new/@cloudflare/kumo@79

commit: 7e76e8a

@github-actions
Copy link
Contributor

github-actions bot commented Feb 11, 2026

Docs Preview

View docs preview

Commit: 7e76e8a

@github-actions
Copy link
Contributor

github-actions bot commented Feb 11, 2026

Visual Regression Report

5 screenshot(s) with visual changes:

Button / Loading State

Before After
Before After

Dialog / Basic Dialog

Before After
Before After

Select / Select

Before After
Before After

Select / Select.Option

Before After
Before After

Select (Open)

Before After
Before After
8 screenshot(s) unchanged
  • Button / Variants
  • Button / Sizes
  • Button / With Icon
  • Button / Icon Only
  • Button / Disabled State
  • Dialog / Confirmation Dialog (Alert)
  • Dialog / With Actions
  • Dialog (Open)

Generated by Kumo Visual Regression

@mattrothenberg mattrothenberg merged commit 752fdf1 into cloudflare:main Feb 13, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants