Once again an article about navigation events. This time it has nothing to do with checks you need to implement to know when or to which page you navigated. This time it is about canceling/aborting API calls which your browser performs while navigating to another page. Most likely you can cancel these calls because they do no longer matter for the current page.
Some time ago I wrote about things to check in your SharePoint Framework application customizer for making sure it behaves correctly on navigation events. This included checks to see if you navigated to another page, different hub site and site with another language. In most cases, these are the checks that you want to put in place, to make sure that your application customizer renders the right data after a navigation event.
When building a SharePoint Framework solution which includes application customizers. One of the important things about their functionality is how they behave during navigation events/page transitions. These days in modern SharePoint most of the page transitions are achieved from the client-side, which means that it does not fully reload the page, but only partially.
Probably one of the most difficult things when working with application customizers is how it behaves while navigating. Modern sites have their own page navigation mechanism which provides a great user experience as the page does not require a full-page refresh. Only the things that are changed will get loaded/unloaded from the page.
Working with cross-site publishing in SharePoint can be fun, but it can also give you some headaches. One of the things were it can go wrong is the permissions, it all seems very simple just some clicking in the UI and you’re all set. That is correct, but what happens if it goes wrong?