Sp-dev-docs: Error when loading web part with declarative dependencies between non-AMD modules (RC0)

[waldekmastykarz]

Category

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

Expected or Desired Behavior

When loading the web part, SharePoint Framework loads external scripts taking into account dependencies between these scripts configured in the project.

Observed Behavior

When loading a web part that uses two non-AMD external scripts, the web part sometimes is loading correctly, but sometimes throws an error. It seems that whether the web part is loaded correctly or not depends on the timing of loading the external scripts.

Steps to Reproduce

• in the config.json add:

  "externals": {
    "jquery": {
      "path": "https://code.jquery.com/jquery-2.1.1.min.js",
      "globalName": "jQuery"
    },
    "simpleWeather": {
      "path": "https://cdnjs.cloudflare.com/ajax/libs/jquery.simpleWeather/3.1.0/jquery.simpleWeather.min.js",
      "globalName": "jQuery",
      "globalDependencies": ["jquery"]
    }
  },

• install jquery typings: $ npm i @types/jquery -D
• in the web part code reference both scripts:

import * as jQuery from 'jquery';
require('simpleWeather');

• change the render method to:

  public render(): void {
    if (this.renderedOnce === false) {
      this.domElement.innerHTML = `<div class="${styles.weather}"></div>`;
    }

    this.container = jQuery(`.${styles.weather}`, this.domElement);

    const location: string = "Redmond"; // escape(this.properties.location);

    if (!location || location.length === 0) {
      this.container.html('<p>Please specify a location</p>');
      return;
    }

    const webPart: WeatherWebPart = this;

    (jQuery as any).simpleWeather({
      location: location,
      woeid: '',
      unit: 'c',
      success: (weather: any): void => {
        const html: string =
          `<h2><i class="icon${weather.code}"></i> ${weather.temp}&deg;${weather.units.temp}</h2>
           <ul><li>${weather.city} ${weather.region}</li></ul>`;
        webPart.container.html(html).removeAttr('style').css('background', `url('http://loremflickr.com/500/139/${location}')`);
      },
      error: (error: any): void => {
        webPart.container.html(`<p>${error.message}</p>`).removeAttr('style');
      }
    });
  }

• $ gulp serve
• refresh the workbench a couple of times and you should see the following error:

[SPWebPartErrorCode.ScriptLoadError]:: Unable to load web part WebPart.WeatherWebPart.5b1525cb-6d5b-4c86-8953-c698baf56f4b,Error: ***Failed to component "de33e780-5ae0-4d1e-abbc-5ef3468debb1" (WeatherWebPart). Original error: Error loading https://component-id.invalid/de33e780-5ae0-4d1e-abbc-5ef3468debb1_0.0.1/weatherStrings as "weatherStrings" from https://component-id.invalid/de33e780-5ae0-4d1e-abbc-5ef3468debb1_0.0.1 script resources due to: undefined. CALLSTACK:: Error at SPWebPartError.SPError [as constructor] (https://localhost:4321/node_modules/@microsoft/sp-loader/dist/sp-loader_en-us.js:20731:25) at new SPWebPartError (https://localhost:4321/node_modules/@microsoft/sp-webpart-base/dist/sp-webpart-base_en-us.js:11674:18) at Function.SPWebPartError.create (https://localhost:4321/node_modules/@microsoft/sp-webpart-base/dist/sp-webpart-base_en-us.js:11696:18) at https://localhost:4321/node_modules/@microsoft/sp-webpart-base/dist/sp-webpart-base_en-us.js:12329:65

[patmill]

Yeah - this is a known issue that we are working on. In the meantime, the workaround is to include them in your bundle rather than making them external. Will update with more information when I get it.
Thanks @waldekmastykarz

[waldekmastykarz]

Thank you for confirming @patmill. Great to hear it's on the radar and you guys are working on it. 💪

[dcu-sharepoint]

@waldekmastykarz: two questions:

