Context not being reinitialized between pages

[tarjeieo]

This issue seems related to #544. I talked with Vesa on twitter and he asked me to create a new issue.

Category

• Question
• Typo
• Bug
• Additional article idea

Expected or Desired Behavior

We have an SpFx web part that renders an editing experience for additional list fields on the page. The web part is upgraded to the latest 1.4 drop. The editors can edit the page and then select a value from a dropdown. On save, the web part persists the field value for the current page. This works as intended on a single page.

Observed Behavior

When standing on a page with the web part present, and then creating a new page, and adding this web part again, the problem appears. Seemingly everything works as intended, but when selecting a value in the dropdown and saving the page, the previous page's value is updated, not the current one. When creating another page and repeating this again, the first page is updated.

Investing this further, it looks like this.context is not being reinitialized. Specifically the page id (which we are using) is not updated, and always contains the first, initial page that has this web part. This property is this.context.pageContext.listItem.id. I haven't noticed (nor looked for to be fair) if any other properties are updated later.

Our code uses OnInit to create the pnp context each time, but while debugging it doesn't look like the context changes in this method.

Another observed behavior is that the web part's console logging is stacking on subsequent pages. I.e. if you've created 5 pages in one go, the web part's log messages are appearing in the console 5 times with the exact same messages. Not sure if this is related, or a symptom of something else.

Steps to Reproduce

• Create a web part that uses this.context.pageContext.listItem.Id
• Add web part to a page
• Create a new page while standing on the first page
• Add the same web part to the new page
• Observe that this.context.pageContext.listItem.Id has the Id of the initial page

[manishgarg1]

Hi @tarjeieo, looks like there is a bug in the compose scenario. The pageContext is not updated. That said, the code behaves correct in the page navigation scenario. We are look at fixing this. Thank you for the report.

[spplante]

I have the same problem. I created a ListViewCommandSet extension, and I use the pageContext to identify the list in which I currently am, and when switching between lists using the quick launch, the pageContext.list.title is updated just fine on the first click of each list link, however when clicking back on a list that I previously clicked on, now the pageContext.list.title has the value of the previously clicked list.

For now, I went with a workaround that checks the URL instead of the page context to get the current list I am in, but it's kinda sketchy.

By the way I think this is not an SPFX issue but a SPO issue in general, because you can replicate the problem simply by going to Library Settings many times when switching library, at some point the Library Settings will bring you to the settings page of the previously clicked library, it really is something with the cache / MDS.

Update : Interestingly, the pageContext seems updated correctly when using it in the onExecute of my extension (which is when the extension button is clicked) instead of the onInit. This is interesting because it means that it's most likely a lifecycle issue, as it looks like the onInit exposes a pageContext that isn't updated yet but seems to be updated later in the lifecycle

[tdwhite0]

Facing the same issue here. Anyone know if this is going to be fixed soon? I'm suddenly scared that several things I've built are broken because they can't rely on the the page context being correct.

[tarjeieo]

Hi @tdwhite0, I use the same workaround as @spplante by getting the item from the URL of the current page, but it feels a little bit hacky. Would be nice with a fix for this indeed.

[spplante]

Actually as I said in my update, I figured out that the context is actually valid 100% of the time when used in the onExecute method rather than the onInit.

So I reverted back to using the context but did everything in the onExecute instead.

It’s still a bug that needs to be fixed however.

[tdwhite0]

@spplante Mine is happening inside webparts, which don't look like they have an onExecute method. Looks like I might need @tarjeieo 's hack.

[spplante]

I see, didn’t use it in a WebPart yet

[patmill]

So, I'm struggling to reproduce this. I've created an application extension that writes out some information to the header and the console.
I see two specific areas that are problematic, and that need to get fixed
1 - Creating a new page doesn't trigger a navigate / context update
2 - The interaction with Search is dodgy at times

WIth respect to this line - "Update : Interestingly, the pageContext seems updated correctly when using it in the onExecute of my extension (which is when the extension button is clicked) instead of the onInit. This is interesting because it means that it's most likely a lifecycle issue, as it looks like the onInit exposes a pageContext that isn't updated yet but seems to be updated later in the lifecycle"

There might be a misconception of the lifecycle. OnInit will be called the first time the extension is loaded. It won't get called on every navigate. You'll need to hook into the OnNavigate() application event if you are storing information, or access the context object at the point in time you need the data.

Does that makes sense?

[spplante]

@patmill that's in fact something I noticed, but I couldn't find a regular patern in which the onInit was called si I thought it was a bug. Indeed, the documentation has always been clear about the fact that the onInit was only called the first time the extension is loaded, but I was assuming that between libraries (different pages) the extension would be loaded for the first time everytime you change page...

Then I figured that as you said, it's not the case, once the extension has been loaded even if you switch page (switching libraries using the quick launch for example) the extension was somehow cached and not reloaded when going back to the original page.

However, when switching pages multiple times, it ends up being reloaded once a while, so lets say you switch page 20 times I was entering the onInit 3-4 times within the 20 page reloads, so the inconsistency made me believe that it wasn't by design.

As for the onNavigate() event, I had never heard of it before, yes it would make sens but do you have an example of how to use it in a List Command Extension? Because the following seems to be only available in application customizers :

this.context.application.navigatedEvent

Also note that it's been a while since I had the problem, the problem has been documented at plenty of places like this one #1042 and it seems that a fix was implemented on april 24th, no idea if it works better as of today.

[raymondlittle100]

I am seeing some similar behavior around this. Previously I used to get a partial page load when navigating between pages in the same modern team site. This was a little frustrating because as mentioned above things like list item id didn't update but I could use the Url in certain cases on click events.

It now seems like the context isn't updating when moving between modern team sites now so when I access a modern team site I pass the current site URL to my react component but when I click a link to go to another modern team site my react component isn't reloaded it still has the original site URL, see below

First load

After link click

@VesaJuvonen could you confirm this behavior? I have setup the customizer as per the documentation with the changeEvent being registered in the onInit. Others are suggesting onExecute can you confirm the correct behavior expected and the correct event in which to register the customizer.

Thanks much appreciated

https://docs.microsoft.com/en-us/sharepoint/dev/spfx/extensions/get-started/using-page-placeholder-with-extensions

[rmillener]

@raymondlittle100 we're successfully using navigatedEvent but there is a huge amount of confusion around this.

We had a secondary issue where we didn't update our PnP JS context in our data-getter/service after navigation. This was fixed by switching to the second initialisation method in PnP JS.

[raymondlittle100]

@rmillener thanks for the response.

Its good to know it isn't just me experiencing this and there is a way to resolve this its just the confusion around is this a bug or expected behavior going forward. I'm reluctant to make code changes I may have to revert if its a bug but if its the expected behavior it would be good to know the recommended approach to initialize customizers going forward

[michelsmit]

Any updates on this one in a web part scenario? Struggling with the exact same issue...