SPFx | Failed to load component.

6 min read. This post describes the typical reasons why one might encounter the following error, and the ways I’ve found to fix them: “Failed to load component. Original error: ***Failed to load path dependency ContosoSPFxWebPartLocalization from component [guid] (ContosoSPFxWebPart)“.The error typically looks something like this in the screenshot below:“Something went wrong” when loading your SPFx webpart. What do? ProblemThis error can be thrown for a lot of different reasons. I’m trying to describe the variants I’ve run into and their fixes below. But first, let’s take a closer look into the error in question!So looking at this, what’re the actual errors we’re getting? Where are they stemming from?From the first line (“SPLoaderError.loadComponentError“) we already know that it’s about the SPFx failing to load your component for whatever reason. Now all that’s left is figuring out what the reason is!I’ve seen a few different variations of this error. Sometimes you have the sick-looking “https://component-id.invalid…” -URL, and sometimes you see an absolute URL- let’s take a closer look at the stack below![SPLoaderError.loadComponentError]:***Failed to load component "9951b316-c8f2-4e27-887a-b7a46b3e94a0" (ContosoSPFxWebPart).Original error: ***Failed to load path dependency "ContosoSPFxWebPartLocalization" from component "9951b316-c8f2-4e27-887a-b7a46b3e94a0" (ContosoSPFxWebPart).Original error: Error loading https://component-id.invalid/9951b316-c8f2-4e27-887a-b7a46b3e94a0_1.3.1/ContosoSPFxWebPartLocalization Unable to load script https://contoso.sharepoint.com/sites/contosoapps/ClientSideAssets/490f3be2-7e8a-4fe5-8d6b-49ae5d7c4a2e/s-ContosoSPFxWebPartLocalization_en-us_2b301efaa958eadafbad865f710d89e4.js***INNERERROR:***Failed to load path dependency "ContosoSPFxWebPartLocalization" from component "9951b316-c8f2-4e27-887a-b7a46b3e94a0" (ContosoSPFxWebPart).Original error: Error loading https://component-id.invalid/9951b316-c8f2-4e27-887a-b7a46b3e94a0_1.3.1/ContosoSPFxWebPartLocalization Unable to load script https://contoso.sharepoint.com/sites/contosoapps/ClientSideAssets/490f3be2-7e8a-4fe5-8d6b-49ae5d7c4a2e/s-ContosoSPFxWebPartLocalization_en-us_2b301efaa958eadafbad865f710d89e4.js***CALLSTACK:Error at t [as constructor] (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:889:16049) at new t (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:1512:21125) at Function.e.buildErrorWithVerboseLog (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:1512:16214) at Function.e.buildLoadComponentError (https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:1512:12245) at https://spoprod-a.akamaihd.net/files/sp-client-prod_2019-03-15.008/sp-pages-assembly_en-us_2676c0dcef2e33d08d5b8433ef878499.js:1512:60385You’ll be interested in a couple of things here. The first line we’re already familiar with (SPLoaderError.loadComponentError), so now we’ll take a look at 2 different interesting things. First of all, we can identify the faulting components by investigating the component IDs – probably, the most interesting line is the INNERERROR:***Failed to load path dependency “ContosoSPFxWebPartLocalization” from component “9951b316-c8f2-4e27-887a-b7a46b3e94a0” (ContosoSPFxWebPart).The name of the dependency tells you, which component, bundle or file the Loader is failing to load. This will of course help you identify which of your imports fails if you’re the one developing the solution.Another interesting part is the URL where the Loader is trying to load the dependencies. Take a look at the example below:Unable to load script https://contoso.sharepoint.com/sites/contosoapps/ClientSideAssets/490f3be2-7e8a-4fe5-8d6b-49ae5d7c4a2e/s-ContosoSPFxWebPartLocalization_en-us_2b301efaa958eadafbad865f710d89e4.jsTake another look at that URL and make a mental note of it – you’ll need it soon.Reasons and solutionsOkay, so after a bit of digging, there are a couple of different reasons and different solutions. The first thing we need to figure out is to find the deployment path for your solution. It’s likely either the SharePoint CDN, or a path under the App Catalog in SharePoint Online. However, it’s also possible to host the files your .sppkg or .app file then requests in pretty much any location! Anyway – let’s verify if you’re using CDN or not. Take a look at the error to find the url the script is being loaded from – does it begin with something like this:publiccdn.sharepointonline.comIf it does, you likely have an SPFx webpart that’s deployed to the public Office 365 CDN.While you might have additional resources loaded from CDN, these domains are typically not hosting your components:*.sharepointonline.com cdn.sharepointonline.comstatic.sharepointonline.comprivatecdn.sharepointonline.comspoprod-a.akamaihd.netThese are additional resources or core components being loaded from different CDN services. Yes, Microsoft has quite a few of them :)If you’re not using CDN, skip the next subchapter and jump right to “Error in dependencies or packaging“.Errors with CDNThis solution only applies if you’re using Office 365 CDN.Does the error apply to just one SPFx package or to multiple? If it applies to all of the SPFx packages that are deployed to CDN on that tenant, it’s somewhat safe to assume that the CDN is to blame.While using Office 365 is definitely the suggested course of action most of the time, it’s worth realizing that the CDN is not the most stable piece of tech ever existed. The built-in CDN has had its fair share of issues – see the ones below for examples:https://github.com/SharePoint/sp-dev-docs/issues/1731https://github.com/SharePoint/sp-dev-docs/issues/2015https://github.com/SharePoint/sp-dev-fx-webparts/issues/491https://github.com/SharePoint/sp-dev-docs/issues/864https://github.com/SharePoint/sp-dev-docs/issues/3079A lot of times, these issues are fixed by one of the following actions (these are very unofficial and totally made up by me, by the way).Time needed: 6 minutesHow to fix Office 365 CDN when it breaks Make sure you have enabled CDN for this tenant. Wait for about 15 minutes. Verify that you have */ClientSideAssets set as a private CDN origin. Deploy an updated version of your sppkg package. Remove your existing packages (only if you know you can do that on this tenant!), also from the recycle bin in the app catalogue site, and then upload your package again. Open a ticket at Microsoft Support complaining about this case and reference the suitable GitHub issues in it. To verify that you have a CDN origin configured properly, run this and verify the origin exists (see picture below): Connect-PnpOnlineGet-PnPTenantCdnOrigin -CdnType "Public" In order to host your apps from Office 365 CDN, you need to have a Public CDN origin configured for ClientSideAssets. These steps apply to both the error described in this article, but also cases when your app just won’t update.Error in dependencies or packagingIf you’re encountering this with your own package in development, grab the component name and/or the Guid. The component name will help you pinpoint which one of your imports is being misconstructed.Now, if it indeed is YOUR package, fix it somehow like the steps in this article by Shantha Kumar Thambidurai.You could also try running gulp clean and rebuild, something like this:gulp cleangulp buildgulp bundle --shipgulp package-solution --shipThis issue only exists in Internet Explorer…Oh, how I would love to tell you to stop using Internet Explorer… But I know, I know – maybe your customer requires it.Anyhow, these are some of the extra things you can try with IE:Force IE to use 11 document modeIE 10 or compatibility mode is not supported. If you have to, modify the master page to get IE to behave properly.Set your site and CDN to be in the same security zoneShouldn’t matter – but it still does. Duh.Go through your dependencies once moreThere are a TON of dependencies, that might not be compatible with legacy browsers. Verify, that you’re not using something that doesn’t work with IE at all!This applies especially if you get the threaded error below:[SPLoaderError.loadComponentError]:***Failed to load component "58c4fb68-60f1-45ac-b057-ba7cc51c3ec2" (WebPartName).Original error: ***Failed to load URL 'https://publiccdn.sharepointonline.com/tenantname.sharepoint.com/sites/AppCatalogName/ClientSideAssets/ca2eacd0-4645-4306-a335-e5d9aa919578/web-part-name_e437798e9f3bcfff6ee74118a0bf73ed.js' for resource 'web-part-name' in component '58c4fb68-60f1-45ac-b057-ba7cc51c3ec2' (WebPartName). There was a network problem.This may be a problem with a HTTPS certificate. Make sure you have the right certificate.Another quick note about the error above – also verify that your system time is correct – if not, you might run into funny SSL certificate errors… :)Is it not your package? Check the solutions below, and if none of them resolves your issue, ask whomever you got the package from, if the package is working for everyone else.Error with External/Guest usersOkay, sounds pretty broad, right? But I’ve found 2 different solutions here. These solutions apply to AT LEAST the situations when your internal users don’t necessarily experience the issues at all, but your external/guest users do.Not using CDN?If you’re not using CDN with your SPFx webparts, most likely they’re hosted from your app catalog’s SiteAssets/ClientSideAssets library. If you have external users accessing your site, they won’t by default be able to access this site at all, and will hence encounter weird issues with the SPFx webparts.In a case like this, you have at least two different options:How to enable your external users to access your SPFx webparts that are not hosted on CDN:Enable CDN and deploy your apps there instead of the app catalogueSee my snippet on how to do that: How to fix Office 365 CDN when it breaks?Modify the ClientSideAssets -library’s permissions in the app catalogue site to allow external users access there. This includes at least the following steps.Enable external sharing on your tenant if it isn’t enabled already.Enable external sharing on the App Catalog siteInvite a group with your external/guest users to the ClientSideAssets library as visitors/readers.As a side note, to enable hosting your SPFx solution from SharePoint, you need to have “includeClientSideAssets” as “true” in the package-solution.json file. This configuration is also typically ignored when building debug builds (bundle without –ship).Using CDN and messing up the permissionsIn a case like this, it’s probably not you, it’s Microsoft. There isn’t that much you can mess up with CDN that would be external users -specific. And if you have, I want to hear about that, so please do leave a comment below!Otherwise, to try and fix the CDN, see my steps for Office 365 CDN tweaking here.ReferencesMore info about Office 365 CDN:https://docs.microsoft.com/en-us/office365/enterprise/use-office-365-cdn-with-spohttps://docs.microsoft.com/en-us/office365/enterprise/content-delivery-networkshttps://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges?redirectSourcePath=%252farticle%252f8548a211-3fe7-47cb-abb1-355ea5aa88a2https://docs.microsoft.com/en-us/sharepoint/dev/spfx/web-parts/get-started/hosting-webpart-from-office-365-cdnhttps://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-serviceIf you want to read more on Office 365 CDN, these are good sources to get started!

#SharePointProblems

Solutions are worthless unless shared! Antti K. Koskela's Personal Professional Blog

Month: May 2019

SPFx | Failed to load component.

How to resolve the “You cannot edit this page”-error in Modern SharePoint

“Connecting to site failed: ‘.’, hexadecimal value 0x00, is an invalid character.”, when trying to connect to SharePoint Online