What is the best way to set a value for a generic-typed ref?

Question

What is the best way to set a value for a generic-typed ref?

I've been working on a Vue composable using TypeScript that utilizes a generic type T and accepts a single parameter path, ultimately returning a reference to a document.

While I have made progress, I keep encountering an error when trying to set a value to the document ref:

Type '{ id: string; }' is not assignable to type 'T'.
  'T' could be instantiated with an arbitrary type which could be unrelated to '{ id: string; }'.ts(2322)

Below is a condensed version of the composable code:

import { ref, Ref } from "vue";
import { projectFirestore } from "@/firebase/config";
import { doc, onSnapshot } from "firebase/firestore";

const getDocument = <T>(
  path: string
): {
  document: Ref<T | null>;
} => {
  const document = ref(null) as Ref<T | null>;
  const docRef = doc(projectFirestore, path);
  onSnapshot(docRef, (doc) => {
    document.value = { //<-- Error here on "document.value"
      ...doc.data(),
      id: doc.id,
    };
  });
  return { document };
};

export default getDocument;

Despite experimenting with various assignments to document.value such as strings or {} objects, I continue to receive similar errors indicating incompatibility with type T.

I recognize that the issue lies in TypeScript's uncertainty regarding type T's compatibility with other types. Is there a way to inform TypeScript that type T can indeed work with these various types?

typescript vue.js

Answer 1

Answer №1

T is specifically designated for the return type in this scenario. The generic declaration indicates that the resulting Ref can be any type chosen by the caller as T, without any restrictions or constraints.

Even if you were to define T extends { id: string } or set your return type as T & { id: string }—possible using appropriate syntax—you would still encounter challenges with TypeScript's strong typing since, at runtime, it's impossible for getDocument to determine enough information about T to ensure compatibility between doc.data() and the inferred T from the getDocument call.

Here are three possible alternatives:

Remove the generic and have a return type of Ref<{id: string} | null>, ensuring type safety but necessitating the use of ref["key"] notation for checking unknown keys.
Maintain the generic and rely on calls to getDocument to specify the correct type, assuming that errors introduced in your code are more likely than Firestore returning an unexpected data type. Using as any would be necessary to indicate to TypeScript that you are intentionally sacrificing type safety when assigning document.value.
Implement a type predicate to pass into getDocument alongside the path. This predicate, a function taking one argument and indicating whether its arg is T, can be checked within onSnapshot to confirm that your document can safely be cast to T or handle failures accordingly. Additionally, this approach confines T to prevent arbitrary types in your generic. See example below.

const getDocument = <T>(
  path: string,
  docPredicate: (doc: any) => doc is T,  // accept predicate
): {
  document: Ref<T & {id: string} | null>;
} => {
  const document = ref(null) as Ref<T & {id: string} | null>;
  const docRef = doc(projectFirestore, path);
  onSnapshot(docRef, (doc) => {
    const data = doc.data(); // extract to local variable
    if(docPredicate(data)) { // convince TS data is type T
      document.value = {
        ...data,             // integrate as expected
        id: doc.id,
      };
    }
  });
  return { document };
};

interface Foo { a: string, b: number }
function isFoo(doc: any): doc is Foo {
  // TODO: check that doc has {a: string, b: number}
  return true;
}

const fooDoc = getDocument("bar", isFoo);
if (fooDoc.document.value) {
  console.log(fooDoc.document.value.a);
  console.log(fooDoc.document.value.id);
}

Playground before => Playground after

Answer 2

T is specifically designated for the return type in this scenario. The generic declaration indicates that the resulting Ref can be any type chosen by the caller as T, without any restrictions or constraints.

Even if you were to define T extends { id: string } or set your return type as T & { id: string }—possible using appropriate syntax—you would still encounter challenges with TypeScript's strong typing since, at runtime, it's impossible for getDocument to determine enough information about T to ensure compatibility between doc.data() and the inferred T from the getDocument call.

Here are three possible alternatives:

Remove the generic and have a return type of Ref<{id: string} | null>, ensuring type safety but necessitating the use of ref["key"] notation for checking unknown keys.
Maintain the generic and rely on calls to getDocument to specify the correct type, assuming that errors introduced in your code are more likely than Firestore returning an unexpected data type. Using as any would be necessary to indicate to TypeScript that you are intentionally sacrificing type safety when assigning document.value.
Implement a type predicate to pass into getDocument alongside the path. This predicate, a function taking one argument and indicating whether its arg is T, can be checked within onSnapshot to confirm that your document can safely be cast to T or handle failures accordingly. Additionally, this approach confines T to prevent arbitrary types in your generic. See example below.

const getDocument = <T>(
  path: string,
  docPredicate: (doc: any) => doc is T,  // accept predicate
): {
  document: Ref<T & {id: string} | null>;
} => {
  const document = ref(null) as Ref<T & {id: string} | null>;
  const docRef = doc(projectFirestore, path);
  onSnapshot(docRef, (doc) => {
    const data = doc.data(); // extract to local variable
    if(docPredicate(data)) { // convince TS data is type T
      document.value = {
        ...data,             // integrate as expected
        id: doc.id,
      };
    }
  });
  return { document };
};

interface Foo { a: string, b: number }
function isFoo(doc: any): doc is Foo {
  // TODO: check that doc has {a: string, b: number}
  return true;
}

const fooDoc = getDocument("bar", isFoo);
if (fooDoc.document.value) {
  console.log(fooDoc.document.value.a);
  console.log(fooDoc.document.value.id);
}

Playground before => Playground after

Answer 3

Answer №2

After some exploration, I stumbled upon a different approach.

By leveraging the DocumentData interface provided by Firebase, I decided to incorporate it in both the document reference and return type.

This choice enabled me to eliminate the need for the generic T altogether.

The result is a more streamlined and straightforward function that does not require custom interfaces to be created and passed in. This successfully resolves the issues within this composable and eliminates errors in the Vue SFC template when utilized.

Below is the complete code snippet:

import { ref, Ref } from "vue";
import { projectFirestore } from "@/firebase/config";
import {
  doc,
  onSnapshot,
  DocumentSnapshot,
  DocumentData,
} from "firebase/firestore";

const getDocument = (
  path: string
): {
  document: Ref<DocumentData | null>;
} => {
  const document = ref<DocumentData | null>(null);
  const docRef = doc(projectFirestore, path);
  onSnapshot(docRef, (doc: DocumentSnapshot<DocumentData>) => {
    if (doc.data()) {
      document.value = {
        ...doc.data(),
        id: doc.id,
      };
    }
  });
  return { document };
};

export default getDocument;

Answer 4

After some exploration, I stumbled upon a different approach.

By leveraging the DocumentData interface provided by Firebase, I decided to incorporate it in both the document reference and return type.

This choice enabled me to eliminate the need for the generic T altogether.

The result is a more streamlined and straightforward function that does not require custom interfaces to be created and passed in. This successfully resolves the issues within this composable and eliminates errors in the Vue SFC template when utilized.

Below is the complete code snippet:

import { ref, Ref } from "vue";
import { projectFirestore } from "@/firebase/config";
import {
  doc,
  onSnapshot,
  DocumentSnapshot,
  DocumentData,
} from "firebase/firestore";

const getDocument = (
  path: string
): {
  document: Ref<DocumentData | null>;
} => {
  const document = ref<DocumentData | null>(null);
  const docRef = doc(projectFirestore, path);
  onSnapshot(docRef, (doc: DocumentSnapshot<DocumentData>) => {
    if (doc.data()) {
      document.value = {
        ...doc.data(),
        id: doc.id,
      };
    }
  });
  return { document };
};

export default getDocument;

What is the best way to set a value for a generic-typed ref?

Answer №1

Answer №2

Similar questions

Unlock the potential of Vue custom props within the asyncData function in your nuxtjs project!

How can I arrange a specific array position in Vuejs according to the Id value?

Guide to utilizing Terser in conjunction with webpack

Having issues with Vue js increment operator not yielding the desired results

Code error TS1005 indicates that an ampersand is expected

Vue 3 app encountering error due to element having an 'any' type implicitly

Issues encountered while attempting to utilize the delete function within a CRUD process involving Angular 8, Laravel, and JWT authentication

The state array is rejecting the value from the other array, resulting in null data being returned

Can you explain how to specify individual keys in an object literal in TypeScript?

How to Publish an Angular 8 Application on Github Pages using ngh

What is the proper way to input a Response object retrieved from a fetch request?

Working with e.charcode in TypeScript allows for easy access to

Arrays nested in Laravel validator responses

Determining the length and angle of a shadow using X and Y coordinates

Tips for utilizing method overload in TypeScript with a basic object?

Display images in a list with a gradual fade effect as they load in Vue.js

Utilize an array of observables with the zip and read function

Rounded Doughnut Chart using Vue3 and vue-chart-3 for visually appealing data representation

Unable to generate paths in Ionic 3

Identify when a div reaches the end of the screen using CSS