Ideally this function would be

protected addChoice(choice: ChoiceTransition) {
  this.choices.push(choice);
}

but I guess we can't change the function signature now

I wonder if we can do this to help make this function signature stable if we ever add more props to ChoiceTransition:

interface ChoiceTransition extends ChoiceTransitionOptions {
  condition;
  next;
}

interface ChoiceTransitionOptions {
  comment?;
}

protected addChoice(condition: Condition, next: State, options: ChoiceTransitionOptions) {}

This has 2 benefits:

• using the function would look like

choice.when(sfn.Condition.stringEquals('$.color', 'BLUE'), handleBlueItem, {
  comment: 'blue item comment',
});

which imo makes it clear that we're providing a comment.

• if we add an additional prop to ChoiceTransition in the future, like default or something, we can easily add it to ChoiceTransitionOptions

@msambol what was the reason for naming this IChoiceTransitionOptions? I assume you ran into some linter rule that yelled at you? Want to find out because I don't think it makes sense here, and we should exempt this from that rule if thats the case

@kaizencc Yep, I got:

aws-cdk-lib:     The declaring class is introduced here
aws-cdk-lib: aws-stepfunctions/lib/states/state.ts:503:3 - error JSII3008: The "comment" property of struct "aws-cdk-lib.aws_stepfunctions.ChoiceTransitionOptions" must be "readonly". Rename "aws-cdk-lib.aws_stepfunctions.ChoiceTransitionOptions" to "IChoiceTransitionOptions" if it is meant to be a behavioral interface.

@kaizencc From what I'm reading there isn't a way to silence JSII errors? Hmm..

does this fix the JSII error maybe?

@jogold It did. Good shout, Jonathan. I was following the pattern of state and condition but there is no reason this can't be readonly.