Ever wondered how to add SharePoint Framework web parts from different solutions to your local workbench while developing on localhost? Then look no further
Some time ago, I published a blog post related to a web part that I use on the hosted workbench page while creating other web parts. I have this solution deployed on my dev tenant and simply add it to the bottom of the Workbench page to work around some things that get in the way when building the UI of SPFx web parts.
The Microsoft Graph endpoints for Teams are not something new. You can easily find online multiple blog posts containing sample requests on how to retrieve the teams that a user is a member of. Instead, in this blog post, I will share some code blocks that I used to accomplish this on a SharePoint Framework project.
With SharePoint Framework, Microsoft also introduced a really good development story for creating custom web parts: the Workbench page. This page is not only available when you are developing solutions locally, but also on a SharePoint site. This gives you the option to access data on a SharePoint site from code running on your machine. Let's be honest, it's great! But it dies have some limitations...
There are plenty of solutions available online, from complete implementations to blog posts with the relevant code snippets, but I was also unable to find one that was able to track full and partial page loads, so I decided to tweak one to work on the required scenarios.
If you know me or follow me on Twitter/LinkedIn, you must have realized by now how much I like the PnPjs library. But this library will hopefully get even better soon by providing support for Project Online REST API!
The SPFx Workbench page is fantastic. You can use the local version to run your code locally, or you can use the online hosted version to test your code against your site. But it has some limitations.
About 2 weeks ago, I published a blog post on how to use pnpm with SPFx 1.6.0 and the required steps to have a working solution. Today, I was reviewing the comments and noticed someone was having issues with SPFx 1.7.0, so decided to give it a go.
Last weekend, I had the pleasure of speaking at SharePoint Saturday Leicester. Very well organized event and with a good number of attendees, especially considering that it was the first event.
When you create a new SharePoint Framework project, you have the option to use different package managers: npm, pnpm or yarn. For a long time, I completely ignored this and just used npm. Npm is the slowest option from the list above, but it didn't really matter as I was installing packages once a week or so. But this is not the case anymore. Simple processes, like upgrading your existing solutions to newer versions of the SharePoint Framework can make you go through that process more times than desired.