Add Current Page Request to Pagination Service

[whimxiqal]

I am interested in knowing the page that a player is viewing of a paginated list I sent them.

I want the option to send a new paginated list as a clickable menu, but it will only work well if I send them back an updated paginated list at the same page they left off at. So, I want to be able to ask what page they were viewing when they clicked on something.

To use this, the developer would do something like the following:

Map<UUID, PaginationList> playerLists = new HashMap<>();
String textData = "Click to update me!";

void sendPagination(ServerPlayer player) {
  PaginationList list = paginationService.builder().title("title")
    .contents(Collections.singletonList(Component.text(textData)
      .clickEvent(ClickEvent.runCommand("/update"))
    .build();
  int index;
  if (playerLists.contains(player.uniqueId())) {
    index = paginationService.currentPage(playerLists.get(player.uniqueId())).orElse(1);
  } else {
    index = 1;
  }
  list.sendTo(player, index);
  playerLists.put(player.uniqueId(), list);
}

...
// in send command
sendPagination(player);
...

...
// in update command
textData = "Updated!"
sendPagination(player)
...

Another option would be to put this current page data in the PaginationList interface itself. Or is there another, simpler way to request a specific page that a player left off at?

[whimxiqal]

Another option could be to add a custom index option when building a paginator in PaginationList.Builder. So, when you build a PaginationList, you can set some integer or string that identifies it so that when you build another PaginationList with the same id, it opens back up to the same page they were viewing before, essentially "replacing" the previous one.

[dualspiral]

This isn't a great way to solve the problem as we don't assume stored state anywhere in the API (whether or not that's the case in the impl is irrelavent, even if it's the only viable way to do it -- though all we really store is the paginationlist for a given player).

I don't want to store any more state.

There might be a case for adding a callback or event (ChangePaginationPageEvent?) for changing a page, so that your plugin can do the state management it needs to do - though it might require some internal logic changes.

[whimxiqal]

I was hoping we could just pass through the stored page index in the ActivePagination of the last known pagination.

I'm all for the page-change event though. Isn't that only when /page next and /page prev is called though?

[dualspiral]

I was hoping we could just pass through the stored page index in the ActivePagination of the last known pagination.

I honestly do not want to do that - it's very much an implementation detail designed to support the /page command which, in itself, is part of the pagination service. The state of the system is internal and I don't want other implementations of the service to feel beholden to that.

I'm all for the page-change event though. Isn't that only when /page next and /page prev is called though?

Well... considering there isn't one right now, we can do what we like. Could be on the /page command, could be on clicking things, it'd all be up to the service.

[whimxiqal]

Well... considering there isn't one right now, we can do what we like.

Would you like me to come up with an event interface then? Or do you no want to put other pagination implementations on the hook for posting those events?

[ImMorpheus]

Going over old PRs.

I honestly do not want to do that - it's very much an implementation detail designed to support the /page command which, in itself, is part of the pagination service.

I think this is a core point of why this solution is not going to work. A few other valid solutions have been proposed, events being a similar approach to what we are doing for economy, so I'll close this PR.