Frage

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

War es hilfreich?

Lösung

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.

Andere Tipps

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

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

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)

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit sharepoint.stackexchange
scroll top