Declaration merging makes typing per-table meta difficult

[wyozi]

Hey, I really liked the ability to specify per-table meta types on a per-table basis with table.setRowType. I'm working on an application that has many kinds of tables with different meta functions all over the codebase, so declaration merging causes extraneous meta function definitions and all kinds of other issues.

Would it be possible to add a method to still be able to specify meta types on a per-table basis?

[tannerlinsley]

This would require a return to the insane generics. I doubt the benefits would outweigh the increased friction on types.

[Faithfinder]

What if you add a second generic for TableMeta to createColumnHelper?

[varwasabi]

This is also something i was looking for recently. Whilst the meta option is definitely great; being able to have independent types for each table would help keep things a bit more tidy. Can understand why you wouldn't want to go down that route though @tannerlinsley

[chiptus]

I found this discussion just before I was going to post about it. I don't like the insane generics thing too (and v7 added more problems with that as we had to define global types per the plugins we used). I would love to hear if someone found a solution to it. currently, I just add more props to meta, but I have no way to understand which types are related...

I do think adding a generic for meta is the solution here

[emrerdem1]

I’m strongly in favor of restoring a per-table meta-type setter. In large codebases where dozens of tables each carry a different row-meta contract, forcing all meta functions into a single merged global interface quickly becomes unmanageable... duplicate definitions and unintended meta callbacks get pulled into tables where they don’t belong.