Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
fix(stepfunctions): improve Task payload encoding #2706
fix(stepfunctions): improve Task payload encoding #2706
Changes from 1 commit
f196130
b8ac1bd
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
This file was deleted.
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps a single required property of a union-like class instead of two optionals with runtime check?
[That seems like a repeating pattern between
string
andMap<string => any>
. Maybe we can have a standard type for this?]There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered it, but I think it will be worse in the typical case. I'm expecting JSON object to be the common scenario and I'd hate to made that even harder to pass.
By the way, you're making the exact opposite argument in #2716. Which is it? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that this is not ideal, but The problem here is that it is a required argument, and having two optional arguments that are mutually exclusive results in poor IDE experience and we don’t have union types.
Makes me wonder if perhaps we can implement automatic support for union types in Jsii so that we can use unions in typescript and other languages will be able to generate union-like classes....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeeessss!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would solve so much.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would you do it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did it for consistency with Event Targets. That does mean we now have this abomination:
Guess there's no getting around it... :x
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only issue is how to automatically come up with a name for the union type. Anonymous won't be possible and any automatic mechanism will not be backwards compatible. Don't know if we get enough information from the TypeScript compiler, otherwise we could maybe force type unions to only be allowed if they're declared first:
Then we can generate:
As an optimization, if the union type occurs in a props type for which we're already generating a builder, we could generate builder overloads like we do now:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, we will need to have an official name for the union type and also come up with a way to render the names of the various methods in case the union includes primitives/lists/maps...