Debugging SharePoint Framework solutions which use the Microsoft Graph just works

In a recent version of the SharePoint Framework, Microsoft released a new way to connect to the Microsoft Graph. While initially, debugging solutions using this new client was inconvenient, the issue has been fixed and things just work as expected.

Debugging the way it’s supposed to work

When you build a SharePoint Framework solution, you can easily debug it by executing the gulp serve command. This command starts a local web server on your developer machine and opens the local SharePoint Workbench in the web browser. In the workbench, you can then add your web part to the canvas to verify that it’s working as expected.

Inconvenient debugging solutions which use the MSGraphClient

In a recent version of the SharePoint Framework, Microsoft released the MSGraphClient - a new class to simplify connecting to the Microsoft Graph. Instead of having to implement ADAL JS yourself, you can use the MSGraphClient and with a single API call get a valid access token to the Microsoft Graph. Unfortunately, until recently, using the MSGraphClient had one serious disadvantage.

Debugging solutions using the MSGraphClient isn’t possible in the local workbench. In a way that’s understandable, since in order to obtain an access token, the SharePoint Framework requires the context of a SharePoint site so that it can complete the authentication flow. But if you tried to debug a local web part using the MSGraphClient in the hosted workbench or on a modern page, all you would see, was the following error message:

sp-client-preview.js:128 Uncaught (in promise) TypeError: Cannot read property 'PROD_OAUTH_TOKEN_URL' of undefined

Developers working with the MSGraphClient, logged the issue on GitHub in the sp-dev-docs repo, where it was confirmed by the SharePoint engineering team. As a temporary workaround, in order to test your solution, you had to deploy the package with your solution to the app catalog, which would cause your solution to work as expected.

Debugging SharePoint Framework solutions which use the MSGraphClient just works

It turns out, that the issue has been fixed recently, and debugging SharePoint Framework solutions that use the MSGraphClient, just works the way you would expect it to.

When you start your local web server using the gulp serve --nobrowser command, navigate to the hosted workbench and add your web part to the canvas. Assuming that you have the right API permissions configured in your tenant, you will see your web part just working.

Apparently some tenants still experience the original issue. But seeing some tenants fixed, would indicate, that the fix is rolling out and should be available to all tenants soon.

What was wrong

It seems, that the issue was caused by the @microsoft/sp-client-preview package, that defines the MSGraphClient and which expects the @microsoft/sp-http package to provide the base URL of the Microsoft Graph. Because that URL wasn’t available, all you saw, was a runtime error.

What we see in the hosted workbench today, is that it loads the @microsoft/sp-client-preview package from SharePoint Online instead of the local web server. The version of the package hosted online is newer and contains a slightly different implementation of the MSGraphClient that works as expected.

Try it today

If you’re building enterprise solutions using the SharePoint Framework, you will either need to connect to an enterprise API or the Microsoft Graph. Using the recently added MSGraphClient and AadHttpClient simplifies it a lot. For more information about these clients and how to use them, check out the official documentation for AadHttpClient and MSGraphClient.