You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, while upgrading the Intercom SDK to version 6.0.0, I found it to be very useful. However, I noticed that the type definitions for some response fields could be improved. MPany API responses include fields that are currently typed as plain string but are actually constrained to a limited set of valid values. For example, the source.type field in retrieve a conversation typically returns values like 'conversation', 'email', 'facebook', 'instagram', 'phone_call', 'phone_switch', 'push', 'sms', 'twitter', and 'whatsapp'.
Proposed Enhancement:
I propose updating the type definitions across the library to leverage TypeScript string literals for fields with a fixed set of possible values. This change would ensure that fields representing specific categories or types use explicit string literal types rather than the generic string.
Benefits:
Improved Type Safety: This guarantees at compile time that only valid values can be assigned to fields with restricted sets, reducing potential runtime errors.
Enhanced Developer Experience: Developers benefit from better autocompletion, code documentation, and guidance in their IDEs, making it easier to work with the library.
Better Code Clarity: Clearly defined literal types make the code more self-descriptive and maintainable by documenting valid values directly in the types.
Implementation Considerations:
Given that the intercom-node types might be auto-generated—as suggested by comments such as:
/** * This file was auto-generated by Fern from our API Definition. */
It may require adjustments in the type generation process to incorporate string literals. I would appreciate guidance on how the generation pipeline could be adapted to include these improvements.
Feedback and Collaboration:
I am keen to contribute by helping with this enhancement. I would welcome any insights into how the types are being generated and any specific areas to focus on to effectively integrate these suggested changes.
The text was updated successfully, but these errors were encountered:
kang8
changed the title
Use String Literals for Fixed-Value Fields in API Responses
Use String Literals for Fixed-Value Fields in API Responses in 6.0.0
Dec 24, 2024
@kang8 thanks for writing this detailed issue and I agree with you typing as a literal instead of a string would be a better developer experience. Would you be open to making a pull request to the 2.11 OpenAPI spec here ?
Description:
Today, while upgrading the Intercom SDK to version 6.0.0, I found it to be very useful. However, I noticed that the type definitions for some response fields could be improved. MPany API responses include fields that are currently typed as plain string but are actually constrained to a limited set of valid values. For example, the source.type field in retrieve a conversation typically returns values like 'conversation', 'email', 'facebook', 'instagram', 'phone_call', 'phone_switch', 'push', 'sms', 'twitter', and 'whatsapp'.
Proposed Enhancement:
I propose updating the type definitions across the library to leverage TypeScript string literals for fields with a fixed set of possible values. This change would ensure that fields representing specific categories or types use explicit string literal types rather than the generic string.
Benefits:
Implementation Considerations:
Given that the intercom-node types might be auto-generated—as suggested by comments such as:
It may require adjustments in the type generation process to incorporate string literals. I would appreciate guidance on how the generation pipeline could be adapted to include these improvements.
Feedback and Collaboration:
I am keen to contribute by helping with this enhancement. I would welcome any insights into how the types are being generated and any specific areas to focus on to effectively integrate these suggested changes.
The text was updated successfully, but these errors were encountered: