Monday, November 7, 2022

Overloaded Methods in TypeScript

If you've ever worked with a language like C# or Java you're probably often using overloaded method signatures to provide callers with an opportunity to have a similar outcome by passing a different number or type of parameters. However in TypeScript which is just a superset of JavaScript and adhering to all things JS under the covers, method overloading doesn't work the same with identical method names and parameter signature because there are no types to differentiate between. If you have (2) identical methods in JS being called the latter defined method on the prototype will be called, and the former ignored.

TypeScript has the benefit of type definitions at build time so method overloading is possible... kind of. If the goal is to have intellisense to see multiple definitions of the same overloaded method, we can certainly achieve that. If the goal is to have multiple definitions of the same method name with different parameter signatures and separate, different implementations, this out of the box is not possible and won't be like traditionally static typed, structured languages like C#. Regardless let's see how overloading does work in the vanilla form (I'll hint at conditional types at the end) using TypeScript and you can decide if you can leverage for your benefit.

The recipe for overloaded methods in TypeScript is that you can create 1...n method signatures, but only have a single implemented method representing any of the possible call combinations. Let's look at a code sample:

Above we have the overloaded method named start, that represents the potential to provide the different procedures to start an engine, based on the various engine types. Note the (5) overloaded method signatures, but only a single implemented method. The reason for this is the overloaded behavior and differentiation of methods is a design/build time only feature available due to the fact we are using TypeScript. In fact if you look at the transpiled JavaScript the only method shown is the single implemented method:

If you do try and use implementations on more than 1 method with the same name, TypeScript will warn you with a, "Duplicate function implementation" warning.

Looping back to our original goal using the properly implemented code, as the method caller if we want to see at design time a list of the various signatures, we have indeed accomplished that goal as you may scroll through and see the multiple, overloaded definitions:

However this comes at a bit of a sloppy cost for that single implemented method. In order to make this work the method signature must encapsulate all potential values that could be sent to satisfy the TypeScript compiler. This usually equates to using a Union type in the method signature to account for all possible types. The next hurdle is because overloaded methods are really a fa├žade, you must manually pick apart what's sent and reverse engineer what you received at runtime. This usually equates to type guards, if statement, switch statements, or some combination to sniff out what you received, so you can proceed forward. All of this logic is that code above within our implemented method to determine what exactly we received.

It's even trickier to determine what's sent if you have (2) identical method signatures that are only differentiated by variable name like our 1st two methods below. This is not advisable even though it does work:

The long and the short of method overloading in TypeScript is that it is possible, but with a few caveats that may not make it sensible. I think if you only have (2) different method signatures, that are easily discernable at runtime in the implemented code, then this might make sense. However as the signature list expands, the logic to differentiate the potential values sent can get unwieldly. 

Lastly another potential option may be to use conditional types in the method signatures which rely on generics to sort out the types based on what the caller is sending. This could reduce the need for the implemented method to contain all the logic to sort out which values it was sent as it will be know already. However in this post I wanted to strictly do a 1:1 look at the concept of overloading as it may be known from other languages, and how it can be accomplished in TypeScript.

Wednesday, October 26, 2022

How to View Deployed Files for a Web App Using the Azure Portal

When debugging a web app and tracking down problems, especially newly created and deployed apps that aren't working, sometimes all that's needed is to look and see what's deployed to help determine the issue. This is trivial to do using the App Service Editor available from the Azure Portal.

Once logged into the portal, navigate to the website or specific deployment slot of the app where you'd like to browse the files. Viewing the menu of options on the left-hand side, select App Service Editor:

This will redirect to a location in a new browser tab which will show the folder structure and physical files present. Within the utility there are other useful functions available along the left-hand side in addition to the logging output to help diagnose and have insight into your deployed site.

This feature is still in 'Preview' mode so expect some changes over time to the utility, possibly being renamed, and on occasion being down. As noted you can always FTP into the directory as well as a secondary option.

Wednesday, October 19, 2022

Generate YAML from an Existing Azure DevOps Pipeline

Here's a quick tip if needing to generate a .yml file for CI/CD configuration from an existing Azure DevOps pipeline. There are several ways to build the .yml configuration file:

  • Make one from scratch
  • Use a template from GitHub or another similar project
  • Use the AzureDevOps pipeline editor and assistant
  • Use an auto-generated one created from a cloud portal (i.e. Azure portal)
However if the above solutions or any other aren't providing to be fruitful to your deployment configuration, you can leverage the classic editor from ADO to create a pipeline configuration visually via steps. This is often a means to an end to get working syntax in a methodical manner via form input, rather than through raw configuration.

Once you have a working pipeline however, it's ideal to get this configuration into your GitHub repository. This allows source control tracking on the configuration which is preferred to a pipeline used in a vacuum. If you used the classic editor to build a working pipeline, generating a .yml configuration is trivial. 

In ADO, navigate to the pipeline and find the ellipse next to, 'Run Pipeline.' From this menu you'll see an option to, 'Export to YAML.'

This will generate a .yml configuration file based on your working pipeline.

At this point you could add the .yml file to source control and create a new Azure pipeline connecting to your source control provider that leverages the newly created file.

Note different deployment systems use different YAML syntax or 'actions' so this may not be directly portable to another workflow for deployment. For example the .github/workflows directory in GitHub can connect to the repo from the Azure Portal in the Deployment configuration and use a .yml file. However the syntax is different for GitHub Actions, so the .yml file downloaded would only be a guide and require further massaging.

Tuesday, October 18, 2022

How to Activate an Azure Monthly Credit With Another Account When Subscription Login Denies Benefit

Scenario: You've been assigned Visual Studio Subscription (AKA MSDN subscription back in the day) by your organization, and would like to activate your free $150 (or similar) credit. Upon attempting the credit you get an error along the lines of, "You're not eligible with this benefit. Your organization does not allow activating this benefit." However you know the Azure credit is a benefit as it's listed as such on your subscription. Why an organization would block this benefit, I'm not sure nor how to inquire about resolving, but there's a simple solution.

Context: You switch companies, switch emails, a subscription expires, another is activated. This inconsistency creates havoc for your personal development and OSS work as all of your Azure resources have to be recreated over and over for new subscriptions (Note: moving resources is typically not an option as you can only do this across the same underlying subscription; see: Move Azure Resources). Now you've gone to login to your new subscription to use the Azure credit, and the benefit isn't allowed to be activated. Ideally you have a single, static, non-changing account login that you can associate varying subscriptions with over the years. The recommendation IMO is to use your personal GitHub login to associate Azure credits for 1...n Visual Studio Subscriptions. 

Solution: You can add an 'Alternate Account' to your Visual Studio subscription, that can be assigned the credit instead to associate with your current subscription. 

  1. Log into your active and current Visual Studio subscription. Under the 'Benefits' tab there will be a box to active your Azure monthly credit:

  2. Upon selecting 'Activate' you'll be presented with a Microsoft login to proceed to the Azure Portal. If you select logging in with your organization's login which is the same as your Visual Studio subscription login, you get an error that the benefit is not allowed to be used for this ID: 

  3. Back in Visual Studio subscriptions, head over to the 'Subscriptions' tab:

  4. Add an alternate email that you'd like to associate with your Azure credit. Essentially this allows using that credit, with another valid Microsoft or SSO login. My suggestion is to associate the email with your personal GitHub login. This will help set you up in the future to be able to re-associate new subscriptions with the same login to ease transition. Note - whichever account you choose, this whole process will be much easier if it's already established as a Microsoft account and have previously logged into the Azure portal ( 

  5. After adding the alternate email, go back to the 'Benefits' tab and press 'Activate' for the Azure credit again (Step #1). This time when presented with the login, use the alternate email credentials. For a GitHub login, select 'Sign on options' and SSO authenticate with GitHub. If you used another Microsoft login as the alternate account, use those credentials.

  6. If you get a login error regarding STS or federation error (i.e. AADSTS900043 or similar), just close the browser tab and reopen This seems to be a 1-off issue with the handshake and has nothing to do with this overall process.

  7. Once successfully logged in your Azure monthly credit will be applied to the alternate email ID login you configured. To check the status, you can view your subscription(s) from the 'Settings.' 

One final note - once this process is done and as expected, if you try and activate again with another login (i.e. your organization's login, another email, etc.), you'll be presented with the message that this benefit is already used and can't be activated again. I'm not sure on how to re-link the monthly credit, so ensure the login you setup is the one you want to use.