SPFx antes de la versión 1.0: tres web parts nuestras en los samples oficiales de Microsoft

La developer preview de SharePoint Framework salió en agosto de 2016. La versión 1.0.0 quedó disponible el 22 de febrero de 2017.

Nuestra primera contribución a pnp/sp-dev-fx-webparts, el repositorio oficial de samples de la comunidad Microsoft 365, se integró el 6 de octubre de 2016. Cinco meses antes de que existiera una 1.0 sobre la que construir.

Es la parte de una trayectoria que no se puede reclamar después. Tres de nuestras web parts están hoy en ese repositorio, al alcance de quien quiera leerlas. Esto es lo que hace cada una.

Consumir una base Northwind a través de una Azure Function

Una página de SharePoint necesita datos que no viven en SharePoint. El instinto es ir directamente a la base de datos, y ese instinto sale caro: pone una cadena de conexión delante del navegador, ata la página a un esquema, y convierte cada cambio futuro de ese esquema en un cambio de la página.

Esta web part llama a un HTTP trigger anónimo en una Azure Function App y muestra lo que vuelve. La web part nunca sabe que hay una base de datos. Sabe que hay un endpoint, y es el endpoint el que decide qué significa la pregunta y quién puede hacerla.

Es deliberadamente sin brillo, y es el diseño que usamos en trabajo de cliente cuando SharePoint tiene que mostrar algo que pertenece a otro sistema. La ingeniería interesante no está en la web part. Está en la frontera.

Carbon Footprint Calculator

Una calculadora interactiva que estima la huella de carbono mensual a partir de electricidad, transporte, calefacción y agua, descompone el resultado por origen, y lo exporta a PDF. React, Fluent UI y Chart.js.

La construimos porque necesitábamos una para nuestro propio informe de sostenibilidad, y las opciones honestas eran una hoja de cálculo que nadie abría o un sitio externo que se llevaba los números a donde no los veíamos. Siendo web part, los datos nunca salen del tenant. Es esa restricción la que explica la forma que tiene.

Es también una respuesta que funciona a una pregunta que nos hacen mucho: si una herramienta interna puede ser realmente útil sin convertirse en otro sistema que mantener. Esta es una web part en una página. No hay base de datos, no hay servicio, no hay autenticación aparte, y no hay nada que desmantelar más tarde.

Public Holidays Global

Muestra los festivos de un país y año a elegir, con paginación y gráfico, leyendo en tiempo real de la API pública Nager.Date.

Nació de una irritación corriente en una organización con personas en más de un país: la respuesta a quién falta el próximo martes vive en la cabeza de alguien, o en una lista que dejó de mantenerse en marzo. Los datos ya existen y se consultan gratis.

La web part es delgada a propósito. No guarda nada, porque un calendario de festivos guardado es algo que se queda desactualizado en silencio y sigue mereciendo confianza igualmente. Si la lista de países cambia el año que viene, nadie tiene que acordarse de actualizar nada.

Por qué están públicas

Porque una afirmación sobre competencia vale menos que la posibilidad de comprobarla.

Quien esté decidiendo si trabaja con nosotros en SharePoint puede leer el código en lugar de creer en nuestra palabra. Puede ver cómo tratamos una API de terceros, dónde ponemos la frontera entre la página y los datos, qué hacemos con las versiones y la compatibilidad, y si aquello compila. Es una afirmación más fuerte que una descripción de nuestra experiencia, y comprobarla no le cuesta nada a quien lee.

Hay una segunda razón, que cuenta más puertas adentro. Los samples de ese repositorio se validan contra reglas de contribución y los leen personas que ya han visto miles. Publicar ahí significa que nuestro trabajo en SPFx lo revisa gente sin ningún motivo para ser amable.

De qué va esto en realidad

SPFx va por la versión 1.23 y ha atravesado una década de versiones de Node, cadenas de compilación, cambios mayores de React y deprecaciones. La mayor parte de la dificultad en un front end de SharePoint nunca fue el framework. Es saber qué partes son lo bastante estables para construir el sistema de un cliente, y qué partes desaparecen en dos años.

Ese criterio viene de haber estado presente en las versiones que ya no existen. Llevamos estos samples por esos ciclos, y hemos escrito sobre lo que cuesta en la práctica, en SPFx 1.23.2: actualizar no es cambiar un número y en el estado de SharePoint en 2026.

Si está construyendo sobre SharePoint y quiere el front end hecho por quienes ya estaban antes de la versión 1.0, hable con nosotros. El código es público. Empiece por leerlo.