SPFx before version 1.0: three of our web parts in the official Microsoft samples

The SharePoint Framework developer preview was released in August 2016. Version 1.0.0 became generally available on 22 February 2017.

Our first contribution to pnp/sp-dev-fx-webparts, the official Microsoft 365 community samples repository, was merged on 6 October 2016. Five months before there was a 1.0 to build against.

That is the part of a track record that cannot be claimed retroactively. Three of our web parts are in that repository today, readable by anyone. This is what each one is for.

Consume a Northwind database through an Azure Function

A SharePoint page needs data that does not live in SharePoint. The instinct is to reach for the database directly, and that instinct is expensive: it puts a connection string in front of the browser, ties the page to a schema, and makes every future change to that schema a change to the page.

This web part calls an anonymous HTTP trigger on an Azure Function App and renders what comes back. The web part never knows there is a database. It knows there is an endpoint, and the endpoint decides what the question means and who is allowed to ask it.

It is deliberately unglamorous, and it is the shape we use in client work when SharePoint needs to show something that belongs to another system. The interesting engineering is not in the web part. It is in the boundary.

Carbon Footprint Calculator

An interactive calculator that estimates a monthly carbon footprint from electricity, transport, heating and water, breaks the result down by source, and exports it to PDF. React, Fluent UI and Chart.js.

We built it because we needed one for our own sustainability reporting, and the honest options were a spreadsheet nobody opened or an external site that took the numbers somewhere we could not see. As a web part, the data never leaves the tenant. That constraint is why it exists in this form.

It is also a working answer to a question we are often asked: whether an internal tool can be genuinely useful without becoming another system to maintain. This one is a web part on a page. There is no database, no service, no separate login, and nothing to decommission later.

Public Holidays Global

Shows public holidays for a chosen country and year, with pagination and a chart, reading live from the Nager.Date public API.

It came from an ordinary irritation in an organisation with people in more than one country: the answer to who is off next Tuesday lives in somebody's head, or in a list that stopped being maintained in March. The data already exists and is free to query.

The web part is thin on purpose. It stores nothing, because a stored holiday calendar is a thing that quietly goes stale and then gets trusted anyway. If the country list changes next year, nobody has to remember to update anything.

Why they are public

Because a claim about competence is worth less than the ability to check it.

Anyone deciding whether to work with us on SharePoint can read the code rather than take our word for it. They can see how we handle a third-party API, where we put the boundary between the page and the data, what we do about versions and compatibility, and whether the thing builds. That is a stronger statement than a description of our experience, and it costs the reader nothing to verify.

There is a second reason that matters more inside the company. Samples in that repository are validated against contribution rules and read by maintainers who have seen thousands of them. Publishing there means our SPFx work is reviewed by people with no reason to be kind about it.

What this is actually about

SPFx is now on version 1.23 and has been through a decade of Node versions, build chains, React majors and deprecations. Most of the difficulty in a SharePoint front end has never been the framework. It is knowing which parts of it are stable enough to build a client's system on, and which parts will be gone in two years.

That judgement comes from having been there for the versions that are already gone. We have carried these samples through those cycles, and we have written about what it costs in practice, in SPFx 1.23.2: upgrading is not changing a number and in the state of SharePoint in 2026.

If you are building on SharePoint and want the front end done by people who were there before version 1.0, talk to us. The code is public. Start by reading it.