-
Notifications
You must be signed in to change notification settings - Fork 136
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
Create from Deploy feature and some local UX changes #4130
Conversation
…ions into nat/createFromDeploy
@@ -0,0 +1,164 @@ | |||
/*--------------------------------------------------------------------------------------------- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is basically moving all the code from SubscriptionTreeItem. Please pay careful attention that I actually got everything-- small things have been changing with create here and there (flex, containerized, etc.)
@@ -24,6 +24,7 @@ | |||
"azureFunctions.deleteFunction": "Delete Function...", | |||
"azureFunctions.deleteFunctionApp": "Delete Function App...", | |||
"azureFunctions.deleteSlot": "Delete Slot...", | |||
"azureFunctions.deployProject": "Deploy to Azure...", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I think we originally went with "Deploy function to Azure..." but after more discussion, just went with a more generic "Deploy to Azure..."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't think we need to give more context to users on what they are deploying?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I mean you're in the workspace part of the extension so I think it's kind of clear. That being said, I think it still prompts you for a workspace folder.
I'm thinking of adding a right-click context item on the local project node though that also has "Deploy to Azure..." on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well I was thinking that they might need to know that the command is for deploying Functions to Azure and not App Service or anything else. But maybe they should already know?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, you click the Functions symbol to open the menu for the commands. I thought that was kind of the reason we had those buttons there to give them that context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, that's fine
return version; | ||
} | ||
|
||
async function createFunctionAppWizard(wizardContext: IFunctionAppWizardContext): Promise<{ promptSteps: AzureWizardPromptStep<IAppServiceWizardContext>[], executeSteps: AzureWizardExecuteStep<IAppServiceWizardContext>[] }> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't love that this function is returning a whole wizard object, but then only the prompt and execute steps on that object are used. I think the return type should be changed to reflect what is actually used.
Also it's a bit weird that this function also sets some wizard context, but I can't provide a better place to set it so 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't disagree with you, but this is logic that was pre-existing to this PR. I'm open to changing it, but I'd rather do it in a separate PR since I wanted to keep the core logic fundamentally the same.
src/commands/SubscriptionListStep.ts
Outdated
} | ||
} | ||
|
||
private async getPicks(_: IFuncDeployContext): Promise<IAzureQuickPickItem<AzureSubscription>[]> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason we didn't just remove the parameter if it's not being used?
const promptSteps = [new SubscriptionListStep(), new FunctionAppListStep()]; | ||
const title: string = l10n.t('Select Function App'); | ||
const wizard: AzureWizard<IAppServiceWizardContext> = new AzureWizard(context, { | ||
promptSteps, | ||
title | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer if you just put the promptSteps
and title
values inline here since they aren't used anywhere else.
|
||
await wizard.prompt(); | ||
|
||
node = context.site ? await ext.rgApi.tree.findTreeItem(nonNullProp(context.site, 'id'), context) : undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Find tree item is sort of sketchy to use. Have you tested this when the tree hasn't been loaded yet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it works though it's pretty unbearably slow. I may try to refactor this to just use the data model instead because of the performance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's pretty tough without some significant refactoring. We need to pass the tree ndoe to deploy because it does the whole temporary description thing on it. If the node isn't there or if the parent is undefined, it'll throw an error.
} | ||
}); | ||
|
||
qp.unshift({ label: '$(plus) Create new function app', description: '', data: undefined }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the empty description?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You see the description as half empty, but I see it as half full.
} | ||
|
||
public async getSubWizard(context: IFuncDeployContext): Promise<IWizardOptions<IFuncDeployContext> | undefined> { | ||
if (!context.site) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add a comment here. It seems like this the pivotal place where the code decides if we're creating a FA or not for deploy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: I would also like to suggest using a guard clause here to clean this up a bit more :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you clarify what you mean by using a guard clause here? I'm not really sure what I would be type guarding in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically invert it and add this guard at the beginning instead:
if (context.site) {
return undefined;
}
// Do the rest of your normal logic but now without the nesting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey guy, I already did that.
commandId: "azureFunctions.createNewProject", | ||
displayName: "Create Function Project", | ||
commandId: "azureFunctions.createFunction", | ||
displayName: "Create Function Locally", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you remember if there was a reason we couldn't do something like Create Function (Local)
? I vaguely recall a reason but can't really remember anymore
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if there was a reason or not, but personally if I see (Local), it makes me think that there is another version of Create Function. Probably Create Function (Remote) or something like that.
…ions into nat/createFromDeploy2
Whoo boy 🥵 |
This is basically this PR #4042 but I removed some of the UX changes regarding "Create function locally...".
I really didn't like having the prompt asking for what type of project does the user want to create. It doesn't really make sense to have it in our main entry point, so until we can think of a good solution, the command list looks like this:
Old:
New:
Create Function App...
option in the local workspace viewDeploy function to Azure...
which includes a+ Create new function app
option as a quick pick when we prompt for the appOther changes I probably should have made separate PRs for 😅:
Added
Create New Project...
to workspace view if there's no project in the workspace. It actually does callazureFunctions.createNewProject
because we know that we need to start from scratch.createFunction
has to do some checks before it ultimately cancels and callscreateNewProject
so performance is slightly better to just call it directly.Old:
New:
Added two entry points for "Create Function..." which live on the local project node and context menu