-
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
construct: consider renaming "parent" to "scope" #1431
Comments
@awslabs/aws-cdk-team what do you guys think? |
Doesn't change much to me, but "scope" is fewer characters than "parent" so I'm all for it. |
ha! I am aware that this might seem superficial, but I truly believe that by offering a slightly different mental model for users, this API will be more intuitive and will be less confusing. I believe people will feel less inclined to look for things like "addChild", etc. I think this should be coupled with a change of messaging to stop talking about "construct trees" and refer to "construct scopes". |
Seems like @rix0rrr likes this as well 👍 |
- Rename "parent" to "scope" in all construct initializers and imports (fixes #1431) - Group all members (besides `validate`) under a `node` property so they don't pollute the surface area of derived classes (fixes #1441) - Define `IConstruct` and have all `IXxx` extend it - Normalize construct ID to `id` across the board (fixes #189) BREAKING CHANGE: Multiple breaking changes: - All the APIs of `cdk.Construct` are now available under `construct.node` (e.g. instead of `construct.path` use `construct.node.path`. See #1441 for details. - Construct `parent` was renamed to `scope`. See #1431 for more details. - First argument of `codepipeline.CrossRegionScaffoldStack` is now required. - `IPipeline.uniqueId` removed and can now be accessed via `pipeline.node.uniqueId`.
I am wondering if maybe some of the confusion and non-intuitiveness around the construct tree can be relieved by modifying the semantics ever so slightly so they will reflect more accurately the reason behind the first constructor argument. Perhaps instead of calling it "parent" (which represents the in-memory data structure) we should call it "scope" (which more accurately represents the motivation behind the model).
I have a feeling that by calling the first argument "scope", it would be more natural for users to pass in "this", indicating that this object is created within this scope.
Another benefit of this is that it will reduce the temptation to overlay other tree models (e.g. route53, step functions, pipelines) onto the construct hierarchy, since the mental model would not align so cleanly.
The underlying mechanisms will be exactly the same.
The text was updated successfully, but these errors were encountered: