How to "chain" a subcollection with useCollection and target?

[davidstackio]

I have a Firestore collection called Locations. It has a subcollection called Periods. I'm using Nuxt (no SSR) with Pinia.

The Locations store is correctly subscribing to the corresponding collection when using useCollection with a computed source: it's showing up in Vue Dev Tools as a filled array. However, the Periods one does not subscribe to the collection or get populated. It also uses useCollection and a computed source. The source is based off the Locations collection.

My source function uses a variation of the computed property contactSource logic from the docs:

const contactSource = computed(() =>
  doc(collection(db, 'contacts'), route.params.id)
)
// contact will always be in sync with the data source
const contact = useDocument(contactSource)

Note: I'm also using the target option.

So I'm wondering if it's because in order to populate the Periods store collection, it needs the collection information from Locations (hence the "chain" in the title).

BUT, the source is being computed correctly - just the collection is not.

What am I missing?

---

Here is the logic:

LocationStore.ts

Everything works as expected here.

export const useLocationStore = defineStore("LocationStore", () => {
  // Auth related
  const currentUser = useCurrentUser();

  const locationsColRef = computed(() => {
    if (currentUser.value) {
      return collection(db, "users", currentUser.value.uid, "locations");
    }
  });
  const locationsQuery = computed(() => {
    if (locationsColRef.value) {
      return query(locationsColRef.value, orderBy("expiration", "desc"));
    }
  });
  const locationsCol = ref<LocationDoc[]>([]);
  useCollection<LocationDoc>(locationsQuery.value, {
    target: locationsCol,
  });

// Get default location. If not found, use the first one.
  const defaultLocation = computed(() =>
    getDefaultLocation(locationsCol.value)
  );

function reset() {
    locationsCol.value = [];
  }

return { locationsCol, locationsColRef, defaultLocation, reset };

PeriodStore.ts

periodsColRef and periodsQuery are being computed correctly, but periodsCol is not.

export const usePeriodStore = defineStore("PeriodStore", () => {
  // Auth related
  const currentUser = useCurrentUser();

  // Connect to location store
  const locationStore = useLocationStore();
  const defaultLocation = computed(() => locationStore.defaultLocation);

  const periodsColRef = computed(() => {
    if (currentUser.value && defaultLocation.value) {
      return collection(
        db,
        "users",
        currentUser.value.uid,
        "locations",
        defaultLocation.value.id,
        "periods"
      );
    }
  });
  const periodsQuery = computed(() => {
    if (periodsColRef.value) {
      return query(periodsColRef.value, orderBy("lastUpdated", "desc"));
    }
  });



  // THIS IS WHAT IS NOT POPULATING
  const periodsCol = ref<PeriodDoc[]>([]);
  useCollection<PeriodDoc>(periodsQuery.value, {
    target: periodsCol,
  });

  // Get default period. If not found, use the first one.
  const defaultPeriod = computed(() => getDefaultPeriod(periodsCol.value));

  function reset() {
    periodsCol.value = [];
  }

  return { periodsCol, periodsColRef, defaultPeriod, reset };
});

[posva]

I think you might be interested in #153

[davidstackio]

Thanks, for that, but I'm doing two queries already (in two separate Pinia stores - one for each collection).

The more I've dug into this, I'm wondering if there's an issue somewhere with using the VueFire composables within Pinia. I was running into strange behavior when using them in Pinia (the issue in this discussion being one of them). Because I just needed it to work and didn't have time to debug, I have removed the VueFire composables from my Pinia store altogether and am using the Firebase native onSnapshot instead. The composables are easy/work great in single file components, but either there's something I'm missing about Pinia stores or a hard to trace bug somewhere.

I call this function in a navigation guard prior to authenticated page load and it is all working as expected.

store.ts

function fill() {
  // Only fetch data if store is empty
  if (!activityCol.value.length && activityQuery.value) {
    // TODO: add error handling try/catch
    onSnapshot(activityQuery.value, (querySnapshot) => {
      const docs: Array<ActivityDoc> = [];
      querySnapshot.forEach((doc) => {
        const item = { id: doc.id, ...doc.data() } as ActivityDoc;
        docs.push(item);
      });
      activityCol.value = docs;
    });
  }
}

middleware.ts

// Fill activity store
const activityStore = useActivityStore();
activityStore.fill();

[posva]

maybe there is a problem with pinia stores. If you have a code sample with the problem I could give it a look

[davidstackio]

@posva I tried so many different variations of the code that each had different problems, that I'm not sure what would be helpful to share at this point, but I've included one below that should help.

For reference, here are the issues I was seeing when using useDocument / useCollection in a Pinia store:

1. Subcollection stores that rely on documents from their parent collection as part of their path wouldn't get populated, even though the collectionRef got correctly populated (this discussion).
2. After a device was sitting idle (usually a phone, though not always), the useCollectioned state in the store would be empty. The only way to fix it was to refresh the page. (as described here Automatic unbinding after idle? #1428)
3. When a user (auth) and Firestore doc was first created (via a Firebase function), if that user added a document to a subcollection of their user doc, after it was initially added it would not sync in real time unless the page was refreshed. I think this had to do with the if (!activityCol.value.length) check I was doing in the fill() function, but I'm not sure why it wouldn't be syncing in real time. This is the one I'm least confident in attributing to VueFire since there was plenty of other logic at play. This is most likely related to the first issue I described above.

One final thing, I'm still using the useCurrentUser composable in Pinia without issue. The problem just seems to be around the collection/document maintaining real time updates with Firestore. Possibly around using the target logic.

---

locationStore.ts

This is the full file. There's a middleware that calls the fill() function on page load.

I'm wondering if the real time connection is broken with this line in the fill() function: locationsCol.value = docs;.

import { collection, query, orderBy, getDocs } from "firebase/firestore";

// Types
import type { LocationDoc } from "types/firebase";

export const useLocationStore = defineStore("LocationStore", () => {
  // Auth related
  const currentUser = useCurrentUser();

  const locationsColRef = computed(() => {
    if (currentUser.value) {
      return collection(db, "users", currentUser.value.uid, "locations");
    }
  });
  const locationsQuery = computed(() => {
    if (locationsColRef.value) {
      return query(locationsColRef.value, orderBy("expiration", "desc"));
    }
  });
  const locationsCol = ref<LocationDoc[]>([]);
  useCollection<LocationDoc>(locationsQuery.value, {
    target: locationsCol,
  });

  // Get default location. If not found, use the first one.
  const defaultLocation = computed(() =>
    getDefaultLocation(locationsCol.value)
  );

  async function fill() {
    // Only fetch data if store is empty
    if (!locationsCol.value.length && locationsQuery.value) {
      const docs: Array<LocationDoc> = [];

      // TODO: add error handling try/catch
      const colSnap = await getDocs(locationsQuery.value);
      colSnap.forEach((docSnap) => {
        const item = { id: docSnap.id, ...docSnap.data() } as LocationDoc;
        docs.push(item);
      });
      locationsCol.value = docs;
    }
  }

  function reset() {
    locationsCol.value = [];
  }

  return { locationsCol, locationsColRef, defaultLocation, fill, reset };
});

if (import.meta.hot) {
  import.meta.hot.accept(acceptHMRUpdate(useLocationStore, import.meta.hot));
}

[davidstackio]

Also, I keep getting this warning in the console, but I'm not using SSR. Not sure if it's related.

[VueFire SSR]: Could not get the path of the data source locationStore.ts:21

[Norfeldt]

Also, I keep getting this warning in the console, but I'm not using SSR. Not sure if it's related.

[VueFire SSR]: Could not get the path of the data source locationStore.ts:21

I found this useful regarding the SSR warning:

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

#1315 (comment)