Sp-dev-docs: What would be the best way to reference JSOM from a SPO site where our web part is going to deploy to

[frankchen76]

Category

• [X ] Question
• [ ] Typo
• [ ] Bug
• [ ] Enhancement / Suggestion
• [ ] Additional article idea

As a section "Loading SharePoint JSOM" in Add an external library to your SharePoint client-side web part mentioned, SPFx can use JSOM library by adding reference in config.json when we connect to SPO. Based on the code sample list in that document, the "path" points to a absolute URL. "path": "https://CONTOSO.sharepoint.com/_layouts/15/SP.js", . When we deploy our web part, we definitely don't know what the final URL is going to be. So my question is what would be the best approach to reference JSOM library from a SPO site where we are going to deploy a web part? do we have token string which allows SPFx to reference JSOM library from target SPO site?

[waldekmastykarz]

Have you tried using a server-relative URL rather than an absolute one?

[frankchen76]

@waldekmastykarz. I tried to use relative URL like "path": "/sites/dev/_layouts/15/SP.js" and "path": "_layouts/15/SP.js". But unfortunately, both didn't work.

[waldekmastykarz]

What was the error that you got when trying to do this?

[jaredbuttars]

My experience getting that section of the docs and JSOM to work was very problematic. Basically everything after the point to install SharePoint Typings didn't work at all. What I ended up doing was using SP.SOD.executeFunc to ensure JSOM was available. There was no need to include any additional external scripts or require statements.

Mind you, my web part is running in a classic page not a modern page so it's probable that the required scripts are already loaded.

SP.SOD.executeFunc('sp.js', 'SP.ClientContext', () => {
  //  JSOM is available
});

[frankchen76]

please look at my screenshot for error message, I think when I changed to server relative URL, SPFx loaded JSOM from webpart's host which is my localhost.

[waldekmastykarz]

If you're using a server-relative URL to reference SharePoint-hosted scripts, but are testing your web part in a locally-hosted workbench than these URLs won't work: as you're seeing in the screenshot the server-relative URLs point to your local dev machine which doesn't have these scripts. Have you tried testing your web part in the hosted workbench available at https://yourtenant.sharepoint.com/_layouts/15/workbench.aspx?

[frankchen76]

I was testing on my SPO workbench. I think when I used gulp serve to start my webpart, the webpart related code should be reference by localhost:4321(see my previous screenshot) no matter you test on local workbench or SPO workbench. It seems like SPFx loaded relative URL from webpart host which is localhost:4321 instead of SPO.

[waldekmastykarz]

One workaround that you could try is to use SPModuleLoader to load the scripts in code rather than defining them as external resources in the config.

In the config.json file to the externals section you would add:

"@microsoft/sp-module-loader": "node_modules/@microsoft/sp-module-loader/dist/sp-module-loader.js"

Then, in code you would import the SPModuleLoader class:

import SPModuleLoader from '@microsoft/sp-module-loader';

Finally, in code you would call:

ModuleLoader.loadScript('/_layouts/15/SP.js', 'SP').then((SP: any): void => {
    // the rest of the code that depends on SP.js
});

[jpalo]

Any idea why using the SPModuleLoader as described above throws this error? Don't pay too much attention on the GUIDs as I parsed this error from two error messages to get it in English.

Error comes from the loadScript row:

SPModuleLoader.loadScript('/_layouts/15/SP.js', 'SP').then((SP: any): void => {
    // the rest of the code that depends on SP.js
});

[SPWebPartErrorCode.ScriptLoadError]:: Unable to load web part WebPart.ItemListWebPart.2f07d505-b453-4c79-9137-65ac99d043ae,Error: ***Failed to load component "6d3567ef-a711-49f9-83f0-3b83fccca741" (ItemListWebPart). Original error: ***Failed to load path dependency "@microsoft/sp-module-loader" from component "6d3567ef-a711-49f9-83f0-3b83fccca741" (ItemListWebPart). script resources due to: {1}. CALLSTACK:: Error at t [as constructor] (https://spoprod-a.akamaihd.net/files/sp-client-prod_2017-03-03.007/sp-loader_fi-fi_64d7a0f1f3c7b997dccbc7fa5337153d.js:88:23976) at new t (https://spoprod-a.akamaihd.net/files/sp-client-prod_2017-03-03.007/sp-webpart-base_fi-fi_2775b02c45dd8e838ee74f316c7988a1.js:146:34992) at Function.t.create (https://spoprod-a.akamaihd.net/files/sp-client-prod_2017-03-03.007/sp-webpart-base_fi-fi_2775b02c45dd8e838ee74f316c7988a1.js:146:35433) at e._handleModulePromiseRejection (https://spoprod-a.akamaihd.net/files/sp-client-prod_2017-03-03.007/sp-webpart-base_fi-fi_2775b02c45dd8e838ee74f316c7988a1.js:146:54328) at https://spoprod-a.akamaihd.net/files/sp-client-prod_2017-03-03.007/sp-webpart-base_fi-fi_2775b02c45dd8e838ee74f316c7988a1.js:146:44910

[mpasarin]

In order to use JSOM, follow the instructions in https://dev.office.com/sharepoint/docs/spfx/web-parts/guidance/connect-to-sharepoint-using-jsom
Following those steps will get JSOM working on your web part successfully. We are working on improving this scenario with a simpler, more efficient way to load JSOM. In that case the article will be updated with the latest guidance for using JSOM.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues