Passing a query to useCollection gives warning "could not get path of the data source"

[Soviut]

Reproduction

coming soon

Steps to reproduce the bug

1. Install vuefire@3.1.0
2. Run the following code

<script setup lang="ts">
const q = query(getCol('companies'), orderBy('createdAt', 'desc'))
const { data: companies, pending } = useCollection(q)
</script>

<template>
  <p v-if="!pending && companies.length === 0">No companies yet</p>
  <div v-for="company in companies" :key="company.id">{{ company.name }}</div>
</template>

3. Observe that pending resolves early causing any templates that depend on it to flash momentarily before being replaced with data.
4. Observe that the data loads and is ordered correctly.
5. Check the logs for [VueFire SSR]: Could not get the path of the data source

Expected behavior

I would expect that passing a query to useCollection would behave the same as passing a raw collection.

• pending would resolve when fully complete to avoid flashing any template fragments that depend on it
• there would be no warning
• data would load correctly

Actual behavior

• pending resolves early, flashing "no companies yet" fragment before replacing with data
• throws a warning in the console
• data loads correctly from query, in correct order

Additional information

I set a breakpoint in the source. Here's the result in Chrome Dev Tools with some of the local context showing.

[posva]

For queries, you need to pass an ssrKey to the options of useCollection(): https://vuefire.vuejs.org/guide/ssr.html#manual-ssr-keys

[Soviut]

@posva I suppose it doesn't matter that I'm not using SSR?

[posva]

Not yet 😄

vuefire/src/ssr/plugin.ts

Lines 42 to 47 in 66f42ed

	} else {
	// TODO: warn if in SSR context in other contexts than vite
	if (process.env.NODE_ENV !== 'production' /* && import.meta.env?.SSR */) {
	console.warn('[VueFire SSR]: Could not get the path of the data source')
	}
	}

[davidstackio]

I'm also not using SSR (ssr: false in Nuxt config) and get this SSR related warning. Ideally, if no SSR is being used, there wouldn't be any warning related to it.

[BenJackGill]

+1 here. I am also seeing this warning and not using SSR at all. Using latest VueFire 3.1.13 version.

[MarkSonn]

does anyone know what the ssrKey actually is? can it just be a random value or is there somewhere specific to get it?

[posva]

it must be a unique key across your application

[ChrisRoss5]

I'm not using SSR and I need to get rid of this warning. Please fix this.

[Soviut]

I'm not using SSR and I need to get rid of this warning. Please fix this.

Demanding a maintainer fix something like this is not a good way to encourage them.

First, you should explain exactly why you need to get rid of the warning, because usually warnings don't affect anything.

Second, you can already get rid of the warnings based on the links to documentation above. For example https://vuefire.vuejs.org/guide/ssr.html#Manual-SSR-keys explains that you can manually set an SSR key. This will make it go away

useCollection(queryRef, { ssrKey: 'my-quiz' })

Finally, consider sponsoring Posva so that he can reach his sponsorship goal and work on his open source projects full time. https://github.com/sponsors/posva

[ChrisRoss5]

I wish there was a better way. Thanks for help.

[tlserver]

How about adding more details to the warning message? The current warning, [VueFire SSR]: Could not get the path of the data source, is somewhat misleading.

1. Many responses to this issue indicate that they are not using SSR, so the prefix [VueFire SSR] can be confusing.
2. The message does not mention the ssrKey option. If providing an ssrKey is the preferred method of resolution, it might be helpful to include this in the warning.
3. It would also be beneficial to reference documentation or an FAQ, such as https://vuefire.vuejs.org/guide/ssr.html#Manual-SSR-keys, directly in the warning message.

[BenJackGill]

From what I can gather they plan to fix this by hiding the message for those not using SSR. The fix just hasn't been released yet. Maybe creating a PR would be helpful for the repo owner.

Adding the ssrKey is a workaround until the fix is released.

[tewshi]

still experienced this, had to use @BenJackGill 's fix

[tewshi]

hopefully it is resolved here #1564