Fix for Typescript warnings for type ‘any’ with Cloud Functions for Firebase - node.js

I’m getting a number of warnings all relating to the use of ‘any’ as a return type for functions in my Typscript code. I am trying to write a node.js backend with Cloud Functions for Firebase, to manage Google Play Billing purchases and subscriptions.
I am following the examples given in the Classy Taxi Server example here:
https://github.com/android/play-billing-samples/tree/main/ClassyTaxiServer
For example, the following:
function purchaseToFirestoreObject(purchase: Purchase, skuType: SkuType): any {
const fObj: any = {};
Object.assign(fObj, purchase);
fObj.formOfPayment = GOOGLE_PLAY_FORM_OF_PAYMENT;
fObj.skuType = skuType;
return fObj;
}
Gives the warning
Unexpected any. Specify a different type. #typescript-eslint/no-explicit-any)
I have tried to change ‘any’ to ‘unknown’, but then I get an error
Property 'formOfPayment' does not exist on type 'unknown'.ts(2339)
and
Property 'skuType' does not exist on type 'unknown'.ts(2339)
In another function
export function mergePurchaseWithFirestorePurchaseRecord(purchase: Purchase, firestoreObject: any) {
// Copy all keys that exist in Firestore but not in Purchase object, to the Purchase object (ex. userID)
Object.keys(firestoreObject).map(key => {
// Skip the internal key-value pairs assigned by convertToFirestorePurchaseRecord()
if ((purchase[key] === undefined) && (FIRESTORE_OBJECT_INTERNAL_KEYS.indexOf(key) === -1)) {
purchase[key] = firestoreObject[key];
}
});
}
I get the following warnings
Missing return type on function. #typescript-eslint/explicit-module-boundary-types
Argument 'firestoreObject' should be typed with a non-any type. #typescript-eslint/explicit-module-boundary-types
Unexpected any. Specify a different type. #typescript-eslint/no-explicit-any
In this function, if I change ‘any’ to ‘unknown’, I still get a warning for
Missing return type on function.
In another example I get an error for the use of ‘any’ in this constructor:
export default class PurchaseManager {
constructor(private purchasesDbRef: CollectionReference, private playDeveloperApiClient: any) { }
And again the warning is
Argument 'playDeveloperApiClient' should be typed with a non-any type. #typescript-eslint/explicit-module-boundary-types
In this case, if I follow the suggestion to use ‘unknown’ instead of ‘any’, then I get an error for ‘purchases’ in the following function:
const apiResponse = await new Promise((resolve, reject) => {
this.playDeveloperApiClient.purchases.products.get({
packageName: packageName,
productId: sku,
token: purchaseToken,
}, (err, result) => {
if (err) {
reject(this.convertPlayAPIErrorToLibraryError(err));
} else {
resolve(result.data);
}
})
});
The error created by changing ‘any’ to ‘unknown’ in the constructor is:
Property 'purchases' does not exist on type 'unknown'.ts(2339)
If I understand correctly, I could prevent all of these (and other similar) warnings without creating errors, by disabling explicit-module-boundary-types, and/or no-explicit-any for the entire file, but I am not sure if this is bad practice?
Is there another (better) way to specify the return types to avoid using ‘any’?
Or is it fine to just go ahead and disable explicit-module-boundary-types or no-explicit-any?

If you do not want to use any, you will have to declare an interface for your type and set that as the return type of the function.
You can do something like:
interface MyType {
formOfPayment: string;
skyType: SkyType;
foo: //<any other pre-existing type>;
}
Then you can use this as the return type of any other function that requires you to return an object with above properties. e.g.
function purchaseToFirestoreObject(purchase: Purchase, skuType: SkuType): MyType {
const fObj: any = {};
Object.assign(fObj, purchase);
fObj.formOfPayment = GOOGLE_PLAY_FORM_OF_PAYMENT;
fObj.skuType = skuType;
return fObj;
}

Related

How to read properties in typescript after using Object.defineProperty?

I have the following code on typescript playground and a few questions come up that I am not sure how to get working
class PathInfo {
functionName: string;
httpPath: string;
httpMethod: string;
constructor(functionName: string, httpPath: string, httpMethod: string) {
this.functionName = functionName;
this.httpPath = httpPath;
this.httpMethod = httpMethod;
}
toString(): string {
return "PathInfo["+this.functionName+","+this.httpPath+","+this.httpMethod+"]";
}
}
class AuthRequest {}
class AuthResponse {}
class LoginRequest {}
class LoginResponse {}
const path: any = (thePath: string, type: any) => {
return (target: Function, memberName: string, propertyDescriptor: PropertyDescriptor) => {
const pathMeta = new PathInfo(memberName, path, type);
Object.defineProperty(target, memberName+'pathInfo', {
value: pathMeta,
writable: false
});
//How do I access the stored pathMeta
//console.log("target="+target.pathInfo);
console.log("member="+memberName);
console.log("props="+propertyDescriptor);
}
}
class AuthApiImpl {
#path("/authenticate", AuthResponse)
authenticate(request: AuthRequest): Promise<AuthResponse> {
throw new Error("all this is generated by factory.createApiImpl");
}
#path("/login", LoginResponse)
login(request: LoginRequest): Promise<LoginResponse> {
throw new Error("all this is generated by factory.createApiImpl");
}
};
function printMethods(obj: any) {
console.log("starting to print methods");
for (var id in obj) {
console.log("id="+id);
try {
//How do I access the stored pathMeta here FOR EACH METHOD ->
//console.log("target="+target.pathInfo);
if (typeof(obj[id]) == "function") {
console.log(id+":"+obj[id].toString());
}
} catch (err) {
console.log(id + ": inaccessible"+err);
}
}
}
console.log("starting to run")
const temp = new AuthApiImpl();
printMethods(temp);
console.log("done")
line 64-65, how to read the property that I set
line 40-41, how to read the property that I set
line 58-74, why is this not printing any functions? I want to print all functions and I do NOT want to print properties (just functions)
line 33, Can I access the class name at this point?
line 35, I thought target was a function and would be authorize, then login, BUT if I define the property as JUST 'pathInfo', I get an error that the property is already defined on the target(This implies the target is the class not the function?). I am so confused.
Terribly sorry as I try to focus on a single question, but this one test of writing decorators has given me more questions than answers as I delve into the typescript world.
How can I tweak the code to play more here?
A goal here is as developers define the APIs of other microservices, I can capture a bunch of meta information and store it SOMEWHERE I can use later in startup code. I do not care where I store that really, but just need a clean way of knowing the class I want to extend, the methods, the return types, the http path, etc.
How to get methods of a class
You still can't grab the method names even if you remove the decorator. This isn't a TypeScript specific question.
You need to get the properties of the prototype, not just the object itself.
function printMethods(obj: any) {
console.log("starting to print methods");
const objProto = Object.getPrototypeOf(obj);
console.log(Object.getOwnPropertyNames(objProto));
}
How to access class names
Don't think this is possible with decorators at the moment, but it should be straightforward to just pass in your class name as a string.
Similar issue: TypeScript class decorator get class name
Open issue on GitHub: https://github.com/microsoft/TypeScript/issues/1579
"property is already defined on the target"
Notice if you run the code above you get the following in console.log:
["constructor", "authenticate", "login", "authenticatepathInfo", "loginpathInfo"]
I also want to point out that if you don't even initialize an instance of the class, you'll still get the same error.
I want to read this meta data in nodejs and use that to dynamically create a client implementing the api. Basically, developers never have to write clients and only write the api and the implementation is generated for them.
If I were to do that, I'd probably not use decorators, but mapped types:
// library code
interface ApiMethodInfo {
httpPath: string;
httpMethod: string;
}
type ApiInfo<S extends object> = Record<keyof S, ApiMethodInfo>;
type Client<S extends object> = {[key in keyof S]: S[key] extends (req: infer Req) => infer Res ? (req: Req) => Promise<Res> : never};
function generateClient<S extends object>(apiInfo: ApiInfo<S>): Client<S> {
const client = {} as Client<S>;
for (const key in apiInfo) {
const info = apiInfo[key as keyof S];
client[key] = ((param: any) => invokeApi(info, param)) as any;
}
return client;
}
// application code
interface AuthRequest {}
interface AuthResponse {}
interface LoginRequest {
username: string,
password: string,
}
interface LoginResponse {}
interface MyServer {
authenticate(request: AuthRequest): AuthResponse;
login(request: LoginRequest): LoginResponse;
}
const myApiInfo: ApiInfo<MyServer> = { // compiler verifies that all methods of MyServer are described here
authenticate: {
httpPath: '/authenticate',
httpMethod: 'POST'
},
login: {
httpPath: '/login',
httpMethod: 'POST'
}
}
const myClient = generateClient(myApiInfo); // compiler derives the method signatures from the server implementation
const username = "joe";
const password = "secret";
const response = myClient.login({username, password}); // ... and can therefore check that this call is properly typed
(To understand how these type definitions work, you may want to read the section Creating Types from Types in the TypeScript Handbook)
The weakness of this approach is that while the compiler can derive the client signatures from the server signatures, it will not copy any JSDoc, so client devs can not easily access the API documentation.
In the above code, I chose to specify the metadata in a separate object rather than decorators so the compiler can check exhaustiveness (decorators are always optional; the compiler can not be instructed to require their presence), and because decorators are an experimental language feature that may still change in future releases of the language.
It is entirely possible to populate such a metadata object using decorators if that's what you prefer. Here's what that would look like:
// library code
interface ApiMethodInfo {
httpPath: string;
httpMethod: string;
}
const apiMethodInfo = Symbol("apiMethodInfo");
function api(info: ApiMethodInfo) {
return function (target: any, propertyKey: string) {
target[apiMethodInfo] = target[apiMethodInfo] || {};
target[apiMethodInfo][propertyKey] = info;
}
}
type ApiInfo<S extends object> = Record<keyof S, ApiMethodInfo>;
type Client<S extends object> = {[key in keyof S]: S[key] extends (req: infer Req) => infer Res ? (req: Req) => Promise<Res> : never};
function invokeApi(info: ApiMethodInfo, param: any) {
console.log(info, param);
}
function generateClient<S extends object>(serverClass: new() => S): Client<S> {
const infos = serverClass.prototype[apiMethodInfo]; // a decorator's target is the constructor function's prototype
const client = {} as Client<S>;
for (const key in infos) { // won't encounter apiMethodInfo because Symbol properties are not enumerable
const info = infos[key];
client[key as keyof S] = ((param: any) => invokeApi(info, param)) as any;
}
return client;
}
// application code
interface AuthRequest {}
interface AuthResponse {}
interface LoginRequest {
username: string,
password: string,
}
interface LoginResponse {}
class MyServer {
#api({
httpPath: '/authenticate',
httpMethod: 'POST'
})
authenticate(request: AuthRequest): AuthResponse {
throw new Error("Not implemented yet");
}
#api({
httpPath: '/login',
httpMethod: 'POST'
})
login(request: LoginRequest): LoginResponse {
throw new Error("Not implemented yet");
}
}
const myClient = generateClient(MyServer); // compiler derives the method signatures from the server implementation
const username = "joe";
const password = "secret";
const response = myClient.login({username, password}); // ... and can therefore check that this call is properly typed
Notice how using a Symbol prevents name collisions, and ensures that other code doesn't see this property (unless they look for that particular Symbol), and therefore can not be tripped up by its unexpected presence.
Also notice how MyServer, at runtime, contains the constructor of the class, whose prototype holds the declared instance methods, and it being passed as target to any decorators thereof.
General Advice
May I conclude with some advice for the recovering Java programmer? ;-)
EcmaScript is not Java. While the syntax may look similar, EcmaScript has many useful features Java does not, which often allow writing far less code. For instance, if you need a DTO, it is wholly unnecessary to declare a class with a constructor manually copying each parameter into a property. You can simply declare an interface instead, and create the object using an object literal. I recommend looking through the Modern JavaScript Tutorial to familiarize yourself with these useful language features.
Also, some features behave differently in EcmaScript. In particular, the distinction between class and interface is quite different: Classes are for inheriting methods from a prototype, interfaces for passing data around. It's quite nonsensical to declare a class for a Response that will be deserialized from JSON, because prototypes don't survive serialization.

