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

Benny Skogberg
  • 25,542
  • 12
  • 68
  • 163
Danny '365CSI' Engelman
  • 21,176
  • 7
  • 35
  • 79
  • 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 – Vadim Gremyachev Aug 24 '16 at 08: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 Aug 24 '16 at 09: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 – Danny '365CSI' Engelman Aug 24 '16 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 Aug 24 '16 at 12:30
  • There is an excellent SE Q&A called Programmers where you can discuss bloated code or how to "educate" junior developers into reading instructions and documentation before coding. This means that if the intention of this question is to have a discussion on wether SPFx is bloated or not this question(s) stand the risk of being migrated to Programmers.SE. If you're uncertain on how to ask questions valid for SP.SE, please read the help section. – Benny Skogberg Aug 25 '16 at 04:55
  • The intention of this question is to Guide those 90% of "developers" who just copy/paste code AND the 10% of "developers" who can't even code without using Google, to solid answers and resources. I am only 4 places behind you in the all-time ranking, Benny, I have a fair understanding of how SE works and where it utterly fails. The methods of adding jQuery have become rocket-science, we had 1847 messages in the past that had to do with (simply) loading jQuery.... do the math. – Danny '365CSI' Engelman Aug 25 '16 at 07:28
  • 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 Aug 25 '16 at 11:03

4 Answers4

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.

PatMill_MSFT
  • 2,466
  • 7
  • 9
  • 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 – Danny '365CSI' Engelman Aug 24 '16 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

Vardhaman Deshpande
  • 10,462
  • 1
  • 26
  • 52
  • 1
    Correct, Alas 90% of "developers" don't read, but copy/paste from the first resource they find in Google. – Danny '365CSI' Engelman Aug 24 '16 at 13:43
  • Thanks to update the URL (page in the Wiki has moved to https://dev.office.com/sharepoint/docs/spfx/web-parts/basics/add-an-external-library and source is at https://github.com/SharePoint/sp-dev-docs/blob/staging/docs/spfx/web-parts/basics/add-an-external-library.md) – DeChrist Jan 05 '17 at 17:44
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

Benny Skogberg
  • 25,542
  • 12
  • 68
  • 163
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)

Wictor Wilen MCA MCM MVP
  • 18,207
  • 40
  • 64