Cómo estructurar React dentro de SPFx para mantener soporte, testabilidad y velocidad, incluso cuando usamos asistentes de código para acelerar.
Una de las decisiones más importantes al arrancar un proyecto SPFx es cómo estructurar la capa React. El generador de SPFx crea un componente funcional básico, pero una solución interna real necesita estado, servicios, testing y límites claros. Si además usamos GitHub Copilot, Claude Code, Codex o Gemini Code Assist, esa arquitectura importa más: la IA acelera, pero no entiende el contexto del tenant por nosotros.
El patrón que mejor resultado me ha dado es separar la solución en tres capas dentro de un mismo repo: (1) web part wrapper — solo registro SPFx, mínima lógica, (2) components — árbol React puro sin dependencias de SPFx, y (3) services — capa de acceso a datos que abstrae SPHttpClient y MSGraphClient. Esta separación permite ejecutar los componentes en un entorno React puro (Storybook, Vite dev server) durante el desarrollo, acelerando drásticamente el ciclo de feedback.
Para estado global, React Context + useReducer cubren el 90% de los casos sin añadir dependencias externas. Si la aplicación requiere caching de datos y sincronización entre web parts en la misma página, recomiendo usar la SPFx Dynamic Data API en lugar de intentar compartir estado mediante variables globales. La Dynamic Data API permite que una web part exponga propiedades y otra las consuma reactivamente, manteniendo el contrato tipado.
En cuanto a hooks, el más infrautilizado en SPFx es useRef para mantener referencias estables a servicios inicializados con el contexto de SPFx. En lugar de recrear el SPHttpClient en cada render, lo inicializo una vez en el web part wrapper y lo paso mediante un ServiceProvider context. Esto evita fugas de memoria y mejora el rendimiento percibido en páginas con múltiples web parts.
El tema del bundling merece mención aparte. SPFx 1.20+ permite externalizar React y Fluent UI como shared dependencies a nivel de tenant, lo que reduce el tamaño de cada web part de ~400KB a ~50KB. Esta configuración se activa en config.json con externals y debe coordinarse con el administrador del tenant, pero el ahorro en carga de página para intranets con 10+ web parts es muy significativo.
Para testing, la separación de capas permite usar Vitest + Testing Library directamente sobre los componentes de React sin mockear todo el runtime de SPFx. Solo los servicios que llaman a SPHttpClient necesitan un mock ligero. La inversión en arquitectura se paga dos veces: acelera la test suite y hace que cualquier ayuda de IA trabaje sobre unidades más pequeñas y revisables.