Skip to content

Conversation

@hiranya911
Copy link
Contributor

Using the new AuthorizedHttpClient implementation in the FCM code.

This is a follow up of #280 and #291.

Also introducing the isJson field to the HTTP response interface, to make it easier to handle JSON-formatted responses.

error: response,
statusCode: 200,
});
if (!response.isJson) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be better to create a property or method to determine whether the response is valid, something like isValid() or valid.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed to contentJson and added some documentation. Didn't feel like naming this just json, since that seems to imply this returns a json object. wdyt?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On seconds thoughts I renamed it back to isJson() and made it a method as you suggested. That feels like a better name for what this does.

);
}

get isJson(): boolean {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you need a method to check if a response is valid, I think it is better to give it another name. isValid(). or something like that. Also a isSomething() should be a method. If you need a property for this, call it something like valid.
Note JSCore style guide:
Avoid using the 'is' prefix for boolean properties unless it's unclear from context that the property is a boolean.

Copy link
Contributor Author

@hiranya911 hiranya911 Jul 18, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a matter of validity. It's about whether the response is json or not. We have endpoints (e.g. Metadata server), where the valid response is plain text. It also seems at least some of our backend endpoints return html error messages. So we need a way to easily differentiate between json and non-json responses, so the client code can handle them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants