Sp-dev-docs: 'Cannot read property 'id' of undefined' error when trying to debug a web part using MSGraphClient in the hosted workbench

Created on 1 May 2018  路  12Comments  路  Source: SharePoint/sp-dev-docs

Category

  • [ ] Question
  • [ ] Typo
  • [x] Bug
  • [ ] Additional article idea

Expected or Desired Behavior

Be able to debug web part using MSGraphClient in the hosted workbench while serving from the local web server.

Observed Behavior

After adding the web part to the page, you get the following error in the console:

sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:283 Uncaught (in promise) TypeError: Cannot read property 'id' of undefined
    at e.consume (sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:283)
    at sp-client-preview.js:94
    at e._processPendingCallbacks (sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:283)
    at e.consume (sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:283)
    at e.consume (sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:283)
    at e.consume (sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:283)
    at PersonalCalendarWebPart.render (PersonalCalendarWebPart.ts:33)
    at t (sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:569)
    at PersonalCalendarWebPart.t._renderWithAccessibleTitle (sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:569)
    at sp-webpart-workbench-assembly_en-us_9f8c6f0aa83e12a3358a5cca73b1ce92.js:569

Tenant is running on the 2018-04-20.015 release of SPFx.

Steps to Reproduce

  • scaffold new project using generator v1.4.1 with a React web part
  • to the render method add:
const graphClient = this.context.serviceScope.consume(MSGraphClient.serviceKey);
graphClient.api('me').version('v1.0').get();
  • run gulp serve --nobrowser
  • in the hosted workbench, add the web part to the canvas
  • in the console you get the aforementioned error
spfx-general bug-suspected

Most helpful comment

@Maksim-Ilyenia have you tried the following?

  • run gulp bundle and gulp package-solution but don't use the --ship flag so that the generated package will point to your local files
  • deploy the generated package to the app catalog
  • run gulp serve --nobrowser to start the local web server
  • add the web part to the workbench

All 12 comments

I'am experiencing the same behavior, when running gulp serve --nobrowser the MSGraphClient does not get initialized.
When deploying the app, the MSGraphClient works as expected.

Same here

@waldekmastykarz Any news on this? My team experiencing the same behavior. Will it fix?
Can we create a MSGraphClient in another way as a workaround?

Same here. Tenants I tried on:

  • DEV tenant with Targeted Release
    'Normal' tenant with Targeted Release

@Maksim-Ilyenia have you tried the following?

  • run gulp bundle and gulp package-solution but don't use the --ship flag so that the generated package will point to your local files
  • deploy the generated package to the app catalog
  • run gulp serve --nobrowser to start the local web server
  • add the web part to the workbench

@mmsharepoint When you still encounter an error using the steps above add the webpart to a new modern-page (ignoring the remote workbench). This worked for me.

Thanks for your answer @RobinBreman
But I already knew the steps and they are working for me as well but the original issue and question was who else faces the error when working with the workbench.aspx without deploying the app

One of the main disadvantages of the mentioned workaround is:
Your colleagues cannot work with an already deployed Version of your Webpart as long as you need to debug it (OK, I also know there would be another Workaround for this as well but too much effort ...)

Thanks @waldekmastykarz your solution works fine.

A short update on this with version 1.5.0:
I updated an existing solution from 1.4.1 to 1.5.0 by follwoing the standard approach
https://docs.microsoft.com/en-us/sharepoint/dev/spfx/toolchain/update-latest-packages
and additionally had to use Chris O' Breins nuclear approach:
http://www.sharepointnutsandbolts.com/2018/05/Update-SPFx-version.html
Now the debugging seems to work with the workbench on server-side ("/_layouts/15/workbench.aspx) although I received some timeout issues at first on renewing the token ...("Token renewal operation failed due to timeout") after some F5 they were gone and debugging seems to work now.

Based on the message from @mmsharepoint, we should be fine with this starting from 1.5. If that's not the case, let's re-open.

@waldekmastykarz @VesaJuvonen I followed your solution and my code looks as follows:

import { AadHttpClient } from "@microsoft/sp-http";
import { MSGraphClient } from "@microsoft/sp-client-preview";
const client: MSGraphClient = this.context.serviceScope.consume(MSGraphClient.serviceKey);
client
.api('/me')
.get((error, response: any, rawResponse?: any) => {
console.log(response);
});

Adding web part to the hosted (remote) workbench fails with the following error:

image

I tested the Authorization token from the Request Headers on https://jwt.io/ and it says invalid signature.

Please let me know if you have any suggestions to resolve this. Appreciate your help.

Thanks!

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues

Was this page helpful?
0 / 5 - 0 ratings