20

The SharePoint Framework weather example loads jQuery inside the WebPart render method:

https://www.youtube.com/watch?v=HGC9gsDRy1E#t=10m30

Questions:

  • Is this the preferred development pattern?
  • Will it reload jQuery multiple times when used in multiple WebParts?
    (for sure with .ts files all over the place and Devs using different URIs)
  • Why this code and (potential) memory bloat?
  • How can jQuery be loaded as one global?

The answers are not necessarily for me.

On the Net you have ONE CHANCE to do code right.

We Fronteers have seen it happen with jQuery 10 years ago,
and with the CSR examples on MSDN.

Once examples go wild, they will be copy/pasted,
and 90% of "developers" won't have a clue on what they are doing

7
  • Great question, regarding last statement: Once examples go wild, they will be copy/pasted, and 90% of "developers" won't have a clue on what they are doing, i can't agree more Commented Aug 24, 2016 at 8:51
  • 3
    @Danny, can you keep this down to one question? As it stands this question is falls into the too broad/likely to cause debate category. It's a fair point about bloat, etc.,, but better if you just ask if jQuery is loaded multiple times. The bloat debate is more suited to a discussion forum. Cheers.
    – SPDoctor
    Commented Aug 24, 2016 at 9:57
  • 1
    I do think the bloat mention serves a point here, SPDoctor. We have one chance to control the future and educate that 90%. They will be reading this post, and it will hopefully guide them towards becoming a better developer. It is in our benefit as well, our (at least my) 50% of work is cleaning up bad, stupid code. If this question has to be ONE question, it is: Do we want to educate and really care about what we share? Or are we (again) going to throw code over the wall Commented Aug 24, 2016 at 10:33
  • I would guess that before you call the module.loadScript you would check if jQuery is loaded on the page or not. I'm assuming they didn't include this check since it is just a quick n' dirty example that wasn't taking into consideration the possibility of this webpart being added multiple times to a page.
    – Ray Hogan
    Commented Aug 24, 2016 at 12:30
  • 2
    Danny, the question "Do we want to educate and really care about what we share?" would be more of a discussion so not a good fit for this site. But the question as posted has produced some great answers so I think all good :-) @Benny, let's not migrate this.
    – SPDoctor
    Commented Aug 25, 2016 at 11:03

4 Answers 4

7

I'll add one more thing here. The plan in the near future is to standardize the most common libraries and host a single version on the Microsoft Cdn, and then recognize that a developer is including "jQuery" or "handlebars" or whatever, and load it once. That should reduce the size of the page download and increase the cache hit size. Of course you will be able to not do it that way of you need to, but the idea would be that it is the common path.

1
  • What are the Common libraries. And can we add libraries to that (Microsof) trusted CDN. Ofcourse for a fee so it doesn't become a free-for-all like the current App-store Commented Aug 24, 2016 at 15:17
5

My understanding is that jQuery and other common libraries should be loaded as an external libraries which can be shared by multiple spfx webparts. There is a great section on this in the wiki: https://github.com/SharePoint/sp-dev-docs/wiki/Add-an-external-library-to-a-web-part

2
5

As always there are different ways to load jQuery or any other JavaScript library. If you read through the tutorials you will soon learn that you can unbundle the library from the webpart itself. This would be useful if you have several webparts on the same page.

Unbundle external dependencies from web part bundle

By default any dependencies you add gets bundled into the web part bundle. While this could be true for some cases, it is not ideal. Hence you can choose to unbundle these dependencies from the web part bundle.

In Visual Studio Code, open the file config\config.json

This config.json contains information about your bundle(s) and any external dependencies included.

The entries region contains the default bundle information which in our case is the jQuery web part bundle. You will see one entry per web part once you add more web parts to your solution.

"entries": [
  {
    "entry": "./lib/webparts/jQuery/jQueryWebPart.js",
    "manifest": "./src/webparts/jQuery/jQueryWebPart.manifest.json",
    "outputPath": "./dist/j-query.bundle.js",
  }
]

The externals section contains the libraries information that are not bundled with the default bundle. As you can see, we have a few by default.

"externals": {
    "@microsoft/sp-client-base": "node_modules/@microsoft/sp-client-base/dist/sp-client-base.js",
    "@microsoft/sp-client-preview": "node_modules/@microsoft/sp-client-preview/dist/sp-client-preview.js",
    "@microsoft/sp-lodash-subset": "node_modules/@microsoft/sp-lodash-subset/dist/sp-lodash-subset.js",
    "office-ui-fabric-react": "node_modules/office-ui-fabric-react/dist/office-ui-fabric-react.js",
    "react": "node_modules/react/dist/react.min.js",
    "react-dom": "node_modules/react-dom/dist/react-dom.min.js",
    "react-dom/server": "node_modules/react-dom/dist/react-dom-server.min.js"
  },

In order to exclude jQuery and jQueryUI from the default bundle, we add the modules respectively to the externals section:

"jquery":"node_modules/jquery/dist/jquery.min.js",
"jqueryui":"node_modules/jqueryui/jquery-ui.min.js"

Now when you build your project, jQuery and jQueryUI will not be bundled into your default web part bundle

Reference: jQuery accordion webpart

3

jQuery can be loaded using the ModuleLoader or they can be bundled into your package. It's all up to you as the developer to choose how to do this. Both has its advantages.

Also, the current version (developer preview at the time of writing this) is focused on the bundling (Webpacking) of assets and to some extent the recommended approach.

(jQuery is most likely not the "preferred" way of building client-side web parts. The whole design of the SharePoint Framework really screams use React, Knockout, Angular - something that is not built for modifying the DOM only)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.