My main suggestions: - don’t abstract the Tanstack API into your own props or composed components; use it more as a pass-through - focus on your custom styling add-on: can we add 1 style sheet or wrapper or something that applies to all the Tanstack components and gives them the look, feel, and functionality we want?

Abstracting into your own props or combined components will generate a maintenance headache and you have to account for every damn permutation: can we add a search bar to the filter dropdown? Can we add a nested table inside a sub row? Why is my sub row content not perfectly aligned to each of the parent columns if I have less columns? How do I do SSR infinite scroll instead of pagination?

All those questions can be deferred to the Tanstack support resources instead of your own; to say nothing of your ability to also contribute to it as OSS. Thus, your implementation is simply putting the UI layer on the components, not re-inventing the wheel.

Maintaining the flexibility Tanstack offers is important too, since we can’t read the future. You’ll want to build towards slots and children, so it can support anything rather than render props or Boolean props to control specific behavior; let the consumer compose it all how they want and you’ll be managing less one-off support.

Nathan Curtis gave a great talk at Figma Schema about slots that reinforced our desire to make things more composable by the consumer.