How does the SharePoint Framework (SPFx) work?

Have you ever wanted to know how the SharePoint Framework works? How do your components get added to the page? What's with that extra manifest file? In this post, I'll answer all those questions!

by Andrew Connell

Last updated September 21, 2024

SharePoint Framework at a high-level

The most important thing to know about the SPFx is that it is a 100% client-side technology. This means that it only runs in the browser. When you build solutions, they are only client-side, not server side.

When a page is requested, SharePoint first creates the page source for the structure of the page before sending it to the client. Some components load asynchronously in the browser, such as parts of the suite bar.

When it comes to SPFx, SharePoint first determines if there are any SPFx components that have been added to the requested page. If so, SharePoint will load the SPFx runtime on the page. Otherwise, it doesn’t load it; as I said above, SPFx is entirely client-side and if there aren’t any components on the page, it doesn’t need to add the runtime to the page response and unnecessarily bloat the payload.

SharePoint Framework at a low-level

The SPFx runtime is just a bunch of JavaScript. When the page loads, it gets a list of all the components that should be on the page. Once it has that list, it needs to know everything about that component. Specifically, it needs to know about the component’s dependencies including the JavaScript bundle that represents that component. This information is spread across two manifest files: one contains a list of all components available in SharePoint (let’s call this the SPFx master manifest) while each component has its own manifest that defines its dependencies (this is called the SPFx component manifest).

Generate a list of all components - the SPFx master manifest

The SPFx master manifest contains a list of all the components that could be on the page. This is a collection of the components installed to the tenant app catalog and the current site collection’s app catalog. Think of this list as just an array of name-value pairs. Each entry is for the SPFx component ID and it points to the URL of the component’s manifest file.

Load SPFx components on the page

Now that the SPFx runtime has a directory of everything that can be on the page, it then uses this list to figure out what to load. The SPFx runtime then starts working through all components that should be on the page, finds them in this directory, and uses the information it gets to load the dependencies for the component.

SharePoint Framework's Use of Module Loaders

The SPFx has changed module loaders over time that it uses to load the different modules. Initially the SPFx was using the popular module loader system.js to load the modules, but in the SPFx v1.10.0 release notes from January 2020 they stated they were moving to another popular module loader: require.js.

How are components added to the page?

Once a component’s modules (aka: JavaScript files) are loaded on the page, how is it added to the page?

When the SPFx loads the final module, it creates an instance of the object in the defined entryModuleId and calls one of the expected methods you can define. For instance, to add HTML to the page in a web part, you implement the render() method.

Conclusion

My goal in this post was to answer the question How does the SharePoint Framework work? By now you should have a good grasp on how the SPFx runtime works, how components are added to the page and how to debug extensions on modern pages.

Author: Andrew Connell
Microsoft MVP, Full-Stack Developer & Chief Course Artisan - Voitanos LLC.