Add editEnvironmentVariableName command
#796
Conversation
| { | ||
| "command": "containerApps.editEnvironmentVariableName", | ||
| "when": "view =~ /(azureResourceGroups|azureFocusView)/ && viewItem =~ /environmentVariableItem/i", | ||
| "group": "1@1" |
There was a problem hiding this comment.
I think technically this should be 1@2
There was a problem hiding this comment.
I think 1@1 is correct, but it's confusing because the one above it is environmentVariablesItem with an s and they look super similar 😆
| import { type EnvironmentVariablesBaseContext } from "../EnvironmentVariablesContext"; | ||
| import { type EnvironmentVariableType } from "../addEnvironmentVariable/EnvironmentVariableTypeListStep"; | ||
|
|
||
| export interface EnvironmentVariableEditBaseContext extends EnvironmentVariablesBaseContext, Pick<ISecretContext, 'secretName'> { |
There was a problem hiding this comment.
Seems to be very similar to the EnvironmentVariableAddBaseContext. Any reason to make a new one?
There was a problem hiding this comment.
Yeah you're right, they are super similar. To simplify a bit, I extended from the add context and just made the environmentVariable required because it's needed up front for the edits. I think I still prefer to keep a separate context just because I'm trying to keep the two command paths decoupled for the most part (mostly because I don't want to complicate the draft step with both add and edit logic).
| import { RevisionDraftUpdateBaseStep } from "../../revisionDraft/RevisionDraftUpdateBaseStep"; | ||
| import { type EnvironmentVariableEditContext } from "./EnvironmentVariableEditContext"; | ||
|
|
||
| export class EnvironmentVariableEditDraftStep<T extends EnvironmentVariableEditContext> extends RevisionDraftUpdateBaseStep<T> { |
There was a problem hiding this comment.
It's not a huge deal, but I feel like this step could almost entirely be consolidated with the "AddStep".
But if you like having them separate just for organization/logical purposes, makes sense to me too.
There was a problem hiding this comment.
Yeah, although there are a lot of overlaps, there's enough differences that I'd prefer to leave them uncoupled to reduce complexity if we ever need to come back and alter the behavior.
No description provided.