interfaces in typescript: use function parameter on a nested object reference

I have this object model:
export interface UpdateDocument {
updated_at?: string;
actions?: Actions;
}
export interface Actions {
update?: Update;
create?: Create;
}
export interface Update {
name?: Values;
priority?: Values;
engine?: Values;
fact?: Fact;
}
export interface Fact {
brand?: Values;
model?: Values;
version?: Values;
year?: Values;
km?: Values;
color?: Values;
}
export interface Values {
old?: any;
new?: any;
}
export interface Create {
conditions?: Object;
recipe?: Object;
}
In this function i tried to pass a parameter to references an objects field and do an assignment:
async buildUpdateDocument (updateDocument: UpdateDocument) {
let fields: Array<string> = ['name','priority','engine','fact','adjustment'];
fields.forEach((field: string) =>{
updateDocument.actions!.update![field]!.old = await this.getValue(field)
})
}
but i hav this ts-error: Element implicitly has an 'any' type because expression of type 'string' can't be used to index type 'Update'.
No index signature with a parameter of type 'string' was found on type 'Update'.ts(7053)
How can i pass the parameter in this kind of reference to do the assignment?
First of you have specified a wrong key adjustment that doesn't exist on Update. This example uses a explicit type (as const):
let fields = ['name','priority','engine','fact'] as const;
Make sure to not add a type definition to the variable when using as const.
Here is the modified function to better fit TS standards. This also addresses the forEach-async problem in the original code. The real correct structure would be null checks for each of the x | undefined types, but to override the type errors the following is the way to go.
async function buildUpdateDocument (updateDocument: UpdateDocument) {
const fields: Array<keyof Update> = ['name','priority','engine','fact'];
await Promise.all(fields.map(async (field) => {
(((updateDocument.actions as {update: Update}).update)[field] as Values).old = await this.getValue(field);
}));
}
Your current code has bugs that the type system would help you find if you let it. First, the adjustment field doesn't exist on the Update type, and old field doesn't exist on the Fact type.
To implement this properly, I would use a Record for the data type instead:
const updateFields = ['name', 'priority', 'engine', 'fact'] as const
export type UpdateFields = typeof updateFields[number]
export type Update = Record<UpdateFields, Values>
And then, your function will look like this:
async buildUpdateDocument (updateDocument: UpdateDocument) {
updateFields.forEach((field) =>{
updateDocument.actions!.update![field]!.old = await this.getValue(field)
})
}

Creating a cross-sdk wrapper for Firebase (Firestore, Cloud Storage, and more)

I'm currently trying to find an abstraction that can allow me to run Firebase products (mainly Firestore, Storage, and Analytics) regardless of the platform (React Native, React, Node.js). I have looked at the REST API but would like to use the SDKs for all the features that they offer.
// web
import firebase from 'firebase';
type WebFirestore = ReturnType<typeof firebase.firestore>;
// cloud
import * as admin from 'firebase-admin';
type CloudFirestore = ReturnType<typeof admin.firestore>;
// native
import { FirebaseFirestoreTypes } from '#react-native-firebase/firestore';
type NativeFirestore = FirebaseFirestoreTypes.Module;
const API = (firestore: WebFirestore | CloudFirestore | NativeFirestore) => {
firestore
.collection('foo')
.doc('foo')
.get()
.then((resp) => true);
}
I'm trying to create a TypeScript type that can enable me to do the same (at least that's what I think). The API, on the outset, is kept consistent across platforms for these products but my guess is that the return types are different. By that I mean, I can run this function on all platforms as long as the firestore object belongs to the SDK on that platform.
I was thinking of creating a class that takes a flag ('web', 'cloud', 'native') and then also take the firestore object in the constructor. I tried running the code below but TypeScript says the following:
(property) Promise<T>.then: (<TResult1 = FirebaseFirestore.DocumentSnapshot<FirebaseFirestore.DocumentData>, TResult2 = never>(onfulfilled?: (value: FirebaseFirestore.DocumentSnapshot<FirebaseFirestore.DocumentData>) => TResult1 | PromiseLike<...>, onrejected?: (reason: any) => TResult2 | PromiseLike<...>) => Promise<...>) | (<TResult1 = firebase.firestore.DocumentSnapshot<...>, TResult2 = never>(onfulfilled?: (value: firebase.firestore.DocumentSnapshot<...>) => TResult1 | PromiseLike<...>, onrejected?: (reason: any) => TResult2 | PromiseLike<...>) => Promise<...>) | (<TResult1 = FirebaseFirestoreTypes.DocumentSnapshot<...>, TResult2 = never>(onfulfilled?: (value: FirebaseFirestoreTypes.DocumentSnapshot<...>) => TResult1 | PromiseLike<...>, onrejected?: (reason: any) => TResult2 | PromiseLike<...>) => Promise<...>)
Attaches callbacks for the resolution and/or rejection of the Promise.
#param onfulfilled — The callback to execute when the Promise is resolved.
#param onrejected — The callback to execute when the Promise is rejected.
#returns — A Promise for the completion of which ever callback is executed.
This expression is not callable.
Each member of the union type '(<TResult1 = DocumentSnapshot<DocumentData>, TResult2 = never>(onfulfilled?: (value: DocumentSnapshot<DocumentData>) => TResult1 | PromiseLike<...>, onrejected?: (reason: any) => TResult2 | PromiseLike<...>) => Promise<...>) | (<TResult1 = DocumentSnapshot<...>, TResult2 = never>(onfulfilled?: (value: DocumentSnapsh...' has signatures, but none of those signatures are compatible with each other.ts(2349)
I'm rather new to TypeScript and was wondering if there is a way to make this work. All the types individually work but their union doesn't work. Is there a better way to think about this layer of abstraction in TypeScript? I intend to host this on the Github package registry and all the products to have access to the internal API as functions that are currently - firestore, cloud storage, cloud functions, some REST API calls.
Switching based on string flag is almost never the "right" way. You want to replace if conditions with a level of abstraction.
Adapter Pattern
You might want to read up on the Adapter Pattern, which is a generalized OOP approach to this sort of situation. Instead of one class with type property, you would have a separate wrapper class for each type of store instance. These classes would all have the same public API interface SharedFirestore, but internally they could call different methods on their this.firestore to get the results. When you want to use a firestore, you would just require the type SharedFirestore and you would know that you could interact with it the same regardless of which store type it is.
That sort of setup looks like:
interface SharedFirestore {
getDoc( collectionPath: string, documentPath: string ): Document;
}
class WebFirestore implements SharedFirestore {
private firestore: firebase.firestore.Firestore;
constructor( app?: firebase.app.App ) {
this.firestore = firebase.firestore(app);
}
getDoc( collectionPath: string, documentPath: string ): Document {
return this.firestore.collection(collectionPath).doc(documentPath);
}
}
class CloudFirestore implements SharedFirestore {
private firestore: FirebaseFirestore.Firestore;
constructor( app?: admin.app.App ) {
this.firestore = admin.firestore(app);
}
getDoc( collectionPath: string, documentPath: string ): Document {
return this.firestore.someOtherMethod( collectionPath, documentPath );
}
}
Typescript Generics
Wrapper classes are not necessary here because the three types already implement the same interface, kind of. They all allow you to get a document by calling firestore.collection(collectionPath).doc(documentPath).get(). This is purely a typescript issue which is caused by the differing return types.
web.collection('foo').doc('foo').get();
// type: firebase.firestore.DocumentSnapshot<firebase.firestore.DocumentData>
cloud.collection('foo').doc('foo').get();
// type: FirebaseFirestore.DocumentSnapshot<FirebaseFirestore.DocumentData>
native.collection('foo').doc('foo').get();
// type: FirebaseFirestoreTypes.DocumentSnapshot<FirebaseFirestoreTypes.DocumentData>
Your then callback is a function of the document, but you don't know which of the three types of document you have. So you cannot call a function on the union. Instead we need to say "whichever type of store I have, my callback will match that". To do that, we make the API a generic which depends on the store type.
We can use some conditional types to extract the associated types for the collection and the document from the store type.
interface BaseCollection<D> {
doc(path: string): D;
}
interface BaseStore<C extends BaseCollection<any>> {
collection(path: string): C;
}
type CollectionFromStore<S> = S extends BaseStore<infer C> ? C : never;
type DocFromCollection<C> = C extends BaseCollection<infer D> ? D : never;
type DocFromStore<S> = DocFromCollection<CollectionFromStore<S>>
Here's a possible setup that uses generics to extend a base type rather than extending a union.
class FirebaseAPI <S extends BaseStore<any>> {
constructor( private firebase: S ) {}
getCollection( collectionPath: string ): CollectionFromStore<S> {
return this.firebase.collection(collectionPath);
}
getDoc( collectionPath: string, documentPath: string ): DocFromStore<S> {
return this.getCollection(collectionPath).doc(documentPath);
}
}
You can see how we get the appropriate return types.
(new FirebaseAPI(web)).getDoc('', '').get().then(v => {});
// v has type firebase.firestore.DocumentSnapshot<firebase.firestore.DocumentData>
(new FirebaseAPI(cloud)).getDoc('', '').get().then(v => {});
// v has type FirebaseFirestore.DocumentSnapshot<FirebaseFirestore.DocumentData>
(new FirebaseAPI(native)).getDoc('', '').get().then(v => {});
// v has type FirebaseFirestoreTypes.DocumentSnapshot<FirebaseFirestoreTypes.DocumentData>
Playground Link

Type Assertions not Working when Reading Firestore Data

I am trying to read a complex document from Firebase in order to do some calculations and then execute a Cloud Function.
Unfortunately, I am unable to read the data in the data types that I would like.
Here is an example:
interface CourseEvent {
coucourseGroupType: string;
date: FirebaseFirestore.Timestamp;
courseGroupTypeFirebaseId: string;
firebaseId: string;
maxParticipants: number;
participants: Participant[];
start: FirebaseFirestore.Timestamp;
waitingList: Participant[];
weekNumber: string;
}
This is where I am using the Cloud Function
import * as functions from "firebase-functions";
import { firestore, Timestamp, FieldValue } from "./setup";
export const registerCustomerFromWaitingList = functions.firestore
.document("CourseEvents/{courseEvent}")
.onUpdate(async (change, context) => {
const currentCourseEvent = change.after.data() as CourseEvent;
const currentMaxParticipants = currentCourseEvent.maxParticipants;
if (typeof currentMaxParticipants === "number") {
console.log(`currentMaxParticipants type is number`);
} else if (typeof currentMaxParticipants === "string") {
console.log(`currentMaxParticipants type is string`);
} else {
console.log(`currentMaxParticipants type is NOT number or string`);
}
}
The console always prints that the currentMaxParticipants is a string. I have a similar problem also with another interface.
I also have experimented with such code
const nu = change.after.data().maxParticipants as number;
But in the end, I am still getting a string.
Any tips?
I found out why I would get always a string for the currentMaxParticipants variable.
In Firestore I did save it as a string. I thought that by using type assertions I would also convert the value. In the end, I did change the value within Firestore to a number and now it is working.
I just read this here:
Essential TypeScript: From Beginner to Pro
CAUTION No type conversion is performed by a type assertion, which only tells the compiler what type it should apply to a value for the
purposes of type checking.

Typescript Array.filter empty return

Problem statement
I've got problem with an object array I would like to get a sub object array from based on a object property. But via the Array.filter(lambda{}) all I get is an empty list.
The object is like:
export interface objectType1 {
someName: number;
someOtherName: string;
}
export interface ObjectType2 {
name: string;
other: string;
ObjectType1: [];
}
The method to get the subArray is:
private getSubArray(toDivied: ObjectType2[], propertyValue: string){
let list: ObjectType2[] = toDivied.filter((row:ObjectType2) => {
row.name === propertyValue
});
return list;
}
Analys
Namely two things been done ensure filter comparing works and that the data is "as expected".
Brekepoints in visual studio code
Via break points in the return and filter compareison I've inspected that the property value exists (by conditions on the break point) and that the "list" which is returned is empty.
I would like to point out that I use a Typescript linter which usally gives warning for the wrong types and undefined variable calls and such so I am quite sure it shouldn't be an syntax problem.
Tested via javascript if it works in chrome console
remove braces inside callback function
private getSubArray(toDivied: ObjectType2[], propertyValue: string){
let list: ObjectType2[] = toDivied.filter((row:ObjectType2) =>
row.name === propertyValue
);
return list;
}

Resources