Best practise to ensure reactivity of prop values

[eneeio-nm]

We have a fairly large SaaS product, and it relies on a lot of props being used in components.

With the arrival of being able to destructure props I thought something like this would work:

const { thingId } = defineProps<{
  thingId: string
}>()

const enabled = computed (() => !!thingId)

const { data: thing, isLoading: isLoadingThing } = getThingQuery(thingId, { enabled })

However, it turns out that the query example won't rerun when thingId changes.

The way we've done this to date is:

const props = defineProps<{
  thingId: string
}>()

const thingId = computed(() => props.thingId)
const enabled = computed(() => !!thingId.value)

const { data: thing, isLoading: isLoadingThing } = getThingQuery(thingId, { enabled })

I've since come across examples where toRef is used, probably with prop destructuring, and I'm assuming an example of using toRef would look something like:

const { thingId } = defineProps<{
  thingId: string
}>()

const enabled = computed (() => !!thingId)

const { data: thing, isLoading: isLoadingThing } = getThingQuery(toRef(thingId), { enabled })

I'm eager to understand what is the best approach for handling this example?

Note

The query example used accepts a reactive value which is then passed to TanStack Query, which will rerun the query whenever the value changes.

[skirtles-code]

When using prop destructuring for thingId, the compiler will rewrite uses of thingId to props.thingId. If something wouldn't work with props.thingId then it won't work with props destructuring either.

For example, with code like this:

getThingQuery(thingId)

The compiler will rewrite it to something like this:

getThingQuery(props.thingId)

Importantly, that is passing the current value of props.thingId to getThingQuery. If that value changes later, getThingQuery won't know anything about it.

As you noted, you can use computed to get around this problem when using props explicitly:

const t = computed(() => props.thingId)
getThingQuery(t)

That's fine, but computed comes with some extra internal overhead that isn't really needed for reading a single property. Using toRef is slightly more lightweight:

// toRef with a function, similar to `computed`
const t = toRef(() => props.thingId)
getThingQuery(t)

Or alternatively:

// toRef with two arguments, passing the property name as a string
const t = toRef(props, 'thingId')
getThingQuery(t)

We actually don't need a ref at all, we could pass a getter function directly to getThingQuery instead:

getThingQuery(() => props.thingId)

In all cases, the key thing to appreciate is that it delays the reading of the property value. This gives getThingQuery the opportunity to choose when the value is read, and ensure it is read as part of a 'reactive effect' that will re-run when that value changes.

Back to destructuring props, you can also use a computed in that case:

const { thingId } = defineProps<{
  thingId: string
}>()

const t = computed(() => thingId)

getThingQuery(t)

This looks redundant, but remember that thingId is effectively equivalent to props.thingId, so by wrapping it with a computed like this it delays the reading of props.thingId.

Again, we could use toRef instead:

const { thingId } = defineProps<{
  thingId: string
}>()

const t = toRef(() => thingId)

getThingQuery(t)

As previously, it also isn't necessary to use computed or toRef, we could pass a getter function directly:

const { thingId } = defineProps<{
  thingId: string
}>()

getThingQuery(() => thingId)

getThingQuery will need to be implemented to handle whichever approach you choose. It looks like getThingQuery is intended to be a composable, and it would be perfectly normal for a composable to accept arguments like this. See:

• https://vuejs.org/guide/reusability/composables.html#input-arguments

The section I've linked is the one most directly relevant to your question, but I suggest reading the page from the top as there's some important context given elsewhere on the page and that section may not be as clear if you haven't read the rest of it.

To address one other point you raised, you suggested code like this for using toRef:

const { data: thing, isLoading: isLoadingThing } = getThingQuery(toRef(thingId), { enabled })

That won't really get you what you want. Writing toRef(thingId) is equivalent to toRef(props.thingId), so while it does create a ref, that ref will just contain the current value, it won't track any change to props.thingId. As I noted earlier, it'd need to be toRef(() => thingId) instead, using a function to defer the reading of the prop until the ref's value is accessed.

See also https://vuejs.org/guide/components/props.html#passing-destructured-props-into-functions, which mentions many of the same ideas that I've discussed here.

[eneeio-nm]

@skirtles-code Thank you for your informative breakdown - much appreciated. I'll read through the provided links to ensure my understanding is improved.