-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Expose props as read/write properties in CFN resources and remove propertyOverrides #2100
Expose props as read/write properties in CFN resources and remove propertyOverrides #2100
Comments
We could say "overrides!" but in that case it looks like: cfnrole.propertyOverrides.roleName = 'MyPrefix-' + cfnrole.properties.roleName Which I agree is slightly better, but super non-obvious. Also if |
Is this yet another version of an escape hatch? |
The proposal is to expose all top-level L1 props as simple read/write properties of the construct (note that deep structs will still be readonly, but that should be fine). So for example: class interface CfnBucketProps {
// ...
readonly corsConfiguration?: CorsConfigurationProperty;
readonly bucketEncryption?: BucketEncryptionProperty;
// ...
}
export class CfnBucket {
// ...
public corsConfiguration?: CorsConfigurationProperty;
public bucketEncryption?: BucketEncryptionProperty;
// ...
} Also, remove Then, in @moofish32 might pick this up. Discussed with @rix0rrr and @RomainMuller |
A little note - we hope 🤞 that this does not conflict with attribute property names because they begin with the type name (e.g. bucketArn) |
We could also code generate an It'd maintain the namespace-like encapsulation that prevents name collisions from being a problem, and retain the strong typed overrides. It may need a JSII feature to support objects with an index signature. |
I am not sure it's worth the effort, and the developer experience is less attractive: bucket.corsConfiguration = { boom! }; versus: bucket.props.corsConfiguration = { bam! }; I doubt we'll ever have conflicts and if we do, and we can should implement this logic to mangle the property name if there's an attribute with exactly the same name (e.g. add something like a "Config" postfix). At any rate, if this will happen, it will be a very fringy edge case. |
Just to verify I'm thinking in line with the team a starting point might be:
|
Yep, that's about it what we were thinking as well. |
I'm digging in here, the code needs a little unwinding. Hopefully I'll have something in a couple of days. |
…aws#2372) fixes aws#2100 Modify the generation of CFN resources to create Class members for each CloudFormation Property. This removes the need for the property override solution implemented previously. CloudFormation Resource attributes are now prefixed with `attr` instead of resource name. The RefKind patches are removed. All L2 resources have been updated to consume the new attribute names. The Ref attributes are removed and the new `refAsString` is used. Added tagging support for AppSync, AppMesh, StepFunctions. Token now supports `number` types, so the generated code no longer treats number as non-tokenizable. BREAKING CHANGE: All L1 (CFN) Resources have attributes prefixed with `attr`. For example, in S3 `bucket.bucketArn` is now `bucket.attrArn`. The property overrides for typed properties has been removed, instead users can now directly access CloudFormation properties on the class.
…aws#2372) Modify the generation of CFN resources to create Class members for each CloudFormation Property. This removes the need for the property override solution implemented previously. CloudFormation Resource attributes are now prefixed with `attr` instead of resource name. The RefKind patches are removed. All L2 resources have been updated to consume the new attribute names. The Ref attributes are removed and the new `refAsString` is used. Added tagging support for AppSync, AppMesh, StepFunctions. Token now supports `number` types, so the generated code no longer treats number as non-tokenizable. BREAKING CHANGE: All L1 (CFN) Resources have attributes prefixed with `attr`. For example, in S3 `bucket.bucketArn` is now `bucket.attrArn`. The property overrides for typed properties has been removed, instead users can now directly access CloudFormation properties on the class. Fixes aws#2100
Perfectly reasonable application of aspects came up on Gitter:
To enable this we would need to allow read/write access to the configured properties of a
CfnResource
, in a typed fashion (so it needs to be done incfn2ts
).We need to think about types and JSII though.
A
RoleProps
struct will havereadonly
properties for evertyhing, so cannot be mutated. So the syntax will have to be something like:Not great...
Same story across JSII, except in Javaland it will be even more annoying to copy the existing properties into a new builder object. We need to generate a "copy constructor" as well then.
The text was updated successfully, but these errors were encountered: