Probable bug inside navigatedEvent listener of SPFx Application Customizer

[devangbhavsar89]

Hello guys!

I'm implementing a certain customization via. SPFx extension (i.e., an application customizer) which involves moving of some components (say, quick search box) from OOTB site header area to top placeholder area, as a part of custom header.

I do understand that the OOTB search box component loads asynchronously on the page. This has been taken care of already while performing the component transition. So that part is pretty much achieved quite easily. Now as we know, the OOTB quick search box is not shown on all pages (say, document library, for example), so then in order to comply to OOTB semantics/user experience, it should also not be shown in the custom header as well on such pages. And as I've figured out, there is some MDS kind of partial loading taking place when we navigate across different pages. This means that the full application customizer code is not executed each time and thus the transited component still remains in its place - even though it is not intended any more.

So, of course, some additional logic is needed to hide it again when user navigates to such pages. And in order to also handle the MDS behavior, I started using this.context.application.navigatedEvent.add(this, this._navigatedEventHandler); event handler and build some code to perform cleanup/re-render inside it, so that it triggers each time when user navigates across pages. This seems to do the trick (quite a bit), as it provided me with some kind of listener that can then perform cleanup/re-render when user navigates across different pages.

However, as I've noticed there is some problem with this event handler. It actually fires 2 times instead of 1, for every single page navigation. Apparently, it fires 2 times - one before page navigation starts and one after page navigation is completed (it's just like item adding and item added events). However, there is no way to identify the "navigating" and "navigated" events distinctly. I even tried checking the SPEventArgs parameter which comes as the method argument, but it is always empty. There is no useful information in it.

Any clue if I'm missing out on something here or most likely this is some native issue with SPFx extension, as I understand?

Category

• Question
• Typo
• Bug
• Additional article idea

Expected or Desired Behavior

I'm expecting either of the following as a behavior:

• Ideally there should be separate triggers for page navigating or page navigated events, so that appropriate one can be leveraged based on the requirement.
• Or at least, the SPEventArgs parameter should provide some information about the type of event it is handling (whether it is page navigating or page navigated event).

Observed Behavior

The this.context.application.navigatedEvent() event triggers multiple times (just before page navigation starts and after the page navigation is completed). And on top of it, there is no way to distinguish both these events, because the method parameter/argument (SPEventArgs) is always empty in both cases.

Steps to Reproduce

Just place following code stub inside onInit() method of an application customizer:

this.context.application.navigatedEvent.add(this, (eventArgs: SPEventArgs) => {
    // Issue-1: Custom code to perform cleanup/re-render fires two times...
    this._navigatedEventHandler(eventArgs);
		
    // Issue-2: The eventArgs parameter is always empty!
    console.log(eventArgs);
});

Quick Workaround to the Issue

I tried a few tweaks in code and was eventually able to distinguish both events with the help of window.location parameter and some additional logic. This way, I got my code working in expected manner even with this 2 times execution of this.context.application.navigatedEvent() event handler. However, I'm not sure, if this is an optimal solution to the given problem definition. Please suggest?

Also it would be really nice, if we can have either both events available separately or at least its exact type (navigating or navigated) is known via. SPEventArgs parameter somehow.

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[patmill]

Thanks @devangbhavsar89 . I've got a repro and we're looking into it.

[devangbhavsar89]

Hi @patmill, do we have any update on this bug-fix?

Also I'm quite eager to know, in what manner will this issue be fixed. Meaning, (a) will we have separate handlers for navigating and navigated events or (b) have information about event type available inside SPEventArgs parameter? I believe, based on the type of fix that will be pushed to customer environments, I'll probably have to make corresponding adjustments to the earlier workaround which I'd made to get it working, to ensure that it continues to work seamlessly once the fix is pushed.

So just wanted to check how is it going to be fixed and when is it expected to roll-out?

[patmill]

The code is rolling out, so you should have it soon. The current fix is to not fire multiple events. There isn't currently an -ing/ed pair.

[devangbhavsar89]

That's great to know, thanks for the info!

[navarrorc]

@patmill can you please provide guidance on how to update my existing project so that the fix gets applied? Thank you.

[patmill]

You shouldn't have to do anything - as long as you didn't make temporary workarounds in your code. Are you still seeing issues?

[navarrorc]

Yes I am. The code inside the this.context.navigatedEvent.add(...) Is firing exactly twice when navigating to a different page.

[patmill]

OK, my bad. Apparently the fix isn't rolling until next week. But once it rolls, you shouldn't need to change anything. Sorry about the incorrect dates.

[navarrorc]

No worries. Thank you for the information.