feat(cognito): user pool - required & custom attributes#6487
feat(cognito): user pool - required & custom attributes#6487mergify[bot] merged 8 commits intomasterfrom
Conversation
BREAKING CHANGE: `UserPoolAttribute` has been renamed to `StandardAttrs`.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
| * | ||
| * @default - No attributes are required. | ||
| */ | ||
| readonly requiredAttributes?: StandardAttribute[]; |
There was a problem hiding this comment.
Why not a boolean map?
requiredAttributes: {
email: true,
phone: true
}There was a problem hiding this comment.
I don't see much difference between having a boolean map vs. a list of enum here. Both provide pretty much a very similar experience.
The boolean map is quite handy when it comes to settings, such as "enable xxx" and there are some that default to true and some to false.
OTOH over here, we're asking the user to specify a set of fields that they want to make mandatory, and an array makes good sense.
Both have the same level of IDE autocomplete support.
Implementation wise - mapping each entry from a boolean map to the correct attribute name is another moving part that introduces human error.
I understand this needs to be designed from the customer experience and not from implementation complexity, but when the two experiences are close, it's worth considering this.
I'd prefer to leave this as a list of StandardAttribute. How strongly do you feel about having a boolean map here?
There was a problem hiding this comment.
Both have the same level of IDE autocomplete support.
I disagree that the ergonomics are equivalent. The IDE won’t expand the enum automatically and also will allow the user to specify each value multiple times which doesn’t make sense.
An array is not the “correct” data type here in my opinion, but I don’t think it’s critical!
There was a problem hiding this comment.
Fair enough. I've modified this per your suggestion.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
eladb
left a comment
There was a problem hiding this comment.
I am okay with leaving this with an array if you feel strongly about it.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Commit Message
feat(cognito): user pool - custom & mandatory standard attributes (#6487)
BREAKING CHANGE:
UserPoolAttributehas been removed. It is no longerrequired to defined a
UserPool.closes #1747
End Commit Message
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license