RFC 201: Refactoring support

[rix0rrr]

This is a request for comments about refactoring support. See #201 for additional details.

APIs are signed off by @RomainMuller.

Rendered Link

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[royby-cyberark]

I was just wondering about this and tried to ask in discussions (https://github.com/aws/aws-cdk/discussions/22016) and I suggested a way of side stepping the entire logical ids issues when refactoring.

My suggestion was to avoid using construct classes (avoid inheriting Construct) and instead arrange your code with regular classes which takes the scope of the stack/parent construct and use this as the scope for all child resources.

Pros:

• No logical id changes when refactoring
• get all the value of refactoring and code encapsulation

Cons:

• You lose the CloudFormation hierarchy which comes out of the box
  • you no longer get the ids of the parent concatenated
  • you can't see the nice hierarchy in CloudFormatoin new Tree view which is really nice (also other tools that might do the same things for visualization)

Let me expand on this a bit - i'm not suggesting to have everything as a flat stack, but do something which i'll call "top level domain structuring" in which i'll create top level constructs in which it is highly unlikely for things to move between such top level constructs. and in them, I will avoid using construct, lose the internal hierarchy but be able to refactor the code without issues.

What do you think about this approach? do you think it goes against the "spirit" of cdk/cloudformation, or does it seem like a legitimate approach?

Thank you.

[humanzz]

How different is this from renaming logical ids? Is the difference that relocating can happen at some intermediate construct level therefore might save multiple logical Id renames?

[jonodrew]

Was this ever merged?