Add revision draft support (single revision mode)#405
Conversation
| if (this.containerApp.revisionsMode === KnownActiveRevisionsMode.Single) { | ||
| return !!this.containerApp.template?.scale && !isDeepEqual(this.containerApp.template.scale, scaleDraftTemplate); | ||
| } else { | ||
| // We only care about showing changes to descendants of the revision draft item when in multiple revisions mode |
There was a problem hiding this comment.
This else code segment will be introduced in the multiple revisions PR, commented out for now with a return placeholder
| }; | ||
| } | ||
|
|
||
| getChildren(): TreeElementBase[] { |
There was a problem hiding this comment.
This being the same as the ContainerAppItem kind of makes me want this class to be extended from or based off of a an abstract ContainerAppItemBase. I think it'll be kind of annoying when we change/add children or the container app item itself.
There was a problem hiding this comment.
Yeah, technically you'd probably have the ContainerAppItem, the RevisionItem, and the RevisionDraftItem all extend from this then. I'm open to some base class that has maybe a private method that you would call within getChildren to obtain the shared children.
There was a problem hiding this comment.
Actually, instead of enforcing inheritance for this, how do you feel about providing the children through a static method on the RevisionItem. That feels simpler to me and we can still manage the children in one place. It also could make sense to keep it on that item because the template changes are analogous to the concept of revisions anyway.
| getChildren(): TreeElementBase[] { | ||
| let scale: Scale | undefined; | ||
|
|
||
| if (this.hasUnsavedChanges()) { |
There was a problem hiding this comment.
Don't need it now, but maybe just a side-note. Anytime we have an item that is part of the "batch changes", we could have a base model for it that has the same implementation for how to get the value/children and check for unsavedChanges, etc.
There was a problem hiding this comment.
Yeah, I totally get what you mean, I was thinking about doing something like this eventually as well further down the line when we have a better vision for how all the batch revision work will tie together.
I'm not sure if I prefer extending from a base here or just implementing an interface (leaning towards the latter). If we ever decide we want to implement discard changes on the item level, that would also be a good candidate to include as well.
bff2eff to
2fed691
Compare
|
Just a heads up, I think this is ready for review again! |
116d22f to
0b07f91
Compare
babd790 to
242b6ad
Compare
| "containerApps.createContainerApp": "Create Container App...", | ||
| "containerApps.deployImage": "Update Container App Image......", | ||
| "containerApps.editContainerApp": "Edit Container App (Advanced)", | ||
| "containerApps.deployImage": "Update Container App Image...", |
There was a problem hiding this comment.
I'm wondering if we should call this: "Update Container..." or "Edit Container..." after our conversation offline. The image is just a part of the overall container, after all.
It's annoying and confusing, but Container =/= Container App.
There was a problem hiding this comment.
Yeah it's 😵💫
…inerapps into mwf/revision-draft-alt-2
Background:
Based on team feedback surrounding the initial revision draft PR (v1), here is the new and improved v2! Major changes include:
scaleItem("Scaling")Purpose:
What is covered in this PR:
What is coming down the line:
Demo of the full feature:
I had to include a little bit of the multiple revisions mode code (for example,
RevisionDraftItem) because of some loose coupling, but overall I tried to split it up so it's a little bit less code to review overall.If you see missing command spots in the
package.json, you can see here for what the full thing will eventually look like: a58ee13