Repository navigation
Schema$Userinfo interface returns optional values #3151
Copy link
Copy link
Closed
Labels
priority: p2Moderately-important priority. Fix may not be included in next release.Moderately-important priority. Fix may not be included in next release.type: questionRequest for information or clarification. Not an issue.Request for information or clarification. Not an issue.
Description
Environment details
- OS: MacOS
- Node.js version: 16.15.0
- npm version: 8.19.2
googleapisversion: ^110.0.0
Steps to reproduce
- Check
Schema$Userinfointerface (fromoauth2.userinfo.get()) - Confirm the exported interface properties are all optional
export interface Schema$Userinfo {
/**
* The user's email address.
*/
email?: string | null;
/**
* The user's last name.
*/
family_name?: string | null;
/**
* The user's gender.
*/
gender?: string | null;
/**
* The user's first name.
*/
given_name?: string | null;
/**
* The hosted domain e.g. example.com if the user is Google apps user.
*/
hd?: string | null;
/**
* The obfuscated ID of the user.
*/
id?: string | null;
/**
* URL of the profile page.
*/
link?: string | null;
/**
* The user's preferred locale.
*/
locale?: string | null;
/**
* The user's full name.
*/
name?: string | null;
/**
* URL of the user's picture image.
*/
picture?: string | null;
/**
* Boolean flag which is true if the email address is verified. Always verified because we only return the user's primary email address.
*/
verified_email?: boolean | null;
}This is causing some inefficiencies with our code. As a result of these all being optional, we have to first check if these values are defined in order to avoid TS errors.
- It's forcing us to make assumptions about what might and might not be optional, like so:
const { data } = await oauth2.userinfo.get();
if (!data.id || !data.email || !data.name) {
// are these ever ACTUALLY going to be undefined or null? If not, this is useless logic to satisfy TS errors.
throw new Error("Missing data from google account");
}
new GoogleAccount<IGoogleAccount>({
id: data.id,
email: data.email,
name: data.name
});This could cause some unintended errors in the case that we are wrong with assuming a certain property will always be present.
- If we change our database schema to reflect potentially optional or null values for these properties that aren't truly optional or null, we'd then have to enforce a check anywhere we want to use them:
const googleAccount = await GoogleAccount.findOne({ id: someId });
if (googleAccount.id) {
const someData = getSomeDataByGoogleAccountId(googleAccount.id)
}As a result of this, I'd like to request advice on how to mitigate these issues as a result of the typescript interface definitions.
- Are all of these properties truly optional or null? Is there ever a response in which
idwon't be defined withinSchema$Userinfo? - If some of these properties are not truly optional or null, I'd like to petition there be an effort to correct the TS interface definition.
Reacted by Shlomo
Metadata
Metadata
Assignees
Labels
priority: p2Moderately-important priority. Fix may not be included in next release.Moderately-important priority. Fix may not be included in next release.type: questionRequest for information or clarification. Not an issue.Request for information or clarification. Not an issue.
Activity
bcoe commentedon Feb 1, 2023
This library is automatically generated from the API definition here:
https://github.com/googleapis/google-api-nodejs-client/blob/main/discovery/oauth2-v2.json
I do not believe all fields are guaranteed to be preset for all APIs, e.g.,
family_nameforUserinfo. However, there's no distinction in the API definition between fields that will always be present, and those that may be omitted in the response.Even though it's slightly annoying, I think your best bet when using these generated API surfaces is defensive programming with the response object (as you're doing).
CoolTechYT commentedon Feb 2, 2023
@bcoe to your knowledge do you believe that at least
idandemailwill always be present?