Questions about using @next useDocument useCollection

[naranjamecanica]

First of all, thanks for taking the time to update the project in @next. I'm trying to implement the @next version in a new project (Vue 3 & Pinia) I'm starting and I have the following questions:

1. Is there a way to unbind a useDocument manually? For example when a user logs out and I want to unload his bound documents in different Pinia stores?

2. If I want to bind a different document/collection using useDocument or useCollection the same state Ref in Pinia, do I need to unsubscribe the previous or should this be handled automatically?

I'm getting to following error right now when applying useDocument twice on the same state Ref in Pinia:

index.ts:99 Uncaught (in promise) TypeError: Cannot redefine property: error
    at Function.defineProperties (<anonymous>)
    at _useFirestoreRef (index.ts:99:10)
    at useDocument (index.ts:189:10)
    at index.ts:107:22
    at callWithErrorHandling (runtime-core.esm-bundler.js:155:22)
    at callWithAsyncErrorHandling (runtime-core.esm-bundler.js:164:21)
    at job (runtime-core.esm-bundler.js:1789:17)
    at callWithErrorHandling (runtime-core.esm-bundler.js:155:36)
    at flushJobs (runtime-core.esm-bundler.js:388:17)

Thanks again! 👍🏻

ps I'm using the latest source, not latest release

[posva]

Thanks for the feedback!

1. Yes, you can call unbind() (const { data, unbind } = useDocument()) which is probably going to be renamed to stop() or something else
2. It should be handled automatically by passing a ref (or shallow ref or computed) to useDocument() (same with collection):

const currentDocSource = computed(() => doc(db, route.params.id))
const currentDoc = useDocument(currentDocSource)

This makes me think I should support passing null | undefined to allow declarative unbinding: when currentDocSource.value is undefined or null, it will just unbind without binding a new doc

[naranjamecanica]

Thanks for the fast response!

You mean currentDocSource, right? So if this computed value is null | undefined it will unbind until its giving back a DocumentReference again.

[posva]

yes! It's not implemented yet though, although I should be able to add it quickly. But you can already pass a Ref of a DocumentReference, it doesn't handle the nullish value yet

[posva]

Hey @naranjamecanica what is the use case behind having to manually unbind to bind later on to a new data source? Since the subscriptions are automatically removed when the component unmounts, I was wondering if allowing null to the ref of the Data source makes sense or if it would make more sense to allow calling a function like unbind() but let the watcher of the ref still active so it automatically subscribes to a new data source

[naranjamecanica]

Is this also the case when using them inside a Pinia store? Manual unbind could be sensible when the application state changes and syncing of a certain collection is not necessary anymore for the current state. Or I'm I missing someting?

An example for the automatic unbinding would be a Firebase user who logs in and I need to sync his/her details from a Firestore document. I could manually keep track of an unbind method but it would be nice if my store does not get polluted with extra variables to keep track of.

A Pinia store example (stripped down, without error handling, etc) for keeping track of user state:

import { useFirebaseAuth, useFirestore } from '@/firebase';
import { onAuthStateChanged, signInWithEmailAndPassword, signOut, type User } from 'firebase/auth';
import { doc, QueryDocumentSnapshot, type DocumentData, type SnapshotOptions } from 'firebase/firestore';
import { defineStore } from 'pinia';
import { computed, ref, type Ref } from 'vue';
import { useDocument } from 'vuefire';

interface UserInfo {
  uid: string;
  name: string;
  email: string;
}

const UserInfoConverter = {
  toFirestore(info: UserInfo): DocumentData {
    return info;
  },
  fromFirestore(snapshot: QueryDocumentSnapshot, options: SnapshotOptions): UserInfo {
    const data = snapshot.data(options)!;
    return {
      name: data.name ?? '',
      email: data.email ?? '',
      uid: data.uid ?? '',
    };
  },
};

export const useAccountStore = defineStore('account', () => {
  const db = useFirestore();
  const auth = useFirebaseAuth();

  // STATE
  const info: Ref<UserInfo | null> = ref(null);

  // GETTERS
  const isLoggedIn = computed(() => info.value !== null);

  // ACTIONS
  async function login(username: string, password: string) {
    await signInWithEmailAndPassword(auth, username, password);
  }

  async function logout() {
    await signOut(auth);
  }

  // Firebase Auth
  const user: Ref<User | null> = ref(null);
  onAuthStateChanged(auth, (authUser) => {
    user.value = authUser;
  });

  // VueFire binding
  const userInfoDocRef = computed(() => {
    const userId = user.value?.uid;

    if (userId) {
      return doc(db, 'users', userId).withConverter(UserInfoConverter);
    } else {
      return null;
    }
  });

  useDocument(userInfoDocRef, { target: info });

  return {
    // STATE
    info,

    // GETTERS
    isLoggedIn,

    // ACTIONS
    login,
    logout,
  };
});

[posva]

No, it just works 🙂 . Inside a pinia store, there is an effectScope that groups all of the composoable and reactivity API called inside.

Thanks for the background, this helps. I think it makes sense to support null | undefined as a value for the data source

[ottopaulsen]

Can I have a followup question on this one?
I am having the same issue as described and solved here, but with a collection.
The code above helped me a bit on the way, but not all the way.
Here is part of my code in a Pinia store (together with Nuxt 3 and VueFire):

  const { isAuthenticated } = toRefs(useUserStore());
  const farmSource = computed(() => (isAuthenticated.value ? collection(db, "farms") : null));
  const farms = ref<Farm[] | null>(null);
  useCollection(farmSource, { target: farms });

The isAuthenticated is working fine both on login and logout, and the computed is being evaluated in both cases.
However, the farms collection is only updated on login, not on logout. After a logout, the isAuthenticated is false, but the farms collection still holds the values it had before logout.

So I am wondering if this is correctly implemented for collection, and if so, what can I do to get my farms updated (cleared) also on logout.

[ridernet]

I think you need to declare them first as {} or null on login. this way it will overrite the docs. This is a good step on swift/ios (that's my expertise) in order to clean the local/cached data.