Building Pages with Web Parts

Analogy categoryAnalogies

A modern SharePoint page is built by dragging web parts onto a canvas of sections and columns. Each web part — Text, Image, News, Highlighted Content, Embed, or a custom SPFx web part — is an independent, configurable component with its own property pane, and the page itself is just an ordered JSON list of these components stored in the Site Pages library.

🏏

Cricket analogy: Assembling a page from web parts is like a captain picking a playing XI — batsmen, bowlers, an all-rounder like Ravindra Jadeja — where each player is a modular unit slotted into a specific role on the field.

Adding and Configuring Web Parts

To add a web part, hover between existing content on a modern page and click the plus icon, which opens a searchable toolbox of over 40 built-in web parts. Selecting a web part like Highlighted Content lets you configure its property pane to filter by source (this site, a specific site, or a whole hub), content type, or a managed metadata tag, and preview the results live without leaving the page.

🏏

Cricket analogy: Configuring the Highlighted Content web part to filter by tag is like a selector filtering domestic scorecards by strike rate to shortlist players for an IPL auction, narrowing a large pool down to exactly what's relevant.

Third-Party and Custom Web Parts (SPFx)

Custom web parts are built with the SharePoint Framework (SPFx) using TypeScript and React or plain JavaScript, packaged into a .sppkg solution, and deployed to the tenant or site App Catalog. Once deployed and added to a page, a custom SPFx web part behaves identically to a built-in one in the toolbox, complete with its own property pane defined in code, and it can call SharePoint's REST API or Microsoft Graph to pull live data.

🏏

Cricket analogy: Building a custom SPFx web part is like a franchise developing its own bespoke fielding-analytics tool in-house, using the same broadcast data feed as the official Hawk-Eye system but tailored to their specific coaching needs.

typescript

import { BaseClientSideWebPart, IPropertyPaneConfiguration, PropertyPaneTextField } from '@microsoft/sp-webpart-base';

export interface IAnnouncementsWebPartProps {
  title: string;
  maxItems: number;
}

export default class AnnouncementsWebPart extends BaseClientSideWebPart<IAnnouncementsWebPartProps> {
  public render(): void {
    this.domElement.innerHTML = `
      <div class="announcements">
        <h2>${this.properties.title}</h2>
        <div id="items">Loading top ${this.properties.maxItems} items...</div>
      </div>`;
  }

  protected getPropertyPaneConfiguration(): IPropertyPaneConfiguration {
    return {
      pages: [{
        header: { description: 'Configure the Announcements web part' },
        groups: [{
          groupName: 'Settings',
          groupFields: [
            PropertyPaneTextField('title', { label: 'Title' }),
            PropertyPaneTextField('maxItems', { label: 'Max items to show' })
          ]
        }]
      }]
    };
  }
}

The SharePoint Framework toolchain (Yeoman generator + gulp) bundles web parts into a single .sppkg package; deploying it to the tenant App Catalog once makes the web part available site-wide, or you can scope deployment to a single site collection's App Catalog for more controlled rollout.

Web parts that call Microsoft Graph or external APIs need explicit API permission approval in the SharePoint Admin Center (API access page) before they will work for end users — forgetting this step is one of the most common causes of a custom web part failing silently in production.

Modern pages are assembled from independent, configurable web parts stored as JSON in CanvasContent1.
The built-in toolbox offers 40+ web parts including Text, Image, News, Highlighted Content, and Embed.
Highlighted Content can filter by site, content type, or managed metadata tag with a live preview.
Custom web parts are built with SPFx (TypeScript/React), packaged as .sppkg, and deployed via the App Catalog.
A custom SPFx web part behaves identically to a built-in one once added to the toolbox.
SPFx web parts can call SharePoint REST API or Microsoft Graph for live data.
Graph/API-calling web parts require explicit permission approval in the SharePoint Admin Center.

Practice what you learned

1. What format is a page's web part layout stored in?

2. Which technology stack is used to build custom SharePoint web parts?

3. Where are custom SPFx solutions deployed for use across a tenant or site?

4. What must be approved before a web part calling Microsoft Graph will work for end users?

5. What does the Highlighted Content web part let you filter by?

Was this page helpful?

Modern vs Classic Pages

News and Communication Sites

Related Study Notes in Programming

Browse all study notes

Programming

Apache Spark Study Notes

Programming · 30 topics

Programming

Apache Flink Study Notes

Programming · 30 topics

Programming

Hadoop Study Notes

Programming · 30 topics

Programming

Snowflake Study Notes

Programming · 30 topics

Programming

Apache Airflow Study Notes

Programming · 30 topics

Programming

dbt (Data Build Tool) Study Notes

Programming · 30 topics

Topics covered

#Programming#SharePointStudyNotes#BuildingPagesWithWebParts#Building#Pages#Web#Parts#WebDevelopment#StudyNotes#SkillVeris

Building Pages with Web Parts