Component Authoring Pagination Limitations
❔Advice
Hey there! I'm designing a series of reusable systems I'm going to use to build apps on convex, and I'm considering building many of these systems as components, but I noticed the pagination limitations, and I'm having second thoughts.
Here is an overview of what I'm building:
Payments - A system that tracks payments from payment processors and internal accounts (wallets, rewards, etc)
Billing - Invoices, Checkouts, etc
Financial Ledger - Used to track every penny using double-entry bookkeeping, and provides functionality for internal accounts + transactions.
Entitlements - Divides payments into pieces that are owed to different people (ie. Payouts to partners, my internal withholdings, etc)
Reporting - Ingests events, decorates with other data (ie. Product + Payment, etc) to iteratively build indexed tables that are suitable for building dashboard views, generating CSVs, etc
* Those are the big ones.
However, there are many cases where I'd want to expose reactive paginated APIs for these (ie. Payments, Ledger events, reporting datatable views, etc). I was excited to start using the filter convex helper, and query streams (which it seems also has an arbitrary TS filter built in), but the component authoring docs say to use the paginator helper, which doesn't support the filter helper, and there's no mention of query streams, so I'm wondering if this is a glaring limitation with components right now, or if I'm missing something.
So if anyone has some insight or advice here, I'm trying to figure out if it's sensible to build these as components, or if I should just build them as libraries and splat their respective table schemas into the core app.
Thank you to anyone who lends advice!
Here is an overview of what I'm building:
Payments - A system that tracks payments from payment processors and internal accounts (wallets, rewards, etc)
Billing - Invoices, Checkouts, etc
Financial Ledger - Used to track every penny using double-entry bookkeeping, and provides functionality for internal accounts + transactions.
Entitlements - Divides payments into pieces that are owed to different people (ie. Payouts to partners, my internal withholdings, etc)
Reporting - Ingests events, decorates with other data (ie. Product + Payment, etc) to iteratively build indexed tables that are suitable for building dashboard views, generating CSVs, etc
* Those are the big ones.
However, there are many cases where I'd want to expose reactive paginated APIs for these (ie. Payments, Ledger events, reporting datatable views, etc). I was excited to start using the filter convex helper, and query streams (which it seems also has an arbitrary TS filter built in), but the component authoring docs say to use the paginator helper, which doesn't support the filter helper, and there's no mention of query streams, so I'm wondering if this is a glaring limitation with components right now, or if I'm missing something.
So if anyone has some insight or advice here, I'm trying to figure out if it's sensible to build these as components, or if I should just build them as libraries and splat their respective table schemas into the core app.
Thank you to anyone who lends advice!
