Let’s start TypeScript – Part 2

In the first part of this series, we looked at the simple steps to convert the SDK Sample Dependant OptionSets into TypeScript so you can see that it's not about 're-writing' your code. So far, we've seen how to get the TypeScript compiler to compile our old JavaScript. This part is going to look at deploying and debugging the TypeScript code.

Deploying the webresources

1. For the DependantOptionSet code to work we need to also create a config file that defines which child optionsets are filtered by which parent values, so create an xml file in the js folder called AccountOptionSetConfig.xml:
   

   <DependentOptionSetConfig entity="account" >
    <ParentField id="address1_shippingmethodcode"
                 label="Shipping method">
     <DependentField id="address1_freighttermscode"
                     label="Freight Terms" />
     <Option value="2"
             label="DHL">
      <ShowOption value="1"
                  label="FOB" />
      <ShowOption value="2"
                  label="No Charge" />
     </Option>
     <Option value="3"
             label="FedEx">
      <ShowOption value="1"
                  label="FOB" />
     </Option>
    </ParentField>
   </DependentOptionSetConfig>

   You solution should look like the following:

   

2. Next we need to enable deploying the webresources. In the previous part we installed spkl and added the DependentOptionSet webresources. If you've not done this, I suggest you go and review Part 1.
3. Adding the config xml with spkl is really easy, simply add the new file to the spkl.json file:
   

   {
   "uniquename": "sdk_/js/AccountOptionSetConfig.xml",
   "file": "js\\AccountOptionSetConfig.xml",
   "description": ""
   }

4. You can now deploy by running the spkl\deploy-webresources.bat at the command-line.
   Since we installed 'Open Command Line' in the previous part, we can simply select the spkl folder in Visual Studio and press Alt-Space to open the command prompt!
   

Testing inside Dynamics

Now that we've deployed the webresources, we can configure it for use on the Account form.

1. Open the Account Form inside Dynamics Form designer. I find this easiest to do from your App in the designer:
   
2. Select Form Properties and add the DependentOptionSet.js to the Form Libraries:
   
3. Add a new OnLoad Event Handler that calls the SDK.DependentOptionSet.init function with the Parameters (including the quotes) "sdk_/js/AccountOptionSetConfig.xml" 
   
4. Locate the Shipping Method field on the form, and add a new On Change handler calling SDK.DependentOptionSet.filterDependentField with the parameters "address1_shippingmethodcode","address1_freighttermscode"
   
5. These steps are simply necessary to wire up the code to the form events. If you save the form and publish you should now see the Shipping Method drop down filter the Freight Terms based on the configuration xml.
    

Debugging TypeScript with Fiddler

It is inevitable that whilst you are refactoring your JavaScript into TypeScript you will need to debug your code. This will involve making changes and re-testing. Deploying the code files up to the Dynamics server with each change in order that we can test will take up valuable time. Instead, whilst we developer we can use a 'trick' that uses Fiddler to redirect the requested webresources to the local version of the file instead of the version on the server. This allows us to make changes and simply refresh the browser to get the new version. I blogged about this trick back in 2014, but here is are the steps to set it up:

1. Install Fiddler2 from https://www.telerik.com/download/fiddler Run Fiddler.Select Tools->Options->HTTPS and select Decrypt HTTPS traffic.
2. Click Yes when prompted to Trust the Fiddler Root certificate, and then Yes to each subsequent dialog.
3. Click OK on the Options Dialog. This allows Fiddler to decrypt the HTTPS traffic between the browser and the server so that it can intercept it, log and respond with a different file where needed.
4. In Fiddler select Rules->Performance->Disable Caching. This will ensure that files are not stored locally in the browser cache, but downloaded with each page refresh to pick up the latest version
5. In Fiddler Select the AutoResponder tab and select 'Enable rules' and 'Unmatched requests passthrough'
   
6. Click Add Rule and enter:
   REGEX:(?insx).+\/sdk_\/js\/(?'fname'[^?]*.js)
C:\Users\Administrator\source\repos\StartUsingTypeScript\StartUsingTypeScript\src\${fname}
   
   

   Note: Adjust the path to your own project location

7. Click Save
8. You should see a grey highlighted request for the files that match – which is now redirecting to your local file.
9. When you refresh your page, you can now make changes to your local TypeScript which will recompile to a local js file and picked up without a re-deploy and re-publish.

Debugging TypeScript with Source Maps

Since we are no longer writing JavaScript directly, we need a way of stepping through our TypeScript code when debugging rather than the generated code. Luckily most debuggers have support for source maps that provide an index between the original source and the generated source. To enable this, we'll need to let the browser know where to load the TypeScript that is referenced by the .map files. The easiest way to do this is with another Fiddler autoresponder rules:

1. In Fiddler AutoResponders, use Add Rule
2. Set the Rule to be:
   REGEX:(?insx).+\/sdk_\/js\/C:\/(?'fname'[^?]*)
C:/${fname}
   
3. This now will pick up the locations in the source map and redirect to your local folder.
   https://org.crm11.dynamics.com/%7b636672751920000751%7d/webresources/sdk_/js/C:/Users/Administrator/source/repos/StartUsingTypeScript/src/SDK.DependentOptionSet.ts

   is redirected to

   C:/Users/Administrator/source/repos/StartUsingTypeScript/src/SDK.DependentOptionSet.ts

4. You can now put a debugger statement in your TypeScript and you'll see the browser step through the original TypeScript code rather than the actual JavaScript.
   

So there you have it – you have all the same features as you did when writing JavaScript - but with all the advantages of TypeScript.

In the next part we'll look at how we can use gulp to create a minified version of the JavaScript for deployment.