Reactive props for useVueTable

[d-lasagno]

I was experimenting with vue-table, but I can't understand how to pass reactive data as props for useVueTable. I wrapped the table options inside a reactive object, but whenever the options update, the table remains the same. Is there a way to update the table?

Here is a snippet of what I used:

const tableOptions = reactive<TableOptions<Document>>({
  data: props.data, // Updating this doesn't work
  getCoreRowModel: getCoreRowModel(),
  columns, // Updating this doesn't work too: tableOptions.columns.push(columns[0])
});

const table = useVueTable(tableOptions);

[vojvodics]

@d-lasagno Sorry, this is a year late, but I just recently started using vue-table. You can get data to be reactive by making it a js-getter. I didn't try it with columns, but I don't see why it wouldn't work

const tableOptions = reactive<TableOptions<Document>>({
  get data() { 
    return props.data;
  },
  getCoreRowModel: getCoreRowModel(),
  get columns() {
    return props.columns
  }, 
});

const table = useVueTable(tableOptions);

[andreiculda]

Thank you. This works indeed.

[rlsystems]

I love it when someone comes along and provides a clear, understandable solution

[vojvodics]

@rlsystems thanks, but I can't take the credit for it - I took it from the examples folder: https://github.com/TanStack/table/blob/main/examples/vue/basic/src/App.vue#L100-L106

I opened up a new discussion to allow more vue-like API when using vue-table #5102. The current API confuses me - I guess it makes sense in the react ecosystem, but we might need something slightly different for vue

[vincerubinetti]

I use both React and Vue extensively, and I'd say even for React, expecting the user to make use of a get/seter is fairly odd. data: () => props.data as you suggest in your discussion would be much more in line with expectations, and even more consistent with other tanstack apis.

[shax-xxx]

Hello.
Maybe someone can share a working example?

All my attempts to get reactivity from the table have failed.
I update defaultData in onBeforeMount after 10 seconds, but the table does not update automatically or manually with the Rerender button.

My last try:
https://codesandbox.io/p/devbox/lucid-heisenberg-f6w7xz?file=%2Fsrc%2FApp.vue%3A56%2C22

[TonyG89]

As mentioned above, use a getter.

const table = useVueTable({
  get data() {
    return data.value
  },
  columns,
  getCoreRowModel: getCoreRowModel(),
})

[vojvodics]

@shax-xxx Your example didn't work because defaultData has a reference to the same object/array.

I changed your example: https://codesandbox.io/p/devbox/lucid-heisenberg-forked-mv8t6f?file=%2Fsrc%2FApp.vue%3A71%2C1
You could also change the defaultData to be a let, and change the reference to defaultData instead of calling .push

[vincerubinetti]

As of v8.20.0, it looks like they've added Vue reactivity for data only (for now):
#5687

They're talking about doing it for all props in v9 (coming up hopefully soon).

Docs page: https://tanstack.com/table/latest/docs/framework/vue/guide/table-state#using-reactive-data

Thanks @OlaAlsaker!

Related follow-up PRs with bug-fixes (so, you should probably use > v8.20.0):
#5694
#5698

[buzzzzer]

Since 8.20 tanstack/vue-table became unusable.
8.20.3 fixed performance, but reactivity still broken with both variants

data: props.data
// or
get data() {
    return props.data
  },

queryClient.invalidateQueries({ queryKey: ['somekey'] }) does not affect

[OlaAlsaker]

Since 8.20 tanstack/vue-table became unusable. 8.20.3 fixed performance, but reactivity still broken with both variants

data: props.data
// or
get data() {
    return props.data
  },

queryClient.invalidateQueries({ queryKey: ['somekey'] }) does not affect

Are you sure that props.data is actually reactive? If you are using defineProps, try something like this and see if it works:

const props = defineProps<{ data: any[] }>();
const { data } = toRefs(props);

const table = useVueTable({
  data,
  // other options ...
});

[buzzzzer]

Are you sure that props.data is actually reactive? If you are using defineProps, try something like this and see if it works:

const props = defineProps<{ data: any[] }>();
const { data } = toRefs(props);

const table = useVueTable({
  data,
  // other options ...
});

wrapped toRefs(props) works for me

[R0tmayer]

For me it doesn't work

Vue: Type Ref<TData[]> is missing the following properties from type TData[]: length, pop, push, concat, and 29 more.

[zdenkolini]

For me it doesn't work

Vue: Type Ref<TData[]> is missing the following properties from type TData[]: length, pop, push, concat, and 29 more.

you are using a ref instead of the data array, this is a typescript error

[randName]

Thanks for the good work by @OlaAlsaker on Vue reactivity support, I was almost going to give up on this lib due to #4876 but I'm just glad things moved. I understand some more work is planned on supporting the other options, so I took a look and experimented with doing things "the Vue way" over at https://stackblitz.com/edit/musakui-vue-table?file=src%2FApp.vue

• Use of slots rather than render functions
• What's with all the mergeProxy stuff and stateProxy? is it just for backwards compat?
• Controlled state still feels weird for Vue reactivity aka signals-like
  • something simple like pagination still seems clunky (especially getting the pageCount reactively)
  • row selection doesn't seem to play well, I suspect because it doesn't understand how row.getIsSelected() is reactive and doesn't update the checkboxes

[KevinVandy]

@randName would you like to help on the v9 adapter where breaking changes are ok?

[OlaAlsaker]

Yes, mergeProxy and stateProxy are needed for backward compatibility. When we are not passing reactive data, this is needed to make everything work.

As for the slots, I am not sure if that should be a part of TanStack Table. The library is a headless library, so basing columns on slots is kind of wrong in my opinion. However, it could be provided as an example in the docs 😄

If you want to make other properties reactive (like pagination-stuff), you probably have to do something similar to what we do with the data:

table/packages/vue-table/src/index.ts

Lines 82 to 95 in 6b4d616

	// Add reactivity support
	if (IS_REACTIVE) {
	const dataRef = shallowRef(initialOptions.data)
	watch(
	dataRef,
	() => {
	table.setState(prev => ({
	...prev,
	data: dataRef.value,
	}))
	},
	{ immediate: true }
	)
	}

But instead of tracking each individual property:

const dataRef = shallowRef(initialOptions.data)
watch(() => ...);

... we should probably make the entire options-object reactive (while still tracking the data separately for performance reasons), so something like this:

const optionsRef = ref(initialOptions.value)
watch(optionsRef, () => table.setState(...), { deep: true });


const dataRef = shallowRef(initialOptions.value.data)
watch(dataRef, () => table.setState(...));

You would also have to make some changes to the types:

export function useVueTable<TData extends RowData>(
  initialOptions: MaybeRef<TableOptions<TData>>
) {

I have not had the time yet to look at all this, but let me know if you want me to review a pull request 😄

[randName]

As for the slots, I am not sure if that should be a part of TanStack Table. The library is a headless library, so basing columns on slots is kind of wrong in my opinion. However, it could be provided as an example in the docs 😄

yes, I had implemented it outside of the adapter (basically just swap out the <FlexRender>s for <slot>s), so having it as a docs example sounds good (and can work now)

I don't mind helping out on the adapter*, but after playing around with it my biggest concern now is observing readonly values from the table instance, e.g. I cannot make a reactive pageCount without explicitly linking it to the data.length and pageSize values. will there be room for an API surface for those in the new major? I see that usage of signals in the other adapters (like Angular and Qwik) is also pretty limited

*also ultimately my own use case is limited to filter/sort/paginate and slightly hampered(?) by being server side (so I have to control a lot of state myself anyway), so I will have to pass if the effort to shoehorn one reactivity system into another is much greater than just writing something natively