The TableMeta DX

[llllvvuu]

I feel like the DX would be improved if:

• The TableMeta was part of the type variant (i.e. Table<TData, TError, TMeta>) instead of having to declaration-merge
• it was available in more places (e.g. accessorFn can't use it right now - I ended up dynamically generating columns instead of using TableMeta)

It seems like passing things like handlers and context into the global table scope should be a common workflow. Thoughts?

[Guria]

I doubling the point about accessorFn should have access to TableInstance or TableMeta.
We can't even use something like custom hooks to get data. I know I can use Cell for this purpose but in this case it wouldn't be filterable using global filter.

[chiptus]

I use a custom hook useColumns to generate the columns (if needed)

[llllvvuu]

I just noticed that

I ended up dynamically generating columns instead of using TableMeta

is not reactive, i.e. react-table doesn't react to changes in columns prop (it seems what react-table does is trigger the core instance table setOptions -> functionalUpdate, which doesn't include refreshing the accessed values). So TableMeta would really be the only way, if only it could be passed to accessorFn.

[KevinVandy]

What do you mean "react table doesn't react to changes in the columns prop?". News to me.

[llllvvuu]

No worries, here's a minimal repro (I copied the v8 quickstart into create-react-app and added a counter): https://github.com/llllvvuu/react-table-minimal-repro

[KevinVandy]

Oh. The problem is that accessors are frozen/memorized internally for performance. Columns themselves are not. You can change column options on the fly. Having the accessor depend on a changing value is unsupported right now.

[CalMlynarczyk]

This issue comes back up every few months and unfortunately the creator of the library is leaning away from making meta generic per table definition. I have only used v6 on a previous project and v8 currently on a greenfield project, so I do not have the historical context for v7 that he refers to in his comment. From a fixed standpoint though, I agree with the OP that making meta generic is the way to go.

I've personally found this problem to be exacerbated by the fact that there is no built-in way to do custom row state in v8. It appears the only way to implement custom row state as of now is to bolt on an external state store to the meta property of the table definition and reference it from your cell renderers. I've written a few responses about workarounds for implementing row state, but so far I haven't been satisfied with any of these solutions.

Our TableMeta type definition has grown to around 20 properties as we continue to add more and more features and tables to our application. This means we have to define all 20 of those properties for every table in our application, which turns each new meta property/table feature into an exponential amount of work. I might just try reverting to v7 and see if that gives us the flexibility we need.

[TonyVeigel]

@CalMlynarczyk How is V8 working for you? I'm in the process of deciding if we should upgrade from V7 to V8 and I find V8 much more obfuscated. As well, it seems hard to do much of anything custom. The upgrade is more of a re-write which also make me a little worried about what another upgrade would look like.

[CalMlynarczyk]

We've figured out how to make it work for us, but modifying table functionality is one of the most frustrating tasks we have to deal with in our codebase right now. Since I've never used v7, I can't say how different the two are from each other. Custom row-state would make life a lot easier, because the only ways I've found to implement it lead to a lot of unnecessary re-renders since you have to manage all row state from a parent scope.

[TonyVeigel]

Not sure what you mean by row state. What are you trying to accomplish?

[mamlzy]

@tannerlinsley