In a business scenario, you’ll likely want to build a SharePoint Framework solution with a couple of web parts. You might also wonder how SharePoint knows which web part it should run and when. With no explicit relationship between the code and the manifest, do you need a separate project for each web part instead?
The anatomy of a SharePoint Framework project
SharePoint Framework ships with its own toolchain and a new solution structure. Compared to SharePoint solutions we built in the past, it looks like they share nothing in common but a few names. Looking at the different pieces of the project, it seems like there is no relationship between the web part manifest and the web part class where all of the code is located. And yet, SharePoint knows where to get the web part from.
For each client side web part, a SharePoint Framework project contains the following elements:
- An entry in the ./config/config.json file pointing to the intermediate web part entry file and web part manifest
- A web part manifest containing the information about the web part such as its id, version and display properties
- Web part code and other assets such as images, stylesheets, etc.
When you build a SharePoint Framework project, SharePoint Framework first transpiles files from the src folder into intermediate files. These are copied to the lib folder.
Next, using the information from the config.json file and web part’s code, SharePoint Framework uses Webpack to build a web part bundle and to update the web part manifest with additional information. The file specified as the entry in the config.json file is used by Webpack as the entry point to discover dependencies and as the entry point of the generated bundle.
The result of this step is copied to either the dist or ./temp/deploy folder, depending on the type of build that you are running.
If you look closely at the generated bundle, there is some code in there, but because the generated manifest still doesn’t specify an entry web part class, how does SharePoint know which piece of the bundle contains a web part’s code?
There is a web part at the end of the rainbow
The manifest of a client side web part generated by the SharePoint Framework points to a URL where the web part’s bundle is located. That bundle is generated by Webpack and it contains everything that the web part needs in order to run correctly: from the web part’s main code to its assets, stylesheets and other classes.
When building client side web parts, you might have noticed that every web part must inherit from the BaseClientSideWebPart class. But by itself, this is not enough for SharePoint to load a web part from a bundle. For example, if you used one *.ts file and defined two web part classes, both inheriting from the BaseClientSideWebPart, SharePoint wouldn’t load your web part. Also, if you used multiple *.ts files, each with its own web part class inheriting from the BaseClientSideWebPart, SharePoint wouldn’t load your web part.
The other ingredient that’s required by SharePoint to load the web part from the web part bundle is to mark the web part class as the default export.
For SharePoint to load a web part from the specified web part bundle, the entry file, specified in the config.json file, must define a default export class that inherits from the BaseClientSideWebPart class. This means that every web part must be defined in a separate *.ts file. That file must define the web part class as its default export.
Using SharePoint Framework, you can build solutions that consist of multiple web parts. The combination of web part manifest, web part code and entry in the config.json file instructs SharePoint where to get the code for the particular web part.
You can find Waldek’s original article here along with many other great blog posts.