When I went to follow the next tutorial I found that despite my files being hosted in a SharePoint library turned CDN, I was still being prompted to Allow Debug Manifests.
I found that clicking Load debug scripts did nothing. This makes sense since I was not running gulp serve and so no local files would be loading. In fact, a check in the console didn’t show any file not found errors (as would be expected when debugging and gulp serve is not running so local JS files wouldn’t be found).
Strangely, if I chose Don’t load debug scripts my extension would run (the app had been added to the site and the assets loaded into the CDN)! So it was great that things were running, but really weird that I kept getting that prompt.
I uninstalled the app (Site Contents classic view and chose Remove) and even made sure it was deleted out of both stages of recycle bins. But I was still prompted on every modern page every time I visited them!
Aha! The custom action is still in place! So I used the Powershell PnP Cmdlet Remove-PnPCustomAction and ensured that there were no custom actions lingering anywhere. Still prompted! AHHHHHHHHHHHH!
Finally, I posted it as an issue on the sp-dev-docs github repository and Pat Miller quickly provided the answer. Just add ?reset=true to the URL. You only need to do it once and it will clear everything up for the whole site. Apparently a debug cookie gets set sometimes and using this querystring will clear it out.
I’ve been playing with the new SharePoint Framework (SPFx) Extensions lately and ran into strange error when attempting to create a new one. I ran the yo @microsoft/sharepoint command and filled out the prompts to create a new Field Customizer extension. Things looked like they were working for about 15 seconds when I got this sadness:
Here’s the relevant text of the error:
No compatible version found: @microsoft/decorators@~1.0.1
Valid install targets:
1.1.0, 1.0.0, 0.2.1, 0.0.0
This is most likely not a problem with npm itself.
In most cases you or one of your dependencies are requesting
a package version that doesn't exist.
It was specified as a dependency of '@microsoft/sp-application-base'
So what happened? I could use this generator just a few days ago!
The first thing you should do when troubleshooting issues with the generator is check your version vs the available versions.
To check your version just use the following npm command:
npm list -g @microsoft/generator-sharepoint
When I did, I found I had version 1.1.0 so I checked what versions were available:
npm view @microsoft/generator-sharepoint versions
Sure enough, the latest version was 1.1.1 so I updated my generator:
When you create a SharePoint Framework (SPFx) webpart, you can customize the icon displayed in the Authoring Canvas Toolbox. Here’s what it looks like by default:
By default, the Office Fabric Page icon is used but this can and should be changed before packaging up your app. This makes sure your webpart doesn’t get lost among all the other webparts and is a very simple way to add a professional touch.
There are 2 ways to customize this icon. You can specify the name of an icon from the Office UI Fabric icons or you can provide a URL to a custom image.
Both of these are accomplished by editing your webpart’s manifest.json file and changing a simple property.
The Page icon shown above is doing exactly this. You can find this setting in the src/webparts/[YOURWEBPARTNAME]/[YOURWEBPARTNAME].manifest.json file in the preconfiguredEntries/officeFabricIconFontName property:
You can simply change this value from Page to any of the available icon names. Here’s what it looks like with a value of Emoji2:
Keep in mind that this value is CASE SENSITIVE. Also, note that changes to your manifest file (unlike your code files) will require you to stop the gulp serve command and do it again to have those changes reflected in the workbench.
If you inspect the actual toolbox you’ll see that the class name for the span is simply concatenating “ms-Icon–“ and the property value:
This approach is super easy (just change the name) and ensures your webpart matches the official Office styles. But what if you want your own custom icon or logo?
There is another property available called preconfiguredEntries/iconImageUrl and allows you to specify an image URL.
In order to use this property, create a 40x28px icon and upload it somewhere. For this example I’m just going to use my blog, but ideally you would include it in the webpart and then pull this value from your CDN.
You’ll also have to remove the preconfiguredEntries/officeFabricFontIconName property (or the iconImageUrl will be ignored). Here’s what my property looks like:
Again, note that changes to your manifest file (unlike your code files) will require you to stop the gulp serve command and do it again to have those changes reflected in the workbench.
So here’s what it looks like in my local workbench:
What happened!?! For whatever reason, the local workbench continues to try and use a class icon as seen above (You can even see it sets a class of ms-Icon–undefined). However, the O365 workbench (/_layouts/15/workbench.aspx) works just fine:
A quick inspection shows that the property value is just being inserted as the src attribute for an img tag.
This means (and I’m not suggesting you should) that if you happen to have a weird Christopher Walken eyeball gif:
You could simply resize it and get something like this:
Looking at the documentation for the manifest properties (json schema) you may see some misleading outdated information. (If you haven’t setup config file intellisense in VSCode, go do it now! Here’s an awesome guide.)
The description for the officeFabricIconFontName property looks like this:
It directs you to a site with 600+ icons many of which are present in the UI Fabric Icon styles. However, these names do NOT often match the actual class names and so cannot be reliably depended on to locate your icons (for example, the “Emoji2” icon we used in the sample above is listed as “smiley2” on the font site. It took going to the Office UI Fabric Icons page to find the correct class name).
The description for the iconImageUrl property looks like this:
You are instructed to use an icon that is exactly 38x38px. This is no longer accurate. You can use whatever size you want but it will be scaled to 40x28px.
When making SharePoint Framework (SPFx) client side webparts, it’s common to load some data from somewhere else and then display it on the screen. Even if that data is just coming from a local list these requests are performed asynchronously and you should indicate to a user that the operation may take some time. The easiest way to do this is through the loading indicator. Here’s how it looks by default:
Did you know that you can easily show/hide this indicator and even customize the text? You can even decide where it’s displayed. WOWEE!
To show the Loading Indicator you can simply call this.context.statusRenderer.displayLoadingIndicator where the this refers to your BaseClientSideWebPart. This method takes 2 parameters.
The first parameter is the element where you want the loading indicator to be displayed. Typically if you are calling this from the main render method in your webpart, you’ll just specify this.domElement. However, you can easily specify any other element (see below for an example). Just be aware that the default styles are currently pretty large.
The second parameter is the text you want to display between Loading and …