Add convenience configurator for collection paginators

[DRSchlaubi]

Currently there isn't any easy way to cerate a paginator just for a list of items, this PR aims to fix that

[gdude2002]

This API seems far too complex and domain-specific. The functions are, in general, pretty nuts - this is something that requires too much mental overhead to include as a user-facing API.

What's your use-case for this? Why not just collection.forEach { page { ... } }?

[DRSchlaubi]

This API seems far too complex and domain-specific. The functions are, in general, pretty nuts - this is something that requires too much mental overhead to include as a user-facing API.

This seems like the most common use case for paginators, just listing a collection

What's your use-case for this? Why not just collection.forEach { page { ... } }
This functions also allow usage of e.g. Flows and request content on the fly instead of requesting all the pages at once, also always having to do the manual formatting is pretty annoying.

Also, this is pretty similar to what JDA utilities does here: https://github.com/JDA-Applications/JDA-Utilities/blob/master/menu/src/main/java/com/jagrosh/jdautilities/menu/Paginator.java

GitHub

JDA-Utilities/Paginator.java at master · JDA-Applications/JDA-Utilities

A series of tools and utilities for JDA to assist in bot creation - JDA-Utilities/Paginator.java at master · JDA-Applications/JDA-Utilities

[gdude2002]

This seems like the most common use case for paginators, just listing a collection

Right, but you're not just listing a collection here, you're importing a collection with 4 separate required arguments most of which don't seem like they'd be useful for most people.

This functions also allow usage of e.g. Flows and request content on the fly instead of requesting all the pages at once, also always having to do the manual formatting is pretty annoying.

I have different ideas for lazy paginators that I'll be exploring in #90 - I don't think just throwing a flow into the builder is going to help much.

Also, this is pretty similar to what JDA utilities does here [ ... ]

Eh, where? This is a 730 line file.

[DRSchlaubi]

Right, but you're not just listing a collection here, you're importing a collection with 4 separate required arguments most of which don't seem like they'd be useful for most people.

There are 6 of them, but only 3 of them are actually required, and we could eliminate one of them if we add a function specifically for strings, and we could eliminate another one if we specify a default title

I have different ideas for lazy paginators that I'll be exploring in #90 - I don't think just throwing a flow into the builder is going to help much.

A page stores the builder as this suspend EmbedBuilder.() -> Unit so the request function of the paginator gets called when rendering the page, which means that depending on the flow implementation this is lazy

[gdude2002]

A page stores the builder as this suspend EmbedBuilder.() -> Unit so the request function of the paginator gets called when rendering the page, which means that depending on the flow implementation this is lazy

That's really only technically lazy, not lazy in a meaningful way. Either way, the Flow has to be exhausted for the paginator to be shown - that's not ideal for several use-cases that I can think of.

There are 6 of them, but only 3 of them are actually required, and we could eliminate one of them if we add a function specifically for strings, and we could eliminate another one if we specify a default title

Pages aren't... Strings, though? They're full embed builders. That was a deliberate choice for formatting flexibility, and it's been a suuuuuuper long time since pages were restricted this way.

[gdude2002]

Marking this as stale as it hasn't had activity for well over a week.

[gdude2002]

This has been stale for too long, so I'm closing it for now. I already had plans for this feature, so don't worry too much - it's just one of those things.