Access to script root of a web part and dynamic loading of resources

[wobba]

Category

• Question
• Typo
• Bug
• Additional article idea

I wrote a post about loading resources from within the asset bundle (script, react components) only needed in edit mode at
https://www.techmikael.com/2018/08/an-adventure-into-optimizing-sharepoint.html

This could also be dynamic components loaded in any UI mode.

Right now we need to resort to custom gulp tasks to add files to be included into the .sppkg file, and getting the script URL where the bundle is served from is tricky. Pre v1.5 we could get it via context.manifests etc, but those properties have been «hidden» in v1.5. Which is why I decided to use a dummy image instead to go the supported route.

Ideally we would be able to reference scripts via the externals config section, and decide if the script is loaded automatically at runtime, or dynamically via SPComponentLoader. This would make it far easier to create runtime optimized web parts and extensions, loading and bootstrapping as little .js as possible per page, and load more as needed in the life cycle of the page. Having larger .js files loaded later is often more beneficial compared to loading large bundles up front.

I have employed this pattern to the modern script editor web part and to the react search refiner sample so far. Greatly reducing initial loading and bootstrapping.

Thoughts or comments around this?

[patmill]

Hey @wobba - Quick question. How much of what you want to achieve can be wrapped into a "when the property pane loads and the user interacts with it" vs. "when the page is in edit mode, and the user interacts with the webpart on the canvas"?

[wobba]

@patmill When the prop pane loads is fine. If loading would be 100% dynamic at will in any mode, like my sample, better. But a separate prop pane load would solve a lot.

[patmill]

So, give this a try and let me know how it works for you:

1 - create a file in your source (say, HelloWorldWebPartPropertyPaneStuff.ts)
2 - Move all your property pane related code to it.
3 - Create the following method in your main webpart class

  protected loadPropertyPaneResources(): Promise<void> {
    return import(
      /* webpackChunkName: 'HelloWorldWebPartPropertyPaneStuff' */
      './HelloWorldWebPartPropertyPaneStuff'
    ).then(component => {
      this._propertyPaneHelper = new component.HelloWorldWebPartPropertyPaneStuff(this);
    });
  }

4 - Rebuild.

From there, you should get a chunk loaded before the property pane is loaded, but not until then.

Let me know if that works for you.

[wobba]

I’ll try this tomorrow, and looks very interesting indeed.

[wobba]

@patmill Ok.. this is like the coolest thing in a long time of SPFx. And I've tried adding the import line anywhere in my code - and it loads dynamically. This seems by far the best way to load dynamic code combined with ease of programming.

Would it be ok to document this officially that adding the webpackChunkName part allows you to break it up.

cc @wictorwilen @waldekmastykarz

[wictorwilen]

This is a really nice method, which should be documented!!!

But - this really doesn't solve the enterprise scenario where you want to share code across projects and dynamically load that without having the same code over and over again in multiple bundles.
We have solved this by using an extension exposing classes (defined by interfaces) and then used the (now deprecated) methods to load libraries. This allowed for one instance of code, loaded once on the page, for "things" (controls, utilities, data providers) we would like to share across web parts and extensions. (see issue #2376)

[wobba]

@wictorwilen Agree, and having both would be ideal. If we could have a library type SPFx project - even better - which could be loaded by the SPComponentLoader. Sort of my idea how display templates could be done in SPFx.

[patmill]

Cool, glad to see it works for you. And agreed - this is a solution to a different (but somewhat related) scenario than Libraries. This is less about sharing code across components, and more about separating what code gets loaded at any given time.

I'll talk to @VesaJuvonen about docs around this.

[wobba]

@patmill Updated script editor wp with this: https://github.com/SharePoint/sp-dev-fx-webparts/blob/dev/samples/react-script-editor/src/webparts/scriptEditor/ScriptEditorWebPart.ts#L39

works like a charm!

[VesaJuvonen]

Reopening until it's documented... as unless it's documented, it's not officially supported. Will get this included on the upcoming changes and closing this issue when docs are available.

[VesaJuvonen]

On @wictorwilen's comment - "But - this really doesn't solve the enterprise scenario where you want to share code across projects and dynamically load that without having the same code over and over again in multiple bundles."

We do have this item in backlog and it's seriously in plans to get out, but we can't provide ETA for now. Waiting for resources to get assigned to it, which should happen soon.