Unable to access SPFi object after partial page reload

[argofgra]

Major Version

4.x

Minor Version Number

4.18.0

Target environment

SharePoint Framework

Additional environment details

Web parts running from app catalog in standard M365 tenant

Expected or Desired Behavior

The desired behavior is to use the SPFi object without reinitializing the context. The operation is usually retrieving items from a list. But it could also be getting info about the web, retrieving data from another site, etc.

Observed Behavior

I get the error Cannot read properties of undefined (reading 'web') when the web part runs again after a partial page reload. In my example I'm getting the web, but it was originally found trying to access sp.web.lists.

Steps to Reproduce

1. Setup a HelloWorld web part as described below.
2. Add this to the home page of a communication site
3. Setup another page in the comms site, with a link in the navigation
4. Load home page, allow web part to render (works this time)
5. Use navigation to go to other page
6. Use navigation to return to the home page
7. Observe error

Create a HelloWorld web part that initializes a common SPFi object via a centralized helper.

Web part init:

protected onInit(): Promise<void> {
  getSP(this.context);

  return this._getEnvironmentMessage().then(message => {
    this._environmentMessage = message;
  });
}

Centralized SPFi init:

/* eslint-disable no-var */
import { WebPartContext } from "@microsoft/sp-webpart-base";

// import pnp and pnp logging system
import { ISPFXContext, spfi, SPFI, SPFx as spSPFx } from "@pnp/sp";
import "@pnp/sp/webs";
import "@pnp/sp/lists";
import "@pnp/sp/items";
import "@pnp/sp/batching";

var _sp: SPFI;

export const getSP = (context?: WebPartContext): SPFI => {
  if (_sp === undefined || _sp === null) {
    //You must add the @pnp/logging package to include the PnPLogging behavior it is no longer a peer dependency
    // The LogLevel set's at what level a message will be written to the console
    _sp = spfi().using(spSPFx(context as ISPFXContext));
  }
  return _sp;
};

Rendered component:
(error occurs on line 14)

import * as React from 'react';
import type { IPnPjsWebPartProps } from './IPnPjsWebPartProps';
import { useEffect, useState } from 'react';
import { getSP } from '../../../helpers/pnpjs-config';

const PnPjsWebPart: React.FunctionComponent<IPnPjsWebPartProps> = (props: IPnPjsWebPartProps) => {
    const [message, setMessage] = useState<string>('Initial value, stil loading...');

    useEffect(()=>{
      // eslint-disable-next-line @typescript-eslint/no-floating-promises
      (async ()=>{
        try {
          const sp = getSP();
          const web = await sp.web(); // errors here on partial page reload
          console.log(web);
          setMessage('Got the web without an error! Hurrah!')
        } catch (e) {
          console.error('Error getting web :\'(', e);
          setMessage((e as Error).message);
        }
      })();
    },[])

    return (
      <section>
        <div>{message}</div>
      </section>
    );
}

export default PnPjsWebPart;

[bcameron1231]

Hi, so this is something that has been popping up a bit. Upon investigation, it appears Microsoft is disposing of the page context before the instance of the code is removed and the SPFx behavior is holding on to it via the closure. We haven't fully discussed internally on how we want to address this.

For now, you should be able to do a copy of the context, so that it isn't affected by the disposed pageContext. Let me know if this gets you unblocked.

 _sp = spfi().using(spSPFx(getSPFxSnapshot(context)));

const getSPFxSnapshot = (ctx: any): ISPFXContext => {
    return {
        pageContext: {
            web: {
                absoluteUrl: ctx.pageContext.web.absoluteUrl,
            },
            legacyPageContext: {
                formDigestTimeoutSeconds: ctx.pageContext.legacyPageContext?.formDigestTimeoutSeconds,
                formDigestValue: ctx.pageContext.legacyPageContext?.formDigestValue,
            },
        },
        aadTokenProviderFactory: ctx.aadTokenProviderFactory,
    };
}

[patrick-rodgers]

@bcameron1231 so the webpart/spfi isn't dropped but the context gets cleared while we're still holding a ref? Does it leave the webpart in memory/loaded somehow and rerun it with a new context? I wonder if we can detect that and null out the held context - but then we'd need to new one?

[bcameron1231]

@patrick-rodgers As far as I can tell, the Web Part is held in memory during those non-refreshing navigation events. When I debugged it I was able to see the pageContext from SharePoint internals (sp-page assembly) was undefined and the `disposed' property was true.

I have some screenshots and had tagged the SPFx team internally, but no response.

Yea we could check for undefined, but I am not sure of a way to handle getting a new one...

One option I was thinking was having a local context variable we copy from the passed in context inside the behavior... But I haven't thought through all the side effects of that yet, It does work though. The cloning context is the approach I took at my company, and haven't had any issues (yet).

[VesaJuvonen]

@bcameron1231 - "had tagged the SPFx team internally, but no response." - Let's start a new thread on this in the SPFx Commitee, so that we can route the issue and investigation to engineering. Seems definitely like a topic where we should engage. Could not find any internal MVP/NDA discussions on this (could be older one), so let's reinitiate so that we can help. Thx 🙏

[bcameron1231]

@bcameron1231 - "had tagged the SPFx team internally, but no response." - Let's start a new thread on this in the SPFx Commitee, so that we can route the issue and investigation to engineering. Seems definitely like a topic where we should engage. Could not find any internal MVP/NDA discussions on this (could be older one), so let's reinitiate so that we can help. Thx 🙏

Sounds great! I need to correct myself, I thought* I had tagged the team in it (in a MVP discussion). Upon review, I forgot to atMention. That's on me!, but I'll move that thread into the SPFx Committee for discussion.

[argofgra]

Hi, so this is something that has been popping up a bit. Upon investigation, it appears Microsoft is disposing of the page context before the instance of the code is removed and the SPFx behavior is holding on to it via the closure. We haven't fully discussed internally on how we want to address this.

For now, you should be able to do a copy of the context, so that it isn't affected by the disposed pageContext. Let me know if this gets you unblocked.

 _sp = spfi().using(getSPFxSnapshot(spSPFx(context as ISPFXContext)));

const getSPFxSnapshot = (ctx: any): ISPFXContext => {
    return {
        pageContext: {
            web: {
                absoluteUrl: ctx.pageContext.web.absoluteUrl,
            },
            legacyPageContext: {
                formDigestTimeoutSeconds: ctx.pageContext.legacyPageContext?.formDigestTimeoutSeconds,
                formDigestValue: ctx.pageContext.legacyPageContext?.formDigestValue,
            },
        },
        aadTokenProviderFactory: ctx.aadTokenProviderFactory,
    };
}

Yes, this does appear to work, though I think your snippet was a little bit backwards. I modified it slightly to the one shown below. I'll recommend we use this workaround until the underlying issue is resolved and then remove it later.

_sp = spfi().using(spSPFx(getSPFxSnapshot(context)));

[bcameron1231]

Oops, you're right. :) Thanks for that! (Updated my comment)

We're going to keep this discussion open in the meantime as we work with Microsoft to understand if there's an issue with the Page Life Cycle, or something we're going to have to accommodate for within PnPjs.