SPFx antes de la versión 1.0: nuestras web parts en los samples oficiales de Microsoft
La developer preview de SharePoint Framework salió en agosto de 2016. La versión 1.0 llegó en febrero de 2017. Nuestra primera contribución al repositorio oficial de samples de Microsoft 365 es de octubre de 2016, cinco meses antes de que hubiera una 1.0 sobre la que construir. Cuatro de nuestras web parts están hoy en ese repositorio, y esto es lo que hace cada una.
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. Cuatro de nuestras web parts están hoy en ese repositorio, al alcance de quien quiera leerlas, y Microsoft lista las cuatro a nuestro nombre en su Sample Solution Gallery. La más reciente se integró el 3 de agosto de 2026, el mismo día en que dos de las antiguas volvieron a integrarse tras ser reescritas. 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.
Microsoft 365 Search Hub
Busca documentos, páginas, sitios y elementos de lista a través de la Microsoft Search API en Microsoft Graph, desde una sola caja, y dice de cada resultado dónde vive y quién lo cambió por última vez. SPFx 1.23.2, cadena de compilación Heft, Fluent UI v9.
SharePoint ya tiene una búsqueda excelente y esta no intenta sustituirla. Sirve para el caso en que la búsqueda que viene en la caja no encaja en el problema: una página donde buscar pertenece entre las demás cosas de esa página, en lugar de mandar a la persona a un centro de búsqueda y quitarle el contexto en el que estaba, o un portal donde solo merece la pena buscar en un determinado conjunto de sitios.
La caja de búsqueda es la parte menos interesante. Lo que merece la pena leer está debajo: mantener separados el servicio, la sesión y la interfaz, para que la concurrencia viva en un solo sitio en lugar de repartida por los componentes; distinguir un permiso denegado de una sesión caducada, de throttling, de un servicio con un mal día, porque cada una de esas cosas necesita palabras distintas en la pantalla; y probar el debounce, las respuestas superadas, una caché corta y la paginación, carreras incluidas, sin renderizador.
Y donde para, para a propósito. Personas, mensajes de Teams, correo y calendario son cada uno un tipo de entidad distinto en la Search API, cada uno con su permiso y su petición. Añadir uno de ellos es otro sample, no una versión mayor de este, y decirlo en el README forma parte del sample.
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. Llevar un sample hacia adelante es el mismo trabajo que llevar hacia adelante la web part de un cliente, y deja rastro: el 3 de agosto de 2026 la calculadora y la web part de los festivos se reintegraron ambas tras ser reescritas, y el sample más reciente entró ya en 1.23.2. 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.

