New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeScript: Many interfaces have optional members that don't match API docs #1553
Comments
Hi @sbking, The typescript definition files (and the API documentation) are generated from service models shared among the AWS SDKs. I'll pass your feedback on to the service team to see if the documentation could be made more clear. |
+1 Currently hitting issues trying to override
The version that only has the optional callback is not valid per the API docs. Trying to override this like so:
gives a compiler error like this:
|
I have additional feedback for the auto-generated type definitions. It is in the DynamoDB client which basically requires for all the requests a Is it ok to just put that information here or should I create an additional issue to separately keep track of the feedback? |
@anho Could you create a separate issue? That's something we can fix in the SDK, whereas the problem described by the OP would need to be addressed by the underlying AWS service. |
@ajmath Could you create a separate issue? We can update the SDK API documentation to call out the validity of only providing a callback when parameters have been bound to a service. |
More generally,
If the VPC wasn't created, the API will return an error. Hence, in practice it's impossible for This makes it a pain to use result properties, as each access requires validation that the "optional" property isn't
|
@jeskew Any update? This is making using the AWS SDK incredibly painful |
I have a similar problem - the error-first callback signatures indicate that all parameters are required, but they should all be optional, since the error is optional. |
Same pain here, optional is like no types at all. |
@jeskew It's a shame that that this issue seems to be ignored. It hugely devalues the type definitions if one is forced to do spurious |
Perhaps the TypeScript rewrite will put more focus on this. In the meantime I use |
Just wasted some time debugging some code that assumed the optional UnprocessedItems from DynamoDB DocumentClient response would be undefined. It's not just adding a !, it makes for a confusing API that basically requires you to "try it out" to see the return type before you write the code. Much like pure JS... |
AWS have provided a TS-native v3 SDK (https://aws.amazon.com/blogs/developer/first-class-typescript-support-in-modular-aws-sdk-for-javascript/) and still not fixed this! I end up using non-null assertions everywhere, which theoretically AWS can stop returning at any point and break my code :-( |
While working with the OpsWorks client in TypeScript, I noticed that a lot of interfaces in the TypeScript definitions have all optional members, but the API docs don't clarify if anything is optional or under what circumstances they would be undefined. For example, the
DescribeStacksResult
interface shows itsStacks
property as optional, and theStack
interface has all optional members:aws-sdk-js/clients/opsworks.d.ts
Line 1789 in f65c11d
aws-sdk-js/clients/opsworks.d.ts
Line 2789 in f65c11d
However, the API docs do not make it clear that these properties may be undefined, except for perhaps a few cases such as
VpcId
which says "applicable only if the stack is running in a VPC":http://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/OpsWorks.html#describeStacks-property
Could you clarify under what circumstances various members might be undefined?
I suppose I could create various type guard functions that allow me to cast API results to my own types to verify the properties I need are present. But it seems like the discrepancy between the API docs and the type definitions should be addressed somehow. If I were writing in JavaScript, I would have no idea that I need to validate every API result to ensure a property I need didn't come back undefined.
The text was updated successfully, but these errors were encountered: