 Microsoft released the SharePoint framework in early 2017 after initially introducing it to the world in concept at their May 2016 event. One set of questions I seem to keep going back to is explaining the what the SharePoint framework is and why did Microsoft create it. And I thought about it and I finally realized that there really isn't some definitive body of work that answers the most basic questions about the SharePoint framework. You know those questions, the ones that refer to as the 5Ws or sometimes the 5W in the 1H, is the classic what, why, when, how, where and who. Have you ever wanted to know how the SharePoint framework works? How do your components get added to the page? And what's with that extra manifest file? In this episode, I'm gonna answer all these questions. Hey, I'm Andrew Connell. In this piece of my series, it's gonna take a different direction than the rest of the other episodes. In the other episodes in the series, there have been much more of a high level look at things more from a decision maker perspective. I wrote them for developers and development market managers and I tried to stay out of like a lot of the detailed technical stuff. But in this episode, I wanna get my hands dirty and I wanna take you into the depths of the SharePoint framework. And while this episode is really for you, it may be more so for me. The points I'm gonna cover address questions that I answer over and over. And so with this episode, I can now point to a reference that I don't have anywhere else. So let's get started. The most important thing to know about the SharePoint framework is that it's a 100% client-side technology. And this means that it only runs in the browser. So when you build solutions, they're only client-side, they're not server-side. And with that being said, you can implement a scenario where your SharePoint framework components call server-side components that you've deployed, such as a REST API. But that the API doesn't have anything to do with your SharePoint framework component. And as I covered in my other episode on who and where can use the SharePoint framework, SharePoint has specific places that are carved out that you can use the SPFX to customize. These include web part zones, the top and bottom placeholder for extensions, field customizers and command sets for the different types of extensions. When a page is requested, SharePoint first creates the page source for the page and the structure of the page before sending it to the client. Some components are loaded asynchronously in the browser, such as parts of the suite bar that we have at the very top of Microsoft 365. But when it comes to the SharePoint framework, SharePoint first determines, are there any SPFX components that have been added to the requested page? And if so, SharePoint's gonna load the SPFX runtime on that page. Otherwise, it doesn't load it. So as I've said previously, 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 and add the unnecessary bloat of the payload in all those JavaScript libraries. So what happens when the SPFX runtime actually loads? Ah, now we get to the real business of this post. Let's start getting low level. Now, when I said that SharePoint detects that there's any SharePoint framework components on the requested page, it loads the runtime, right? But what does that really mean? 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. And once it has that list, it needs to know everything about that component. Specifically, it needs to know about that component's dependencies, including the JavaScript bundle that represents that component. This information is spread across two manifest files, one that contains a list of all the components that are available in SharePoint. We'll call this the SPFX master manifest. And while the component has its own manifest that defines its own dependencies, I'm gonna call that the SPFX component manifest. So let's look at this first manifest file. The SPFX master manifest file contains a list of all the components that could be on the page. And this is a collection of all the components that are installed to the tenant app catalog and the current site collections 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. Think of it like the snippet that I'm showing you here. It's not real, but it basically conveys the concept that I'm trying to portray. The manifest acts like a directory for SharePoint framework. Once it has this list, it then moves on to the next step to get all the components on the page. Now that the SPFX runtime has a directory of everything it can be on the page, it then uses this list to figure out what to load. The SPFX runtime then starts working through all the components that should be on the page. It finds them in the directory and it uses the information it gets to load the dependencies for that component. This is where things start to get a little interesting. Let's take our custom web part, for example. Let's assume that our web part leverages the popular jQuery data tables plugin. Not only will the SPFX runtime need to load the data tables plugin library, but it also needs to load jQuery. Our web part in any other SPFX components that we may be using, such as the at Microsoft SP HTTP component and certainly the at Microsoft SP web part base packages. Many of the SPFX packages have already been added to your project when you ran the Yeoman SharePoint Generator. Now take a look at your package.json file and you're gonna see these things are listed out for your web part. So you got a bunch of dependencies and you got things like the core library, the load-subset, the Office UI Fabric Core and a couple other ones. These are all needed by your component, but you also have additional components as well. You may have installed the jQuery data tables, jQuery library and the data tables plugin using the npm install command. So in that case, your package json might have those listed in there as well under the list of dependencies. But you're a smart SharePoint framework developer. You know that you shouldn't be putting jQuery in the data tables plugin inside your resulting components bundle. You went to your projects config.json file to add these as external dependencies. This tells the SharePoint framework, the bundling process of the SharePoint framework, don't suck these files into the resulting bundle. Instead, you wanna tell the SharePoint framework to make sure that it downloads the jQuery and the data tables plugin libraries in a specific order before my web part is actually gonna be loaded. Pull them from a CDN. The order that these libraries are loaded on the page is absolutely critical. If your web part bundle is loaded before jQuery or the data tables plugin is added on the page, things are gonna break because there's assumption that they're already on the page. The SPFX bundling process takes this into account for you. The SPFX bundling process takes this into account for you. Now the SharePoint framework documentation, it addresses how the bundling process works, but most of it only focuses on the creation of a bundle. The other thing the bundling process does is it generates the SPFX component manifest file as well. Take a look. After you run the gulp task, gulp bundle, you're gonna see two files in your distribution folder. There's a JavaScript file that's the actual bundle of your project, and then there's the manifest.json file that's the components manifest. Within this file, you're gonna find this object called loader config. Now loader config contains three properties. It's got the entry module ID, which is the name of the JavaScript module that contains the main SPFX component. The internal module base URL, that's the base URL where any non-absolute URLs are listed in the manifest are gonna be located. So like in this example, they're all in localhost. And then also a script resources section. And that's a name value collection of all the libraries and all the components that the SharePoint framework components need to run. Now that last property, the script resources, that's the interesting one. This contains a list that's sorted in reverse order of everything that must be loaded for the component to work. So for my web part to work, the one that used the data tables jQuery library, it's gonna be listed here. Notice that the last few listed are components. These are the SPFX runtime out of the box components that you should already be on the page. But also notice how the bundle that contains our SharePoint framework web part is listed at the top. It comes after the data tables plugin, which comes after the jQuery library. So what the SPFX runtime is doing is it's using something called a module loader on the page to handle the process of loading all the necessary libraries. Let me talk a little bit about module loaders for a second because SharePoint framework, they change module loaders over time that it uses to load these different modules. Initially, the SharePoint framework was using the popular module loader system, system.js. But when they released the SharePoint framework 1.10, the release notes state that they were moving to another library called require.js, which is also very popular. This doesn't really matter to you. We don't really care about this. I mentioned them just in case you wanna go read up on how these things actually work. And you know what the SharePoint team is using. While Microsoft hasn't stated it, I expected only SharePoint online is gonna switch over to require.js, while SharePoint Server 2016 and SharePoint Server 2019 are gonna continue to use system.js because they're not making any changes to the SharePoint framework and on-prem deployments. Now, the module loader is smart enough to know that the dependency has already been loaded on the page from another components dependency tree. So when it knows that, it's not gonna load it a second time. But how are components added to the page? Once the components modules or the JavaScript files are loaded on the page, how is it then added to the page? When the SharePoint framework loads the final module, it creates an instance of the object that's defined in the property entry module ID. And it calls one of the expected methods that you can define. For instance, to add HTML to the page for a web part, you can implement the render method on the base web part class. The object your web parts class is derived from, called base client-side web part, it provides a property DOM element that's a reference to the div that SharePoint has added to the page where your component should go based on where the user specified it was loaded. Okay, so now that you understand how they get on the page, you might wonder how the hosted workbench and the debugging extensions are gonna be impacted by this. So let's first talk a little bit about the hosted workbench. When you navigate to the hosted workbench that's located at whatever your SharePoint site is slash underscore layout slash workbench.aspx, if you haven't spun up your local developer web server by running gulp serve, you get this dialogue message that says that the web part's not gonna appear in the toolbox. So make sure that gulp serve is running in a web part project. The reason you get this is because the workbench is asking for an additional manifest file. Not only does it get the manifest file from SharePoint to list everything that's available, but it also requests a manifest file from the local host colon 4321 slash temp slash manifest.js. And you can see that in the console when you're actually debugging your solution. This file contains the same manifest details that the SharePoint framework runtime gets in this SPFX master manifest, but only the components that you're developing in your project are listed in that manifest. So when you started the local workbench, the local development server using the gulp serve command, the SPFX workbench merges the collection of manifest that it receives from your web server and the one that the SharePoint framework has in their master manifest into one giant collection and it presents it to you in the toolbox, which is giving you the list of all the components that you can put on a page. Now, this is great for testing web parts, right? We see how that works, but what about extensions? Well, unfortunately, the SPFX hosted workbench can't debug extensions. To debug extensions, you need a real SharePoint page. And in the case of a field customizer or a command set, you actually need a real SharePoint list or a SharePoint library. But to test a component on a real SharePoint page, you've got to tell SharePoint that that's what you want to do. And this is done by using a specially crafted URL that includes parameters to tell SharePoint to do a couple of different things. It says, if the SharePoint framework isn't already loaded on the page, then load it on the page. Because if there was no SharePoint framework components already on the page, SharePoint wasn't going to add the extra payload of all the JavaScript for the SharePoint framework to the page and make you download it if it wasn't going to use it. It then also tells it says the SharePoint runtime should also load the manifest.js file from your local development server. And then it also says what component should load in anything that's unique about that specific component. Thankfully, SharePoint framework extension projects will create this URL for you based on the values that you set in the serve.json file. Now let's take a look at this URL. And I've broken it up to make it a little bit more readable here. You're gonna notice a few properties in the URL. Load SPFX equals true tells SharePoint to load the SharePoint framework runtime if it isn't already loaded on the page, which would be the case if the page you're using to test your extension has no other SPFX components on it. The property debug manifest file tells the SharePoint framework runtime where to load the manifest file from. That's my local machine. And then the custom actions property is a JSON object that URL encoded that contains the details about the component. So in this example that you're looking at, you can see that we are telling the SharePoint framework runtime to load the component that starts with the ID of FCA is listed in the debug manifest file on the page. Now, the remaining information is specific to the component. So like in this case, it tells the SharePoint framework that this is an application customizer and that it sets its public properties. And when it's a field customizer, it'll also contain the internal name of the field or the site column that the customizer should override for testing. And you'll notice this when you use the URL, you're presented with this warning that you see here. This is presented by SharePoint when the SharePoint framework is asked to load a manifest from an untrusted location, like local host, such as your local web server. Think about it. This would be a fantastic opportunity for a phishing attack to get some random script loaded in your corporate intranet because once it's loaded, it'll run under your context and thus have all the permissions that you have the user that's running it. Makes sense, right? Or not? If it doesn't, leave a comment. I definitely, I'll jump back and I'll respond to you and clear it up for you. So my goal in this episode was to answer the question of how does the SharePoint framework work? So by now you should have a really strong grasp on how the SharePoint framework works, how components are added to the page, and how you debug extensions on modern pages. Let me know what you thought of this video or if you've got any questions by leaving a comment down below this video. And if you liked this, please be sure to hit that big thumbs up button. And if you're new here, make sure you subscribe. Don't forget to check out the description below the video for links and resources that I mentioned throughout the video. Thanks for watching and I'll see you in the next video.