Common Issues in SPFx 1.8.0 with TypeScript 3.3

Yay! SharePoint Framework 1.8.0 is available! I decided to upgrade one of my simpler Web Parts to see what the experience was like. I learned a few things, I figured I’d share.

One of the things we get as part of this upgrade is a newer version of the TypeScript transpiler. We can choose which version of TypeScript we want to use when we add the dev dependency into the package.json file. I elected to move forward to TypeScript 3.3 by adding this line:

 @microsoft/rush-stack-compiler-3.3": "0.1.7

TypeScript 3.3 is more strict than previous versions. As the SPFx 1.8.0 release notes say:

Fix all the new and interesting tslint errors that are now getting raised with a newer compiler. For large projects, this might take a while. The default behavior of the TS compilers is getting stricter, but your code will be the better for it.

What this means is that code which transpiled and worked perfectly well in earlier versions of SPFx now may refuse to transpile. You may decide that’s annoying, but as the quote above says, your code will be better for it.

In my case, the errors pointed out two main types of things I had been doing that I needed to clean up.

Unused References and Declarations

Unused references and declarations are now a no-no. I had quite a few imports in my components what I wasn’t actually using and variables I once used but no longer was. You’re likely to have at least a few of these if you’ve refactored your code into separate components over time.

In earlier versions of TypeScript, this was fine. Depending on your IDE (I’m partial to WebStorm), you may or may not have gotten a warning. In TypeScript 3.3, those unused references throw an error. It’s a nice opportunity to get rid of the junk you have laying around.

Here’s an example from my code. I’m importing ISPSite, but I’m not using it in the component because I moved some logic into a different component.

import {IServiceProperties, ISPSite, IExclusion} from "./models/Models";

The error about this is:

[12:02:52] Error - [tsc] src/webparts/myTeams/MyTeamsWebPart.ts(17,29): error TS6133: 'ISPSite' is declared but its value is never read.

The fix is to simply remove the unused references or declarations. So now my line just looks like this:

import {IServiceProperties, IExclusion} from "./models/Models";

Possibly Undefined Objects

If you’re sloppy like I sometimes am, you may simply assume a variable is going to have a value. If you come from the JavaScript world, you may do this more often than someone who comes from the C# (strictly typed) world. TypeScript 3.3 doesn’t want us to be sloppy like that, so if you’re not checking for an undefined state, you now get an error.

Here’s a line from my Web Part where I got the error:

return this.processSearchResults2(result.RawSearchResults.PrimaryQueryResult.RelevantResults.Table);

In that line, I’m assuming I’m going to get results back from a call to the Search service containing a collection of subsites. Of course, it’s possible that there won’t be any values because something has gone wrong, the user doesn’t have permissions on any subsites, or whatever. In my testing, this was no problem because I always got a collection of sites back. It may never be an issue, but my code isn’t safe.

Here’s the error:

[12:08:09] Error - [tsc] src/webparts/myTeams/services/DataService.ts(74,39): error TS2532: Object is possibly 'undefined'.

In this case, the fix is to add safer checking on the value of the variable result. The brute force way to fix this is to test the entire object chain for undefined, like so:

if(result.RawSearchResults && result.RawSearchResults.PrimaryQueryResult && result.RawSearchResults.PrimaryQueryResult.RelevantResults && result.RawSearchResults.PrimaryQueryResult.RelevantResults.Table) {
  return this.processSearchResults2(result.RawSearchResults.PrimaryQueryResult.RelevantResults.Table);
} else {
  return sites;
}

To me that feels sort of messy. Lodash comes bundled with the SPFx installation, so you can do something cleaner like this:

let searchResults = lodash.get(result, "RawSearchResults.PrimaryQueryResult.RelevantResults.Table", []);

return this.processSearchResults2(searchResults);

The lodash.get() function is slick: it does the testing down the chain for you and also allows you to pass a default value to use if the object chain is undefined somewhere along the way. (Thanks to Julie [@jfj1997] for sharing her Bingle-fu on this one.)

---

By fixing my code for those two types of errors, I was able to get back to a good state. This is a relatively small Web Part, so it took me longer to write this post than to actually fix things.

This all means that it may be a little work to upgrade your SPFx solutions to 1.8.0. The value of getting these new errors, though, outweighs the annoyance of fixing the issues. Over time, TypeScript is going to help you write better code, and your solutions will be more foolproof. It won’t guarantee your code doesn’t have any bugs, but it may make it harder for you to write silly bugs into your code in the first place.

---

For some other insights on the SPFx release, check out these posts:

• Using the full potential of React in SharePoint Framework 1.8.0 by Elio Struyf (@ElioStruyf )

Have you found an useful article about SPFx 1.8.0? Please share in the comments…