Peculiarity with Hub sites - SPFx Header displayed state of associated site is initial preserved

Following information architecture situation:

1. A communication site registered as hub site
2. Another site (can be communications or modern teams site) associated with the hub site
3. The associated site has some site info tagging; which is visualized to site visitors through a SPFx Header extension
4. The hub site either does not have site info, or the values that it has are different from that in the associated site

Effect of this situation is that when one navigates within the hub association from associated site to hub and vice versa, it can in its (cached / preserved) header display false / incorrect information...

Site associated with Hub; in this site via SPFx Header extension, some ‘site identification’ is visualized in the site’s header

From this hub-associated site, navigate to the hub site. The header info remains visible, even though the info does not hold for the hub site

Refresh / explicit (first)visit the hub site; then the ‘false-positive’ site info is gone

From first visit of hub, navigate to the associated site. The header info remains invisible, even though this site holds identifying site information

Cause: in an hub, only on 'first-visit' the SPFx Header(s) are executed Inspecting the network traffic, it is evident that the displayed header info is not refreshed on navigating 'within hub context': the SPFx Header is not re-executed. Apparent only on explicit 'first-visit' to an Hub assocation - hub or associated site; then SPFxHeader components are executed. And on any navigation 'within' the hub; the (visual) state of the SPFxHeader is preserved; on same notice as the 'hub navigation.

For performance perspective, makes sense. But in situation where via SPFx Header extension essential site information is displayed, -- which is not per se similar throughout the entire hub association; the result in browser is functional / governance-wise incorrect.

UPDATE - problem resolved thanks to community

On friendly suggestion of Vesa Vujonen, I submitted our finding as SharePoint dev issue: Hub site on navigation preserves SPFx header display state of associated site. And the combined power of the community delivered; Andrew Connell suggested that it's related to the navigatedEvent & the page routers partial page loading, and referred to post of Elio Struijf in which similar behavior is described and solution provided: Handling navigation in a SharePoint Framework application customizer.

Redeploy your SPFx Extension to SharePoint

One of the charms of SPFx Extensions is that they apply tenant-wide: they can be configured for immediate utilization in all modern site collections in your tenant. On SharePoint foundational level this works via the concept of good-old CustomAction that is injected into the context of each modern site collection. In the SPFx Extension package the CustomAction is configured as Feature deployment. Via the parameter 'skipFeatureDeployment' in the package-solution.json (see 'Tenant-scoped solution deployment for SharePoint Framework solutions') you can configure the SPFx Extension to be immediate available across all the sites in the tenant when the solution package is installed to the tenant app catalog, without need to explicit activate the CustomAction feature in each individual site.

This works out fine on the initial deployment of your SPFx extension: the deployed SPFx header automatically is included and active on each site.

On initial deploy, SPFx Extension included once in each modern site

However, in case of need for redeployment, you must be aware of a current glitch: the SPFx Extension gets multiplied per each re-deployment. The cause of this is in how the (semi)immediate and tenant-wide application of the CustomAction is applied. The CustomAction is not injected in the scope of each individual site (Web.UserCustomActions does not include the CustomAction of the SPFx Extension); but is injected as Tenant Wide Extensions. In case of "skipFeatureDeployment": true in the package-solution.json file, on upload / install of the .sppkg file in the tenant App Catalog the administrator is asked to set the 'Make this solution available to all sites in the organization' checkbox. If set, a row is added in the list 'Tenant Wide Extensions' in the App Catalog site. And on re-upload / redeploy, the checked setting is applied again, resulting in duplicate entries for the same SPFx Extension in the Tenant Wide Extensions list. This results that the CustomAction is applied multiple times per each site, and therefore that the SPFx Extension is included multiple times in each site...

As side-effect of re-deploy, SPFx Extension is multiplied in 'Tenant Wide Extensions' list

Result is that the SPFx Extension is included multiple times per each site

Correcting this faulty situation is simple once you know how-to (thanks to Vesa Vujonen for fast response on support question raised): just remove the duplicate entries from the Tenant Wide Extensions list. Mind you, it can take some elapse time before the effect of this is structural applied accross all the WFE's involved in serving the sites of one's tenant.

Fix by removing the duplicate rows in Tenant Wide Extensions

Then the SPFx Extension again included once, and referring to latest package version

SharePoint mobile app + SharePoint Framework support?

The latest development approach for SharePoint customizations is via the new SharePoint Framework. MVP Waldek Mastykarz has multiple informative posts on what it is and how to utilize. In Everything you need to know about the SharePoint Framework he makes a remarkable statement: "When building solutions on the SharePoint Framework, if you follow the guidelines provided by Microsoft, not only will your solution look great on mobile devices but it will also be rendered in the native SharePoint mobile app which will be released shortly".

Remarkable, as I'm confused by how a native App could be running clientscript. So I challenged Waldek and Bill Baer via twitter to expand on that:

Well, turns out the statement is for now a bit too early. Microsoft is working on bringing this capability in the new SharePoint mobile app, and Vesa Juvonen acknowledges that Microsoft should tackle my question in their message.

UPDATE (June 13) Jeff Teper, interviewed at SharePoint Saturday Paris, answered on my question, being "We host html in JavaScript" [within the native code of the mobile app]. Although this is merely the high-over answer, and I want to understand more of the lower level details; this is sufficient for now. Details will be shared later by Microsoft and informed MVPs.