docs(numbers): adding doc blocks

[manchuck]

Description

Motivation and Context

Testing Details

Example Output or Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[pardel]

Can we not complicate things like this? Code should be written to be easily readable rather than look smart. What is the benefit of adding transformers here? Why not just a simple inline mapping?

[manchuck]

This is done to normalize out responses and requests. Since our API's do not follow a consistent casing scheme (most use snake_case, some have kebab-case), we convert all responses to be camelCase for ease of use.

In the cases where kebab-case is used, a developer would have to access the object like resp.data['content-type] rather than resp.data.contentType.

Camel Case was chosen since the popular linter rules require camelCasing for variable names (Google, React, Airbnb)

Using the transformer instead of defining the mapping, alleviates the need to push updates when new variables are introduced and prevent keys from being improperly mapped through fat fingering. If the API gets an update, the user will be able to access the new data without waiting for a new release of the SDK. We do map the response in verifyv2 which is why there has to be work done to enable silent auth.

PS for users of Typescript, we export all the types in our packages to allow for this use case. If there is an update to the API they can simple merge of the types with the new propert(ies) added.