Sp-dev-docs: Doc: Office-ui-fabric-react proper guidance for CDN reference

[baywet]

The documentation doesn't provide any guidance when leveraging office ui fabric react with the SharePoint Framework.
Ideally you'd either reference it from the CDN or from the context.
I tried adding

    "office-ui-fabric-react": "https://unpkg.com/[email protected]/dist/office-ui-fabric-react.min.js",

This one fails because office ui fabric react can't find React and React Dom as global variables at runtime. So then I tried:

    "office-ui-fabric-react": {
      "path": "https://unpkg.com/[email protected]/dist/office-ui-fabric-react.min.js",
      "globalName": "Fabric",
      "globalDependencies": [
        "react",
        "react-dom",
        "tslib"
      ]
    },

This one fails because react and react-dom are not defined as external dependencies in the config.
If you follow @waldekmastykarz 's article https://blog.mastykarz.nl/bundling-external-frameworks-sharepoint-framework-client-side-web-parts-bad-idea/ with the latest version of the SharePoint Framework you get the following build time error:

External "react" is specified both as a linked package in the node_modules dependency tree and as an external in in the config.json file. Remove one of the external references. Only one external reference type is allowed per external package.
[16:30:24] Error - [copy-assets] External "react-dom" is specified both as a linked package in the node_modules dependency tree and as an external in in the config.json file. Remove one of the external references. Only one external reference type is allowed per external package.
[16:30:24] Error - [copy-assets] External "@microsoft/sp-lodash-subset" is specified both as a linked package in the node_modules dependency tree and as an external in in the config.json file. Remove one of the external references. Only one external reference type is allowed per external package.
[16:30:24] Error - [copy-assets] External "@microsoft/sp-client-preview" is specified both as a linked package in the node_modules dependency tree and as an external in in the config.json file. Remove one of the external references. Only one external reference type is allowed per external package.

It'd be nice to have the documentation updated to be able to properly reference office ui fabric from a CDN (or from the context if it's not necessary) so our bundles are much lighter. Not only this is going to improve the experience of users towards customs components but also towards SharePoint in general.

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 0dedd717-ec39-dcd9-3994-7bab3839df28
• Version Independent ID: 0eddf92b-1b20-650e-2432-83c530279815
• Content: Using Office UI Fabric Core and Fabric React in SharePoint Framework
• Content Source: docs/spfx/office-ui-fabric-integration.md
• Product: sharepoint
• GitHub Login: @spdevdocs
• Microsoft Alias: spdevdocs

[waldekmastykarz]

Good suggestion @baywet 👍

[OliverZeiser]

I'd like to see guidance for this as well!

[waldekmastykarz]

If I recall it correctly, the guidance to recommended way to use Office UI Fabric React components is to statically reference specific components in your project and have them bundled in your solution. As for Office UI Fabric Core you should be able to load it from CDN, but these classes are already present on the page in SharePoint.

[OliverZeiser]

@waldekmastykarz that is correct and that works. But it leads to really large bundle sizes. And it sucks if multiple webparts and vendors bundle the same components over and over again....

[waldekmastykarz]

How many components do you include? If you include one or two components statically, the total bundle size increase should be significantly lower than pulling in the whole Office UI Fabric React, even if from CDN.

When talking about multiple web parts: is each one of them bundled separately?

With regards to different vendors, the use case isn't that easy, because in the end each of them could request a different version of Fabric React from the CDN and as a result cause downloading significantly more data than if each of them only included the specific components they use in their bundles.

[baywet]

Still it should be a choice. In our case we're building 7 complex components for our customer and there are cases where they are all on the same page. In those cases, even if we refer the specific component from UI fabric react, the page ends up being around 17 MB, 10 being for multiple copies of the library and 3 for SharePoint. We also have other librairies we could dedup and refer from the CDN in that case but only office UI fabric react would save a lot.

[OliverZeiser]

In this case it is a solution with many WebParts/Extensions that we would like to bundle separately. But because of Office UI Fabric React we have to bundle them in a single bundle. Otherwise the total size would increase dramatically. Since we are also using many OUIFR components it would make a lot of sense for us to pull this from a CDN and bundle the webparts/extensions in seperate bundles.

Regarding the versions...I would even go that far, that OUIFR should be part of SPFx and hosted and managed by Microsoft. That way all Vendors/Solution and MS would share the same versions and the same issues related to it ;)

[waldekmastykarz]

@baywet how are you referencing Office UI Fabric React in your solution?

@OliverZeiser this isn't that easy: imagine that Microsoft would want to switch to a newer version of Fabric hosted for everyone. Such change could cause your solution to break and you would have no idea to test it beforehand because you don't control when updates to O365 arrive in your tenant. With the current setup worst case scenario you will end up with a control that looks a bit different than what's available on the page, but it would be working nevertheless. Still, it shouldn't be the case that you're pulling it multiple MBs for UI only.

[OliverZeiser]

@waldekmastykarz of course it is not that easy. But if it is a custom bundle of Fabric that is controlled by MS this would be possible with versioning they are using in SPFx already. They are doing the same thing for React and other things. Currently SPFx is using React 15, with React 16 coming soon to SPFx hopefully. They can't break all existing solutions with that change either.
Other than that, I am fully with you on that statement. Multiple MBs for (more or less) UI only shouldn't be the case.

[baywet]

@waldekmastykarz on the sass side @import '~office-ui-fabric-react/dist/sass/_References.scss'; on the tsx side import { Icon } from 'office-ui-fabric-react';

[chiragshahklc]

I am having same issue.

External "react" is specified both as a linked package in the node_modules dependency tree and as an external in in the config.json file. Remove one of the external references. Only one external reference type is allowed per external package.

Is there any solution for this?

I am using SPFx version 1.6.0

[VesaJuvonen]

So - right now this is simply not supported or possible as using multiple different version of Office UI Fabric in a page and loading them CDN dynamically will result in issues on the page framework... so it will not work. This is precisely why we recommend bundling these components in solution, which does indeed increase the bundle size... a lot... and sure in an ideal world there would be options... but right now there is not. When we release isolated web parts (in 1.7 previews), you can potentially do this without causing conflicts in loading... So - we do understand that this is not optimal, agree absolutely on the input, but there are no short-term solutions which we can do. Closing due to that.

[baywet]

Thanks @VesaJuvonen for the precision. External management with SPFX has a lot of flaws currently and I think it's important the extensibility team gives a bit of love to that really soon. The more developers and organizations adopt SPFX, the more total size of SharePoint Pages is going to increase and that's going to deteriorate users' experience and their global perception of SharePoint. (kind of like the old SSOM issue with third party solutions slowing down SharePoint for everyone).
See those related issues with pnpjs
https://github.com/pnp/pnpjs/issues/226
https://github.com/pnp/pnpjs/issues/203

[OliverZeiser]

@baywet although it is offtopic: pnpjs is working for me when using the latest guidance on cdn. You might want to give it one more try and read the guidance carefully.

@VesaJuvonen I think I do understand the problem around this. But wouldn't it be an option for you to create a custom SPFx fabric-react build (custom namespace etc) that is fixed to certain version. And optionally we could use that version, or bundle the components of newer versions into our solutions?

[baywet]

@OliverZeiser are you using the taxonomy libraries as well? in an application customizer? (feel free to add your information on my issue in the pnpjs repo to avoid polluting this one)

[nishantverma-nagarro]

We got a workaround to fix this issue.
Add the CDN path and globalName of the to config.json
"externals": {
"office-ui-fabric-react": {
"path": "https://unpkg.com/[email protected]/dist/office-ui-fabric-react.min.js",
"globalName": "Fabric"
}
}

This will compile properly. However if you deploy and add the web part to a page it will through react not found error.
To remove the react error I added the CDN path to the page using SEWP on classic page. In case of Modern page you can create extension to add the react js.

Once this is done the web part loads fine.

I know this is not the correct way but this will get your web parts working and will not create large bundle files.

[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