If You are working on a big project based on SPFx You might have already thought about a way to simplify reusability of Your components and maybe speed up the development process a little bit. SharePoint Framework is a great tool but sadly, it doesn’t scale so well, especially when it comes to sharing functionality and components across multiple SPFx projects.
On top of that, even with spfx-fast-serve, the build and serve process is quite slow and heavy on the memory, especially comparing to standard react app. Of course SPFx is doing much more than simple react app but during development we do not actually need it (at least that’s my experience).
Finally, it’s almost impossible to export Your SPFx web part outside of SharePoint. Sometimes You may be working on some complex application and the customer would like to place it also in some other place, but once You go SPFx, it’s almost impossible to get back.
Todays topic is quite advanced. On top of that, presented solution may not be relevant in Your case. If You rely heavily on pageContext or _spComponent loader in Your solution, this article won’t help You.
The best case for below solution is an app that uses SPFx libraries only to consume APIs (Graph, SP Rest or custom one) and doesn’t rely on global objects nor context of a page/site/web it’s deployed to.
What can we do?
For my next project I set up additional goal for myself. I wanted to try build a react app that will fulfill business requirements, then push it to private feed (or npm link) and consume in SPFx web part solution.
The obvious problem at the beginning is authentication. If I want to develop against my local developer server, as it’s usually the case with react app, I need an app registration in AAD to login and consume both Graph and SharePoint API, and if needed, my own API. Thanks to @azure/msal-browser package that won’t be a problem. Now the only thing left is proper management of dependencies, so I can use my fetch api client and spHttpClient or aadHttpClient, as once my app is consumed by SPFx I want to use SPO Extensibility Principal with authentication handled by SharePoint.
How was the development?
As You may imagine, the development process itself was great. After initial issue with authentication and custom http client it was a smooth sailing. Hot reload works great, build took seconds, You can use react profiler to improve performance and better understand lifecycle. On top of that unit testing was significantly simpler as it did not require excessive mocking of SPFx dependencies.
Another great side effect of this approach is, You can just publish your app to blob storage and serve it from there.
Once I was happy with the app, new issue emerged. How to build the solution so it can be consumed by SPFx?
Integrate with SPFx
Thankfully it turned out build is not too difficult. If You add @microsoft/rush-stack-compiler-4.5 and @microsoft/sp-build-web You can create a gulp file that will build react app same way Microsoft builds SPFx itself.
Once I switched to SPFx project I npm link my package. Then it was just a case of building http client based on aadHttpClient for MS Graph API and importing component from my library. Then in web part render method I replaced the component created during scaffolding with my own and it started to work.
Find more Microsoft Teams Week content here.
Was it worth it?
I think yes. It definitely requires some experience to understand how to set up dependencies to get most out of SP dependencies once we’re in SharePoint context but the performance of standard react app is significantly better than SPFx.
In more advances cases, You can export all Your components via SP Component Library and consume it in multiple web parts, which from performance perspective, will work wonders hosted in SharePoint.
If You’re interested how it can be set up, You can find a small sample here. In this solution I’m consuming me/insights/used endpoint to render user document cards with files they recently accessed. In App.tsx file, You can see I’m building my own graph client which I’m using from local machine. You can compare that with MyDocumentsWebPart.ts file in spfx-my-documents project, where we’re building graph client based on aadHttpClient provided by aadHttpClientFactory in web part context. Thanks to that, we don’t have to authenticate when SharePoint is the runtime.
Thanks for reading.
About the Author
Coding enthusiast, TDD evangelist, OOP champion and SOLID proponent. Likes to code as well as talking about the code.
For fun, besides software development, plays guitar, basketball and video games. Enjoys cooking and learning.
Reference
Wojciechowski, M., 2023, The ultimate full stack project setup for M365 development, Available at: https://mgwdevcom.wordpress.com/author/mgwojciechowski/ [Accessed on 15 March 2023]