1) what do you mean by "include them in your bundle" and how is the bundle created?
2) what is the meaning of the class expression 'class="${styles.weather}"' and where is the data inside the {} coming from?

Thanks and my apologies for such dumb questions.

[waldekmastykarz]

@dcu-sharepoint:

1. when referencing libraries in SPFx projects you can either load them on runtime or include in the bundle (which is what @patmill) is referring to. For more information explaining the different approaches see https://blog.mastykarz.nl/loading-frameworks-libraries-sharepoint-framework/. The bundle is created when you build your project. I suggest you follow the tutorials at https://dev.office.com/sharepoint/docs/spfx/web-parts/get-started/build-a-hello-world-web-part to get more understanding of how the different pieces work together
2. these are css classes defined in the .scss file and made available in the script through the import

[dcu-sharepoint]

thanks @waldek, great articles. I've completed the helloworld article already but the loading frameworks is new and will be read later on today(Wednesday)

thanks again, love your VERY USEFUL responses.

L. Carlos Rodriguez
@dcu-sharepoint

---

From: Waldek Mastykarz [e-mail]
Sent: Wednesday, January 11, 2017 1:42 AM
To: SharePoint/sp-dev-docs
Cc: L. Carlos Rodriguez; Mention
Subject: Re: [SharePoint/sp-dev-docs] Error when loading web part with declarative dependencies between non-AMD modules (RC0) (#336)

@dcu-sharepointhttps://github.com/dcu-sharepoint:

1. when referencing libraries in SPFx projects you can either load them on runtime or include in the bundle (which is what @patmillhttps://github.com/patmill) is referring to. For more information explaining the different approaches see https://blog.mastykarz.nl/loading-frameworks-libraries-sharepoint-framework/. The bundle is created when you build your project. I suggest you follow the tutorials at https://dev.office.com/sharepoint/docs/spfx/web-parts/get-started/build-a-hello-world-web-part to get more understanding of how the different pieces work together
2. these are css classes defined in the .scss file and made available in the script through the import

-
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/SharePoint/sp-dev-docs/issues/336#issuecomment-271791131, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AVrwr4ovB2xizZYMdYfKqpVLwy2qMrPmks5rRHnHgaJpZM4LfQ4l.

[manishgarg1]

Should this issue be closed at this point ?

[waldekmastykarz]

I'll leave it up to you guys if you want to keep it open for tracking purposes or not.

[patmill]

No, we shouldn't close it until we sort out the timing / race conditions. You should be able to say "load jquery and jqueryui" and not need to look online to see why it's not working.

[patmill]

BTW, here are some notes on loading from require vs. componentLoader. I'll add them to @olivierCC 's bug as well. We'll get them written up into official docs as well.

There are a couple differences between the 2 methods:

Require
• This method should work:
o Regardless of where your script is located: A CDN, your node_modules, or your src/ folder.
o Regardless of whether your script is an AMD module or not (use globalName)
o Regardless of whether you want the script bundled or not.

• You automatically get better TypeScript support around typings

• This means the resource is loaded when loading the bundle. [Due to webpack: the resource is listed at the top of the bundle in the define() statement].. You might not want this in every case (such as if you want to load something only in edit mode).

• The resource, if it is not pointed at a qualified URL in the config.json, will be pulled into the build system (e.g. it will be in the dist/ folder after a successful build). If it is bundled, the code will be in the bundle. If it is not bundled, there will be a separate file in the dist folder. Essentially, using require allows the build system to know about the resource.

SPComponentLoader
• You don’t want the script loaded when the WebPart is loaded (perhaps you want to wait until the webpart is in edit mode).

• The path to the resource may change (imagine that you might want to load one of 3 scripts, and that changes based on user input).

• You are having issues with require for one reason or another.

[mpasarin]

There was a race condition when loading different path-based dependencies. This has already been fixed.
Closing this issue.

[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