[TS]`updateDoc` no longer reject excess member

[tylim88]

Operating System

window 11

Browser Version

Version 114.0.5735.199

Firebase SDK Version

10.0.0

Firebase SDK Product:

Firestore

Describe your project's tooling

Typescript

Describe the problem

updateDoc no longer reject excess member

firebase v9

firebase v10

Steps and code to reproduce issue

import {
  updateDoc,
  doc,
  getFirestore,
  DocumentReference
} from "firebase/firestore";

type abc = DocumentReference<{
  a: number;
  b: number;
  c: number;
}>;

export const test = () => {
  const docRef = doc(getFirestore(), "abc/efg") as abc;

  updateDoc(docRef, { a: 1, b: 2, c: 3, d: 4 });
};

tsconfig

{
  "compilerOptions": {
    "strict": true,
    "module": "commonjs",
    "jsx": "preserve",
    "esModuleInterop": true,
    "sourceMap": true,
    "allowJs": true,
    "lib": [
      "es6",
      "dom"
    ],
    "rootDir": "src",
    "moduleResolution": "node"
  }
}

[dconeybe]

Some of the TypeScript typings changed in v10 to actually fix a bug where updateDoc() was not checking the correct properties of objects (#7310). As a result, classes like DocumentReference now have two type parameters (instead of 1). The first type parameter is the type of object specified to functions like setDoc() and addDoc(). The second, new type parameter is the type specified to updateDoc(). As a result, if you want to use the same type for both you have to specify that object type as both type parameters.

So in your example above, you would need to change

type abc = DocumentReference<{
  a: number;
  b: number;
  c: number;
}>;

to

type abc = DocumentReference<{
  a: number;
  b: number;
  c: number;
}, {
  a: number;
  b: number;
  c: number;
}>;

Or perhaps consider factoring out the repeated definition to its own type, like this:

interface MyType {
  a: number;
  b: number;
  c: number;
}

type abc = DocumentReference<MyType, MyType>;

[dconeybe]

For some more background information, in v9 the type definition of DocumentReference was

class DocumentReference<
  T = DocumentData
>

In v10, the definition changed to

class DocumentReference<
  AppModelType = DocumentData,
  DbModelType extends DocumentData = DocumentData
>

For v10, I had considered this alternate definition of DocumentReference but it seemed to address some cases (like this one) but could break others:

class DocumentReference<
  AppModelType = DocumentData,
  DbModelType extends DocumentData = AppModelType extends DocumentData ? AppModelType : DocumentData
>

That is, the 2nd type parameter would default to the 1st type parameter, as long as the 1st type parameter conformed to the DocumentData interface; otherwise, it would just use plain DocumentData. To me this seemed somewhat counterintuitive because you get a different default 2nd type parameter depending on what type you use for the 1st type parameter. Ultimately, I chose DbModelType extends DocumentData = DocumentData to make the typings more predictable, at the cost of needing to specify the same type parameter twice in situations like this.

I'd be interested in your thoughts, though, since I'm quite interested in customers' experience with the new typings and would like to make them as robust and usable as possible.

[google-oss-bot]

Hey @tylim88. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Since there haven't been any recent updates here, I am going to close this issue.

@tylim88 if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.