Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'web')

[cwdata]

Category

• Enhancement
• Bug
• Question
• Documentation gap/issue

Version

Please specify what version of the library you are using: [ 3.5.1 ]
Please specify what version(s) of SharePoint you are targeting: [ SPO ]

Observed Behavior

I recently ran into an issue similar to the one reported in #2239. For example, simply when switching the page on which the Webpart is placed into edit mode, the code in the componentDidMount() will error out when accessing getSP().web.(something).
After going through some debugging and trial and error steps I found a reason for that behavior.
In the example provided at https://pnp.github.io/pnpjs/concepts/project-preset/ -> Use a config file
the code is doing the following check
if (_sp === null && context != null) {
This leads to the problem described in the above mentioned issue (PnPJS is somehow not initialized properly).
The line needs to be changed to
if (context != null) {
After changing this line the problem disappeared. I'm not really deep into Javascript but it seems that the _sp object in the config file is still holding 'some' content which isn't valid anymore. The getSP(this.context) in the onInit() method of the Webpart isn't reinitializing the _sp object because it isn't null after a page navigation event -> Later usage of the object will lead to an error.
BTW: The example linked from the docs (https://github.com/pnp/sp-dev-fx-webparts/tree/main/samples/react-pnp-js-sample) is using the same problematic code.

Steps to Reproduce

From my point of view this should always happen when using the 'config file' from the docs, accessing getSP().web.(something) in componentDidMount() and changing the page into edit mode after the Webpart has loaded.

[sallaadithya]

I'm also facing the same issue when switched to Edit mode, for now, when creating sp object, checking null for this.context, resolving the issue, but this might fail for msgraph calls.

[patrick-rodgers]

@cwdata and @sallaadithya - have either of you tried the nightly build? The fix for the issue described in #2356 is not yet in a monthly release.

[sallaadithya]

I just came to know about Nightly build, but sorry, I can't try this now as our application is in production. Will try after the major release.

[patrick-rodgers]

@sallaadithya - sorry, a bit confused. How do you test your application before it hits production? You can drop the nightly build in there and test to see if this issue is resolved - just don't ship it live. If this fixes your issues, great, but if it doesn't, you'll need to wait another month before we can investigate.

[cwdata]

@patrick-rodgers
I just tried it with the nightly release
"@pnp/sp": "3.5.1-v3nightly.20220809"
and the behavior is the same as with the normal 3.5.1.

[patrick-rodgers]

The webpart on the page is not destroyed when placed in edit mode - rather the lifecycle is called again - so if the webpart or a service is holding a reference to the old context you would see this issue. Your code would need to account for the switch to edit mode.

Your suggested edit would remove the caching of the _sp which is by design. Otherwise you can't call getSP when the context isn't present and is why it was coded that way.

[cwdata]

@patrick-rodgers, I think you misunderstood the problem here - seems I didn't explain it precisely enough.
First of all, from my point of view this is only a documentation issue, there's nothing wrong in the code of PnPJS v3. I think, the example given is just wrong.
We are using the code exactly as shown in the documentation and the example linked in my first post, and we see that it fails when switching the page into edit mode. We are definitely not storing the context anywhere. The getSP() method is always provided with the context we get from SPFx in the onInit() method of the webpart. Also, calling getSP() further on in the code without providing a context works without issues (the caching of the _sp object you mentioned).
The problem lies in the fact that your example code is checking for '_sp === null'. As _sp is a globally defined object it will therefore only be initialized in the very first call to onInit() and never again (until you press F5). In other words, putting the page into edit mode will call onInit() including a new context object but this won't reinitialize the global _sp object with the new context as _sp clearly is !== null at that stage.
Does that make sense now?

[coreyroth]

This issue is affecting me as well. Basically, the existing sp object isn't valid when the page is placed in edit mode. I've noticed that the behavior is the same though whether I am F5 refreshing the page in edit mode or toggling from display mode to edit mode.

The workaround by removing the check to see if the sp object exists works though. If we still need to interrogate the sp object before creating a new one maybe there is a way to look at a specific property of the object to see if it needs to be recreated?

I haven't tried 3.6.0 yet, but I could look into that as well.

[BlazeOfFeathers]

I have the same issue..

[juliemturner]

I can confirm that the sample should be changed to
if (context != null) {
and will update the documentation for the next release unless someone wants to do the PR themselves which would be lovely of course.

[github-actions]

This issue is locked for inactivity or age. If you have a related issue please open a new issue and reference this one. Closed issues are not tracked.