Skip to content
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

Closed
eladb opened this issue Dec 26, 2018 · 4 comments · Fixed by #1444
Closed

construct: consider renaming "parent" to "scope" #1431

eladb opened this issue Dec 26, 2018 · 4 comments · Fixed by #1444
Labels
@aws-cdk/core Related to core CDK functionality

Comments

@eladb
Copy link
Contributor

eladb commented Dec 26, 2018

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.

@eladb
Copy link
Contributor Author

eladb commented Dec 26, 2018

@awslabs/aws-cdk-team what do you guys think?

@RomainMuller
Copy link
Contributor

Doesn't change much to me, but "scope" is fewer characters than "parent" so I'm all for it.

@eladb
Copy link
Contributor Author

eladb commented Dec 27, 2018

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".

@eladb
Copy link
Contributor Author

eladb commented Dec 27, 2018

Seems like @rix0rrr likes this as well 👍

@eladb eladb added the @aws-cdk/core Related to core CDK functionality label Dec 27, 2018
eladb pushed a commit that referenced this issue Jan 3, 2019
- 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`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/core Related to core CDK functionality
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants